enterprise and internet computing (distributed computing) stuart fitz-gerald with thanks to chris...

Enterprise and Internet Computing

(Distributed Computing)

Stuart Fitz-GeraldWith thanks to Chris Reade

Feb 2005

Enterprise and Internet - SFG 2

Overview

• Brief History of Enterprise Computing• Enterprise Computing Components

(e.g. Enterprise JavaBeans)• Communication for Distributed

Computing(inter-operability)

• Introducing Web services


Historical Perspective• Mainframes and Dumb Terminals

(applications run on mainframes)• Isolated PCs• Networks (2-tier Client/Server)

– applications run on PCs/ databases on servers– Problems

• fat client - applications rely on OS specific functions (e.g. GUI)• business logic on PCs• expensive to maintain (change management)• heavy communication• transactions conducted/controlled by client• security of info• distribution of updates problematic


Historical Perspective (ctd.)

• 3-tier (n-tier = at least 3-tier)– Move logic to servers– let clients just have GUI front ends

(presentation layer - could even be just Applets)

– Data-tier much as before– New Application Server tier in between


3 Tier Model

Presentation

Tier

(Clients)

Middle

Tier

(Business Logic

and Web Server)

Backend

Tier

(DataBases)

Business methods to be used by clients, e.g.doBankTransfer,createShoppingCart,addToShoppingCart


Middle Tier(s)

• Business Objects (contain business logic) • Components (configuarable objects), off-the-shelf• Design for re-use,• Easy maintenance and easy change management• Strategies for replacing legacy and updating

(wrapping)• Across all tiers

(but easier to manage through integration in middle tiers)– Security– Transaction processing (what is a transaction?)– System Management


Development of Components• Early: On PCs, applications needed to work together.

DLL problems lead to idea of shared components and communication between components. (e.g. OLE and later COM), but applications now tied to OS and hard to develop for more than one.

• Later: Distributed objects on different machines (e.g. COM+) compounded problem of platform dependence.

• A need arose for components to:– work over Heterogeneous network (TCP/IP)– use High level Communication which is not platform

specific(Platform independence not essential but different components may

be on different platforms.)

See support notes for names such as DCOM, ActiveX. These names associated with these definitions are subject to change.


What are Components?• Re-usable parts of applications designed for

– Divide/conquer, scalability, adaptability as well as reuse• Should be Decoupled as much as possible for better reuse and

easier replacement/update• Similar rationale as used for OO, but components are larger

scale Business/Application objects.

Enterpise Systems nearly all based on componentsBUT also require built-in support for 'Hard parts'

–Transaction Logic–Persistence–Security–Concurrency–(Performance)


Building Enterprises with Components

(Enterprise Computing = Distributed Computing)

• Example Component Models– COM, COM+ (Windows only)– Enterprise JavaBeans

(Platform independent - Java specific)– OMG Component Model (CORBA)

• object based, platform and lang independent

• Need to consider– Multi-platform (interoperability)– Communication between objects/components– Distribution of objects (mobile code)– Management of components (and support for'hard parts')


Enterprise JavaBeans• Session EJBs

– stateful (e.g. shoppingCart lasts for client session, keeps state)

– stateless (simpler, quicker , functional behaviour, e.g get info)

• Entity EJBs– Persistent objects

(used in Information/Database Tier e.g EmployeeEJB)• Containers

– Supporting Framework for Components (to manage 'hard parts') EJB container objects manage lifecycle, creation, etc of EJB instances (c.f. JavaBean Containers in GUIs) + transactions, security, management (configure, deploy, replace).

Note this approach takes effort away from enterprise developer, as hard parts are implemented by server vendor (middleware).


A Session EJB

myBean Home Interfaceextends EJBHome

myBean Remote Interfaceextends EJBObject

Home InterfaceRemote Interface

Client

EJB Server

EJB Container

RMI IIOP

RMI IIOP

myBeanImplementation

createremovepassivateactivate

getBalancedoTransfer


Distributed Transactions

• Bean Managed (Session only)– try { transaction.begin(); } catch ….

try{……transfer…. transaction.commit(); } catch ….

• Container Managed (Declarative Transaction Management)– not supported– supports– required– requires new– mandatory– never

Would like to treat a combination of many actions as a single atomic action (either not started or completed) - i.e. should rollback on failure.E.g. Bank transfer accessing 2 or more databases (must remain consistent)

Options attached to methodsin J2EE when deploying container


Communication Protocol Models

• RPC + IDL and Stubs (Pre OO)• COM/COM+

– Initially Windows only– Evolved from Desktop documents

• RMI (was Java only)• CORBA (OMG)

– Any platform– Any OO language (even non OO)– Evolved from distrib. OO

• RMI over IIOP (more recent in Java)(uses CORBA protocol)IIOP = Internet Inter-ORB Protocol

• XML based - SOAP and SOAP-RPC(Web Services)

Request/response OR messaging/queues (either can be implemented on top of the other)


Simplifying remote communication in programs

Single Machine - single program

prog1

f(a,b)

Server

service

f(a,b)

Client Machine

prog1

encode (a,b)make connectionsend request (f)listen for replydecode reply

listen for requestdecode args (a,b)call procedureencode resultsend result

Historically, RPC (remote procedure call) was a package implementing the complex details of encoding and decoding values plus the administration behind making a connection and request. (Implemented in C and other languages)


