Middleware Technologies

1
Middleware Technologies

• MC9251

2
Unit-I Introduction

• Middleware
• Middleware is a general term for any program that
  serves to "glue together" or mediate between two
  separate programs.
• A common application of middleware is to allow
  programs written for access to a particular
  database to access other databases

3
Middleware

• Enterprise Application Integration-EAI
• To exploit the Internet, E-commerce, Extranet,
  and other new technologies
• Middleware categories
• TP monitors
• RPC systems
• Object Request Brokers (ORBs)
• Database access systems
• Message Passing

4
Client-Server Architecture

• Relationship between two computer programs, the
  client makes a service request from another
  program, the server.
• Can be used in a single computer
• More important in Computer Networks
• Example FTP, Internet, Internet banking

5
Client-server architecture - Static HTML pages
6
Client-server - CGI Scripts
7
Server side scripting technologies
8
Client-Server Architecture

• Two tier architectures
• Three tier architectures
• Three tier architecture with transaction
  processing monitor technology
• Three tier with an ORB architecture
• Distributed/collaborative enterprise architecture

9
Transaction Processing monitor technology

• The ability to update multiple different DBMSs in
  a single transaction
• Connectivity to a variety of data sources
  including flat files, non-relational DBMS, and
  the mainframe
• The ability to attach priorities to transactions
• robust security

10
Client-Server Architecture Characteristics

• Service
• Shared Resources
• A symmetrical protocols
• Transparency of location
• Mix and match
• Message based exchanges
• Encapsulation of services
• Scalability
• Integrity

11
Types of Servers

• File server
• Database server
• Transaction server
• Group server
• Object server
• Web server

12
File Server

• It is a computer responsible for the central
  storage and management of data files
• Allows users to share information
• File server a normal PC Dedicated network
  attached storage
• System security to limit access to files to
  specific users or groups
• Novells eDirectory, MSs Active directory

13
Database Server

• SQL requests and Data
• Server uses processing power to find the
  requested data
• DBMS provides server functionality
• Database Master servers and Slave servers
• Client application written by the user

14
Transaction Server

• Transaction- a group of SQL statements
• Client invokes Remote procedures Servers
  execute transactions
• Both client and server component coded by the
  user
• Online transaction Processing (OLTP)

15
Groupware Server

• Addresses the management of semi-structured
  information
• Applications are created using a scripting
  language and form based interfaces

16
Object Server

• Client objects communicates with server objects
  using an ORB
• ORB locates an instance of object server class,
  invokes requested method
• Server objects provide support for concurrency
  and sharing
• Various ORBs
• CORBA - Object management Group
• Dcom - Microsoft
• SOM - IBM
• NEO - SUN

17
Web Servers

• HTTP requests - HTTP responses along with
  optional data contents
• Error response
• Supposed to serve requests quickly from more than
  one TCP/IP connection at a time.

18
Client/Server building blocks

• Architecture Analogy 
• We buy houses and not plans
• Thus, computer users buy business solutions and
  not client/server architectures
• How is the application split between the client
  and the server?
• What functions go into the client and server?
• Can the client/server model accommodate
  businesses of all sizes?
• Can a single client/server model accommodate all
  these type of users? 

19

• The Basic Building Blocks  
• Components
• Client
• Server
• Middleware and is catered for

20

• The Four situations
• Client/server for tiny shops
• Client/server software and most of the business
  services runs on the same machine one person
  shop
• Client/server for small shops and departments
• Classic Ethernet client/single-server building
  block implementation
• Client/server for intergalactic enterprise
• Multi-server building block implementation of
  client/server
• Client/server for the post-scarcity world
• Every machine is transformed in the world for
  both client and a server. Personal agents on
  every machine and do the negotiations

21
Client Components

• Operating system with
• a Graphical User Interface (GUI)
• the ability to find and access distributed
  services
• Web browser to
• provide the user interface
• download the necessary components from the server
  on demand
• Middleware components handle the non-local
  services.
• Clients may also run a component of a Distributed
  System Management (DSM) system

22
Server Components

• Server Operating System
• A server software package of some kind
• SQL Database server
• Transaction Processing (TP) monitor
• Groupware server
• Object server
• Web server
• Middleware components handle the reception of
  requests for services
• A server may also run a DSM component

23
Middleware Components

• These run on both the client and the server sides
  of a client/server application
• Transport Stacks
• Network Operating Systems (NOSs)
• Service-specific middleware
• May also have a DSM component

24
General middleware provide substate for most
client/server 

• Communication stacks
• Distributed directories
• Authentication services
• Network time services
• Remote Procedure Calls
• Queuing services
• NOS extensions
• Distributed file and print services

25
Service-Specific Middleware

