Middleware Technologies
MC9251
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
10/3/2015
Middleware
2
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
10/3/2015
Middleware
3
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
10/3/2015
Middleware
4
Client-server architecture - Static
HTML pages
10/3/2015
Middleware
5
Client-server - CGI Scripts
10/3/2015
Middleware
6
Server side scripting technologies
10/3/2015
Middleware
7
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
10/3/2015
Middleware
8
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, nonrelational DBMS, and the mainframe
• The ability to attach priorities to
transactions
• robust security
10/3/2015
Middleware
9
•
•
•
•
•
•
•
•
•
Client-Server Architecture
Characteristics
Service
Shared Resources
A symmetrical protocols
Transparency of location
Mix and match
Message based exchanges
Encapsulation of services
Scalability
Integrity
10/3/2015
Middleware
10
Types of Servers
•
•
•
•
•
•
File server
Database server
Transaction server
Group server
Object server
Web server
10/3/2015
Middleware
11
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
– Novell’s eDirectory, MS’s Active directory
10/3/2015
Middleware
12
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
10/3/2015
Middleware
13
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)
10/3/2015
Middleware
14
Groupware Server
• Addresses the management of semistructured information
• Applications are created using a
scripting language and form based
interfaces
10/3/2015
Middleware
15
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 ORB’s
•
•
•
•
10/3/2015
CORBA
Dcom
SOM
NEO
-
Object management Group
Microsoft
IBM
SUN
Middleware
16
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.
10/3/2015
Middleware
17
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?
10/3/2015
Middleware
18
The Basic Building Blocks
• Components:
– Client
– Server
– Middleware and is catered for
10/3/2015
Middleware
19
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
10/3/2015
Middleware
20
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 nonlocal services.
• Clients may also run a component of a
Distributed System Management (DSM)
system
10/3/2015
Middleware
21
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
10/3/2015
Middleware
22
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
10/3/2015
Middleware
23
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
10/3/2015
Middleware
24
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
10/3/2015
Middleware
25
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
10/3/2015
Middleware
26
Unit - II
Enterprise Java Beans
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
10/3/2015
Middleware
28
Transaction processor
• Provides API with ‘begin’, ‘commit’, and
‘rollback’.
• Logging mechanism
ACID properties of Transactions
• Atomicity
• Consistency
• Isolation
• Durability
10/3/2015
Middleware
29
OLTP Vs
• Updates in a
Database
• Response time is
critical
• Can handle large
volume of
transactions
10/3/2015
DSS/EIS/OLAP
• Reviews
information
• Involves longrunning queries
• Smaller number of
requests, longer
think time
Middleware
30
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
10/3/2015
Middleware
31
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
10/3/2015
Middleware
32
EJB’s 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
10/3/2015
Middleware
33
• 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.
10/3/2015
Middleware
34
• 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.
10/3/2015
Middleware
35
EJB’s 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
10/3/2015
-
EJB Server
Middleware
-
Database
36
EJB’s role in the three layers
– Client calls remote EJB’s
– 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
10/3/2015
Middleware
37
Overview of EJB’s Software Architecture
• EJB bean exists within the container
• Client communicates with bean through
home interface, remote interface
10/3/2015
Middleware
38
Overview of EJB’s 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
10/3/2015
Middleware
39
Enterprise Bean
• EJB object is implemented, in addition Home
interface and Remote interface implemented
Types of EJB beans
10/3/2015
Middleware
40
• 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
10/3/2015
Middleware
41
• 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.
10/3/2015
Middleware
42
Session bean Vs Entity bean
• EB’s 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 bean’s state must be persistent
– Ex: CreditcardEJB - Entity bean
CreditcardverifierEJB – Session bean
10/3/2015
Middleware
43
EJB Session & Entity Bean
Unit-III
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
10/3/2015
Middleware
45
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
10/3/2015
Middleware
46
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
10/3/2015
Middleware
47
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)
10/3/2015
Middleware
48
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)
10/3/2015
Middleware
49
10/3/2015
Middleware
50
Stateful session bean
10/3/2015
Middleware
51
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.
10/3/2015
Middleware
52
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.
10/3/2015
Middleware
53
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
10/3/2015
Middleware
54
• 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
10/3/2015
Middleware
55
• 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
10/3/2015
Middleware
56
Entity Bean Life cycle
10/3/2015
Middleware
57
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
10/3/2015
Middleware
58
UNIT – 4
CORBA
10/3/2015
Middleware
59
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
10/3/2015
Middleware
60
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 OMG’s component model
10/3/2015
Middleware
61
•IT IS AN PLATFORM & LANGUAGE INDEPENDENCE
IT IS WELL SUITED FOR OBJECT ORIENTED SYSTEMS
IDEA :
USE OF OO SYSTEMS RUNNIG DIFF.
PLATFORMS & COMPILED IN DIFF., LANG .
AN INTERACTION BTWN THEM
10/3/2015
Middleware
62
10/3/2015
Middleware
63
HISTORY OF DISTRIBUTED SYSTEMS
• MONOLITHIC SYSTEMS & MAINFRAME
• 2TIER CLIENT/SERVER
ARCHITECTURE
• MULTI TIER C/S (OR) DISTRIBUTED
SYSTEMS
10/3/2015
Middleware
64
Monolithic Systems and
Mainframes
10/3/2015
Middleware
65
Two-tier client/server architecture
10/3/2015
Middleware
66
Multi-tier C/S – Distributed
Systems
10/3/2015
Middleware
67
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
10/3/2015
Middleware
68
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
10/3/2015
Middleware
69
Architecture overview
An Object Oriented architecture
• Object Request Broker
• Interface Definition Language
• Communications Model
• Clients and Servers, Stub and
skeleton
10/3/2015
Middleware
70
CORBA ARCHITECTURE
10/3/2015
Middleware
71
Object Request Broker (ORB)
–Facilitates communication between
objects
–Locates a remote object upon a
reference
–Marshals and un-marshals
parameters
–Platform independent format
10/3/2015
Middleware
72
• 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.
10/3/2015
Middleware
73
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.
10/3/2015
Middleware
74
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
10/3/2015
Middleware
75
10/3/2015
Middleware
76
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.
10/3/2015
Middleware
77
10/3/2015
Middleware
78
CORBA Networking(
COMMUNICATIONS) Model
• network model
• Object model
10/3/2015
Middleware
79
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 Middleware
Protocol layer
10/3/2015
80
10/3/2015
Middleware
81
CORBA Object Model
Object Distribution