RPC issues

• Simplifies programmer's problems, but• Requires knowledge of Interface definition

language (IDL) to specify translation of various types of value (because server may not use same prog lang)

• Limited to small set of basic types of value• Tries to be, but cannot be, like local calls

(failures, delay, type limitations)


Remote Method Invocation (RMI)

RMI Generalised RPC to invoke methods of remote objects.Originally restricted to Java only at both ends, so much simpler to use and more powerful. (See CORBA and RMI IIOP for mixed languages).PLUS uses serialisation of objects (standardised encoding/decoding) to allow virtually any objects to be sent and returned as values.(False impression of local method invocation -still a problem)Server

service

Client Machine

prog1

lookup server urlcreate server object (serverob) using RmtExample interface

create implementationof RmtExample interface.Register as remote object

RMI

serverob.f(a,b)

common interface declaration...RmtExample …{Float f (Float a, Float b),..}

RMI


RMI example

//file: RmtServer.javaimport java.rmi.*;import java.util.*;

public interface RmtServer extends Remote { Date getDate( ) throws RemoteException; Object execute( WorkRequest work ) throws RemoteException;}

First, an interface (for some remote methods):

[Example from 'Learning Java']


RMI interface implementation on server

//file: MyServer.javaimport java.rmi.*;import java.util.*;

public class MyServer extends java.rmi.server.UnicastRemoteObject implements RmtServer { public MyServer( ) throws RemoteException { } // implement the RmtServer interface public Date getDate( ) throws RemoteException { return new Date( ); } public Object execute( WorkRequest work ) throws RemoteException { return work.execute( ); } public static void main(String args[]) { try { RmtServer server = new MyServer( ); Naming.rebind("NiftyServer", server); } catch (java.io.IOException e) { // problem registering server } }}


RMI (Client)

//file: MyClient.javaimport java.rmi.*;import java.util.*;

public class MyClient {

public static void main(String [] args) throws RemoteException { new MyClient( args[0] ); }

public MyClient(String host) { try { RmtServer server = (RmtServer) Naming.lookup("rmi://"+host+"/NiftyServer"); System.out.println( server.getDate( ) ); System.out.println( server.execute( new MyCalculation(2) ) ); } catch (java.io.IOException e) { // I/O Error or bad URL } catch (NotBoundException e) { // NiftyServer isn't registered } }}


CORBA(Common Object Request Broker Architecture -

1991)Language and Platform neutral way to access objects

• ORB receives 'request'– Must find implementation of appropriate object to handle request– Must prepare implemented object to deal with request (may need

to be 'started')– Must communicate data to complete request

• IDL (Interface Definition Language)– specifies how to communicate with an ORB– Syntax Spec language NOT an implementation

(therefore language neutral)

• ORB is used to access objects – on same machine – across network

An ORB is an implementation of CORBA spec.


ORB (across network)

ORB

IDLClient

IDLObject Impl

ORB

IDLClient

IDLObject Impl

Network

Several vendors for ORBs (inter-operable)


Using CORBATo provide objects/service for use over Internet:1. define the objects/service as interfaces in IDL (Interface

Definition Language),2. compile the IDL to generate client stub and server skeletons,3. implement the service and associate it with the skeletons via

the portable object adapter (POA),4. publish the service with a Naming or Trading Service for use

by clients.The use objects/service, client must:1. contact the Naming Service for the desired service and

retrieve the appropriate object reference,2. invoke operations on the object reference using the IDL-

compiler generated stubs. OR consult an interface repository (IR) and dynamically create requests using the dynamic invocation interface (DII),

3. process incoming reply or exceptions.


CORBA limitations

• CORBA is low common denominatorMissing advanced features (language specific)Higher Order, Event/Callback, Multicasting

• Asynchronous Message Passing needed as well(Loose coupling as well as tight coupling)

• Problems of too many threads on clients• IIOP / firewall problems• Deploying CORBA is complex • Inter-operability of ORBs from differnet vendors not as

good as it should be.

CORBA is still evolving and addressing some of these limitations (CORBA 3.0 Sept 2002), but also…


Web ServicesThe excitement over Web services is based largely on the potential for a combination of XML, the Web, the SOAP and WSDL specifications, and to-be-defined protocol stacks to address many of the problems these technologies have encountered. For example, distributed object systems such as Microsoft's COM family and the OMG CORBA standard did not interoperate, each presented numerous security and administration challenges when deployed over the internet, and neither quite meet the scalability expectations created by the Web. Various XML-based B2B systems have showed much potential, but created incompatible protocols on top of the internet standards which lead to interoperability problems. The Web has proven enormously popular, scalable, and interoperable, but it too presents many challenges -- reliability, security, database-level transactions, details of how to map platform-neutral data, URIs and HTTP operations to back-end application systems, and many others -- that must be handled by Web applications rather than some standardized infrastructure.

Quote from: W3C Web Services Architecture Document http://www.w3.org/TR/ws-arch


Web Services

• What?• Why?• Current Developments• Current Standards


For next time:

• Read references on Web Services noted in Module Diary

• Read about ebXML as well• Think about role of Web Services

enterprise and internet computing (distributed computing) stuart fitz-gerald with thanks to chris...

Documents

different components

internet sfgwhat

internet sfgdevelopment

tier ntier

tier clientserverapplications

distributed objects

idea of shared components

guibusiness logic