• Database
• ODBC, JDBC, SQLJ, DRDA, OLE DB, etc.
• OLTP
• A variety of proprietary products
• Groupware
• MAPI, VIM, JavaMail, SMTP, POP3, IMAP, etc.
• Object
• CORBA, Microsoft's COM
• Internet
• HTTP, CGI, XML, SET

26
Server-to-Server Middleware 

• Middleware software may also be used to
  coordinate inter-server interactions
• Servers are often clients to other servers, and
  vice-versa
• Some server-to-server interactions require
  special middleware
• Mail servers may do store-and-forward type
  messaging
• Databases and groupware use daemons to
  automatically replicate data

27
Unit - II

• Enterprise Java Beans

28
Enterprise Java Beans

• Write once, run-anywhere, middle tier components
• Evolution of Technology
• Mainframe/Terminal model
• Transaction processor
• To handle concurrent client requests
• Several statements as on logical unit
• Guaranteeing successful execution or non would be
  executed

29

• Transaction processor
• Provides API with begin, commit, and
  rollback.
• Logging mechanism
• ACID properties of Transactions
• Atomicity
• Consistency
• Isolation
• Durability

30
OLTP Vs DSS/EIS/OLAP

• Updates in a Database
• Response time is critical
• Can handle large volume of transactions

• Reviews information
• Involves long-running queries
• Smaller number of requests, longer think time

31
Evolution

• Two-Tier architecture
• Transaction integrity by DBMS
• Three-Tier architecture
• Transaction integrity by Middle tier components
• Sockets
• Limited distributed computing
• RPC
• A thin layer on top of Sockets
• Stub-Skeleton
• Stub uses IDL

32

• CORBA
• An object oriented RPC Mechanism
• Objects written in one language can be called by
  objects written in a different language
• CORBA clients can access EJB objects
• RMI
• Java version of CORBA
• No need to write IDL. RMIC handle automatically
• EJB allows client side RMI calls to EJB objects

33

• EJBs role
• EJB specifies an execution environment
• EJB is a java class implements Session bean or
  entity bean
• Container provides services to EJB
• Container provides proxy object for each bean
• EJB exists in the middle tier
• To encapsulate business logic
• Supports transaction processing
• Can Maintain state

34

• Enterprise JavaBeans (EJB) is an architecture for
  setting up program components, written in the
  Java programming language, that run in the server
  parts of a computer network that uses the
  client/server model.
• Enterprise JavaBeans is built on the JavaBeans
  technology for distributing program components
  (which are called Beans,) to clients in a
  network.

35

• Enterprise JavaBeans offers enterprises the
  advantage of being able to control change at the
  server rather than having to update each
  individual computer with a client whenever a new
  program component is changed or added.
• EJB components have the advantage of being
  reusable in multiple applications.
• Can be deployed across all major operating
  systems, not just Windows.

36
EJBs Architecture

• Logically three-tier system
• EJB server DB reside on the same machine EJB
  server includes built in functionality for
  persistent storage
• EJB server Client EJB bean makes a call to
  another EJB bean
• All three tier might reside on a single machine
• Client - EJB Server - Database

37

• EJBs role in the three layers
• Client calls remote EJBs
• EJB components live in the middle tier,
• EJB objects reside in an EJB container which is
  in side of an EJB server
• DB resides in the third layer
• EJB beans accesses the DB through JDBC

38
Overview of EJBs Software Architecture

• EJB bean exists within the container
• Client communicates with bean through home
  interface, remote interface

39
Overview of EJBs Software Architecture

• EJB server
• Provides container with lower level services such
  as network connectivity
• Layered approach
• EJB Container
• Interface between EJB and outside world
• Can create pool of beans
• Provides services to Beans
• Support for transactions, management of multiple
  instances, persistence, and security

40

• Enterprise Bean
• EJB object is implemented, in addition Home
  interface and Remote interface implemented
• Types of EJB beans

41

• Session Bean is created by a Client and usually
  exist only for the duration of a single
  client/server session.
• Entity Bean represents a business objects in a
  persistent storage mechanism
• Ex Customers, orders products

42

• A stateless session bean is a distributed object
  that does not have an associated conversational
  state, thus allowing concurrent access to the
  bean.
• The contents of instance variables are not
  guaranteed to be preserved across method calls.
• Stateful session beans are distributed objects
  having a conversational state. The state could be
  persisted, but access to the bean is limited to
  only one client.

43

• Session bean Vs Entity bean
• EBs are persistent, allow shared access, have
  primary key, and may participate in relationships
  with other entity beans
• When to use Entity bean
• If the bean represents a business entity, not a
  procedure
• If the beans state must be persistent
• Ex CreditcardEJB - Entity bean
• CreditcardverifierEJB Session bean

44
EJB Session Entity Bean

• Unit-III

