Mc9251 Notes

Middleware Technologies

MC9251

04/20/23 Middleware 2

Unit-I IntroductionMiddleware• 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


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


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


Client-server architecture - Static HTML pages


Client-server - CGI Scripts


Server side scripting technologies


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


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


Client-Server Architecture Characteristics

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


Types of Servers

• File server

• Database server

• Transaction server

• Group server

• Object server

• Web server


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


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


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)


Groupware Server

• Addresses the management of semi-structured information

• Applications are created using a scripting language and form based interfaces


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• CORBA - Object management Group• Dcom - Microsoft• SOM - IBM• NEO - SUN


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.


Client/Server building blocksArchitecture 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?


The Basic Building Blocks

• Components: – Client – Server – Middleware and is catered for


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


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


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


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


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


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


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

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


Transaction processor• Provides API with ‘begin’, ‘commit’, and

‘rollback’.

• Logging mechanism

ACID properties of Transactions

• Atomicity

• Consistency

• Isolation

• Durability


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


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


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 objectsRMI• Java version of CORBA• No need to write IDL. RMIC handle

automatically• EJB allows client side RMI calls to EJB

objects


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


• 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.


• 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.


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 - EJB Server - Database


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


Overview of EJB’s Software Architecture

• EJB bean exists within the container

• Client communicates with bean through home interface, remote interface


Overview of EJB’s Software Architecture

EJB server • Provides container with lower level services

such as network connectivity• Layered approachEJB 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


Enterprise Bean

• EJB object is implemented, in addition Home interface and Remote interface implemented

Types of EJB beans


• 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


• 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.


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

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


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


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


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)


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)


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.



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.


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


• 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


• 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


Entity Bean Life cycle


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


UNIT – 4

CORBA


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


CORBACommon 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


•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


HISTORY OF DISTRIBUTED SYSTEMS

• MONOLITHIC SYSTEMS & MAINFRAME

• 2TIER CLIENT/SERVER ARCHITECTURE

• MULTI TIER C/S (OR) DISTRIBUTED SYSTEMS


Monolithic Systems and Mainframes


Two-tier client/server architecture


Multi-tier C/S – Distributed Systems


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


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


Architecture overview

An Object Oriented architecture

• Object Request Broker

• Interface Definition Language

• Communications Model

• Clients and Servers, Stub and skeleton


CORBA ARCHITECTURE


Object Request Broker (ORB)

–Facilitates communication between objects

–Locates a remote object upon a reference

–Marshals and un-marshals parameters

–Platform independent format


• 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.


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.


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


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.


CORBA Networking( COMMUNICATIONS)

Model• network model

• Object model


N/W MODEL

• Inter-ORB protocolsGeneral 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


CORBA Object Model

Object Distribution A CORBA client, a remote

method call looks exactly like a local method call

Object ReferenceBasic Object Adapters


OBJECT REFERENCE

• 2 possible ways call by value Call by

reference

OMG’S ORB USES CALL BY REFERENCE


BASIC OBJECT ADAPTERS• purpose :To interface an object's

implementation with its ORB.

• PROVIDES 3 object ADAPTER types

Basic Object Adaptersprovides set of methods for accessing ORB

functions

Library Object AdaptersOO Database Adapters

useful for accessing objects in persistent storage


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


IDL Ground Rules

• Case Sensitivity

• IDL Definition Syntax

• The Module

• In addition to ,– Comments– Use of C preprocessor– Coupling & cohension


PRIMITIVE TYPES

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

• Integer types– Long & long long

• Unsigned ..,.,.,.• Short• Unsigned short• octet


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


Building a CORBA ApplicationThe 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.


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

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


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).

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(); }

5. Implement and Compile the server application.

6. Compile and Run the Client application.

Mc9251 Notes

Documents

Transcript of Mc9251 Notes