A CORBA client, a remote method call
looks exactly like a local method call
Object Reference
Basic Object Adapters
10/3/2015
Middleware
82
OBJECT REFERENCE
• 2 possible ways
call by value

Call by reference
OMG’S ORB USES CALL BY REFERENCE

10/3/2015
Middleware
83
10/3/2015
Middleware
84
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
10/3/2015
useful for accessing objects in persistent
storage
Middleware
85
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
10/3/2015
Middleware
86
IDL Ground Rules
•
•
•
•
Case Sensitivity
IDL Definition Syntax
The Module
In addition to ,
– Comments
– Use of C preprocessor
– Coupling & cohension
10/3/2015
Middleware
87
PRIMITIVE TYPES
•
•
•
•
•
•
•
Void
Boolean
Char & wchar
Float
Double & long types
String
Const modifier
10/3/2015
• Integer types
– Long & long long
•
•
•
•
Middleware
Unsigned ..,.,.,.
Short
Unsigned short
octet
88
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
10/3/2015
Middleware
89
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.
10/3/2015
Middleware
90
Defining the Server Interfaces
( Define Interface as an IDL file )
• module SimpleStocks {
interface StockMarket {
float get_price( in string symbol );
};
};
10/3/2015
Middleware
91
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).
10/3/2015
Middleware
92
10/3/2015
Middleware
93
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
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 < symbol.length(); i++) {
price += (int) symbol.charAt( i );
}
price /= 5;
return price;
}
public StockMarketImpl() { super(); }
10/3/2015
Middleware
95
5. Implement and Compile the
server application.
6. Compile and Run the Client
application.
Descargar

Slide 1