45

• Session EJB
• A session bean instance is
• A non-persistent object
• Implements some business logic
• Runs on the server
• Live as long as the client need them

46

• Constraints on Session Bean
• EJB cannot use threads but container can run
  multiple instances
• Cannot directly access transaction manager
  container is responsible for managing
  transactions
• Cannot use JDBC commit and rollback container
  issues commit and rollback
• Not allowed to change security identity at
  runtime
• Cannot have static variables it must be static
  final

47

• Session bean constraints
• It is irrevocably disappear from the server
• If timeout value expires
• If the server crashes, shutdown, or restarted
• Session beans are non-reentrant another call to
  the same object from same transaction context
  throws remote exception

48

• Components of a Session EJB
• The remote interface
• Extends EJBObject (All extended types are from
  javax.ejb)
• The home interface -Extends EJBHome
• The bean class itself, called XBean
• Extends SessionBean
• Should implement java.io.Serializable (for
  stateful beans)
• Implements business methods from the component
  interface
• Implements lifecycle methods (ejbXXX)

49

• Stateless Session bean life cycle
• Nonexistence
• Method-ready state
• Session EJBs have no state, so activation and
  passivation are meaningless
• The container simply destroys instances when low
  on memory, and creates new ones as needed
• Still, ejbActivate and ejbPassivate must be
  implemented in XBean (as empty methods)

50
(No Transcript)
51

• Stateful session bean

52
Stateful session bean

• The state of an object consists of the values of
  its instance variables.
• In a stateful session bean, the instance
  variables represent the state of a unique
  client-bean session.
• Because the client interacts ("talks") with its
  bean, this state is often called the
  conversational state.

53
Stateful session bean

• Stateful session beans are appropriate if any of
  the following conditions are true
• The bean's state represents the interaction
  between the bean and a specific client.
• The bean needs to hold information about the
  client across method invocations.
• The bean mediates between the client and the
  other components of the application, presenting a
  simplified view to the client.

54
Entity Bean

• Can be used concurrently by several clients
• Container manages database integrity by
• Queuing client requests
• Creating an instance of the bean for each client,
  and synchronizing
• Entity beans persist across multiple sessions and
  multiple users long lived
• No limit on the life time
• Can be removed by explicit remove() or delete
  from database

55

• Will survive a server crash or restart
• No timeout period
• Directly represent data in a database,
• Variables map directly to the columns in the
  table
• Referenced by primary key
• Bean-Managed Persistence
• Contains code that updates the database
• Container Managed Persistence

56

• Primary Keys
• Primary key is represented by a Java class
• Public class Customerpk implements Serializable
• public int custid
• Carries the value from the client to server

57
Entity Bean Life cycle
58

• Components of an Entity EJBs
• Component interface
• Home interface
• The bean class
• Implements javax.ejb.EntityBean
• And a Primary Key class
• Can be an existing class
• String, Integer, Date, etc.
• Can be a new class (e.g., for composite keys)
• Must be serializable
• Naming convention XKey

59
UNIT 4CORBA
60
CORBA

• AN OBJECT ORIENTED RPC MECHANISM
• HELPS TO DEVELOP DISTRIBUTED SYTEMS IN DIFF.
  PLATFORMS
• OBJECTS WRITTEN IN DIFF., LANG, CAN BE CALLED BY
  OBJECTS WRITTEN IN ANOTHER LANG.
• CORBA CLIENTS CAN ACCESS EJB OBJECTS

61
CORBA Common Object Request Broker
Architecture How can distributed Object
Oriented systems implemented in different
languages and running on different platforms
interact? CORBA is the OMGs component model
62
IT IS AN PLATFORM LANGUAGE INDEPENDENCEIT IS
WELL SUITED FOR OBJECT ORIENTED SYSTEMS IDEA
USE OF OO SYSTEMS RUNNIG DIFF. PLATFORMS
COMPILED IN DIFF., LANG . AN INTERACTION BTWN
THEM
63
(No Transcript)
64
HISTORY OF DISTRIBUTED SYSTEMS

• MONOLITHIC SYSTEMS MAINFRAME
• 2TIER CLIENT/SERVER ARCHITECTURE
• MULTI TIER C/S (OR) DISTRIBUTED SYSTEMS

65
Monolithic Systems and Mainframes
66
Two-tier client/server architecture
67
Multi-tier C/S Distributed Systems
68
PURPOSE

• CORBA provides a standard mechanism for defining
  the interfaces between components
• OMG provides directory and naming services,
  persistent object services, and transaction
  services
• Two features are platform independence and
  language independence

69
CORBA alternatives

• Socket Programming
• Remote Procedure Call
• Function oriented interface
• OSF Distributed Computing Environment
• OSF standard to RPC
• MS-DCOM
• Restricted to only Microsoft technologies
• Java Remote Method Invocation
• Passing of objects by value
• Java only solution

70
Architecture overview

• An Object Oriented architecture
• Object Request Broker
• Interface Definition Language
• Communications Model
• Clients and Servers, Stub and skeleton

71
CORBA ARCHITECTURE
72
Object Request Broker (ORB)

• Facilitates communication between objects
• Locates a remote object upon a reference
• Marshals and un-marshals parameters
• Platform independent format

73

• The concept of ORB is-When an application
  component wants to use a service provided by
  another component, it first must obtain an object
  reference for the object providing that service.

74

1. According to the OMG, "CORBA allows applications
   to communicate with one another no matter where
   they are located or who has designed them."
2. This standard also defined the Interface
   Definition Language (IDL) and the Application
   Programming Interface (API) that makes
   client/server object interactions work in a
   specific implementation of an ORB.

75

• The OMG ORB model can be divided into two main
  parts
• Application oriented components
• Application Interfaces
• Domain Interfaces
• Common Facilities
• System oriented components
• Object Request Broker
• Object Services

76
(No Transcript)
77
Marshaling refers to the process of translating
input parameters to a format that can be
transmitted across a network. Unmarshaling is
the reverse of marshaling this process converts
data from the network to output parameters.
78
(No Transcript)
79
CORBA Networking( COMMUNICATIONS) Model

• network model
• Object model

80
N/W MODEL

• Inter-ORB protocols
• General Inter-ORB Protocol (GIOP)
• Internet Inter ORB Protocol (IIOP)
• Applications are built on top of IIOP
• GIOP protocols rest on TCP/IP, DCE protocols
• New layer ORB Protocol layer

81
(No Transcript)
82
CORBA Object Model

• Object Distribution
• A CORBA client, a remote method call looks
  exactly like a local method call
• Object Reference
• Basic Object Adapters

83
OBJECT REFERENCE

• 2 possible ways
• call by value
• Call by reference
• OMGS ORB USES CALL BY REFERENCE

84
(No Transcript)
85
BASIC OBJECT ADAPTERS

• purpose To interface an object's implementation
  with its ORB.
• PROVIDES 3 object ADAPTER types
• Basic Object Adapters
• provides set of methods for accessing ORB
  functions
• Library Object Adapters
• OO Database Adapters

useful for accessing objects in persistent
storage
86
IDL

• Provides interface b/w various CORBA objects
• Is a generic language
• Has its own language constraints
• IDL is not a procedural language it can define
  only interfaces, not implementations
• as its name suggests, is the language used to
  define interfaces between application components

87
IDL Ground Rules

• Case Sensitivity
• IDL Definition Syntax
• The Module
• In addition to ,
• Comments
• Use of C preprocessor
• Coupling cohension

88
PRIMITIVE TYPES

• Void
• Boolean
• Char wchar
• Float
• Double long types
• String
• Const modifier

• Integer types
• Long long long
• Unsigned ..,.,.,.
• Short
• Unsigned short
• octet

89
Constructed types

• The Enumerated type
• The Structure type
• The Union type
• Term A discriminator, as used in an IDL union,
  is a parameter that determines the value used by
  the union.
• THE INTERFACE TYPE and so on

90
Building a CORBA Application

• The outline of the process is this
• 1. Define the server's interfaces using IDL.2.
  Choose an implementation approach for the
  server's interfaces
• 3. Use the IDL compiler to generate client stubs
  and server skeletons for the server interfaces
• 4. Implement the server interfaces.5. Compile
  the server application.6. Run the server
  application.

91
Defining the Server Interfaces ( Define
Interface as an IDL file )

• module SimpleStocks   interface StockMarket
      float get_price( in string symbol )  
  

92
Choosing an Implementation Approach

• Inheritance mechanism, in which a class
  implements an interface by inheriting from that
  interface class
• The delegation mechanism, in which the methods of
  the interface class call the methods of the
  implementing class (delegating to those methods).

93
(No Transcript)
94
Use the IDL compiler to generate client stubs and
server skeletons for the server interfaces.

• When compiled with the idltojava compiler, the
  stubs and skeletons are placed in a package
• named after our module modulename
• Eg., stockapp,weatherapp

95
Implement the server interfaces.

• import org.omg.CORBA.     // All CORBA
  applications need these classes. import
  SimpleStocks.      // The package containing
  our stubs
• public class StockMarketImpl extends
  _StockMarketImplBase
•   public float get_price( String symbol )    
  float price 0     for(int i 0 i lt
  symbol.length() i)       price (int)
  symbol.charAt( i )         price / 5    
  return price  
•   public StockMarketImpl() super()

96
5. Implement and Compile the server
application.6. Compile and Run the Client
application.