Chapter 3: Middleware Services

1. Overview of 10 important middleware services and examples in CORBA, RMI, JEE, Web Services and .NET (During the lesson, it will be indicated which parts are highly important and which are not important for the exam) Chapter 3: Middleware Services Design of Distributed Software

2. Overview • Naming Service • Event and Notification Service • Messaging Service • Persistence Service • Transaction Service • Activation Service • Loadbalancing Service • Session Tracking • Security Service • Dynamic Invocation Service Design of Distributed Software

3. 3.1 Naming Service Design of Distributed Software

4. Naming Service 1. Naming Service • Definition • Binding Service • Bind Object References to a textual name • Operations: • bind / rebind : registration by server • lookup / resolve : by client Design of Distributed Software

5. Java RMI : Registry 1. Naming Service • RMI registry must run on every server computer in the distributed system. • maps names to remote object references. • a name is represented as a string with format: //computerName:port/objectName • class java.rmi.Naming • public void bind(String name, Remote obj) • gives an exception when the name is already bound • public void unbind(String name, Remote obj) • public void rebind(String name, Remote obj) • when the name is already bound, the object reference is overwritten • public Remote lookup(String name) • public String[ ] list() • returns all names bound in the Registry Design of Distributed Software

6. JNDI 1. Naming Service • Java Naming and Directory Interface • Distributed version of RMI registry • applications based on Java technology can store and retrieve named Java objects of any type • JNDI provides methods for performing standard directory operations, • associating attributes with objects • searching for objects using their attributes • etc. • http://java.sun.com/products/jndi/reference/codesamples/index.html • http://java.sun.com/products/jndi/tutorial/ Design of Distributed Software

7. CORBA Naming Service 1. Naming Service • Registration of Object References • Names are structured in a hierarchy • cfr directories in file system • files and directories can be assigned a “Kind” id Namingservice 2 1 a 3 b server client Design of Distributed Software

8. CORBA server 1. Naming Service • Java class with Main method • Creates and initializes the ORB • Creates an instance of Servant class • Registers it to the ORB (through the connect method) • Gets a reference for the Naming Service • Registers the server to the Naming Service • Waits for incoming client requests Design of Distributed Software

9. CORBA Naming Service 1. Naming Service • NamingService implements an interface called NamingContext • rebind for servers to register the remote object references of CORBA objects by name (e.g. rebind (path, Object)) • resolve for clients to look them up by name.(e.g.Object = resolve(path)) • The names are structured in a hierarchy, • a path is an array of NameComponent (a struct with a name in it) • the path starts from an initial context provided by CORBA • Naming Service is available in all CORBA implementations Design of Distributed Software

10. Example ShapeListServer 1. Naming Service import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListServer { public static void main(String args[]) { try{ java.util.Properties props = System.getProperties(); ORB orb = ORB.init(args, props); ShapeListServant shapeRef = new ShapeListServant(orb); orb.connect(shapeRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path[] = {nc}; ncRef.rebind(path, shapeRef); orb.run(); } catch (Exception e) { ... } } } Design of Distributed Software

11. Example ShapeListClient 1. Naming Service import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListClient{ public static void main(String args[]) { try{ java.util.Properties props = System.getProperties(); ORB orb = ORB.init(args, props); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path [] = { nc }; ShapeList shapeListRef = ShapeListHelper.narrow(ncRef.resolve(path)); Shape[] sList = shapeListRef.allShapes(); GraphicalObject g = sList[0].getAllState(); } catch(org.omg.CORBA.SystemException e) {...} } Design of Distributed Software

12. Advanced Example (1) 1. Naming Service NameComponent[] contextName= new NameComponent[1]; contextName[0] = new org.omg.CosNaming.NameComponent(); contextName[0].id = "CORBA_test"; contextName[0].kind = “ODS_course"; // Note on kind: The kind field is used to indicate the type // of the object. This is to avoid conventions such as that used // by files (name.type -- e.g. test.ps = postscript etc.) org.omg.CosNaming.NamingContext testContext; try { // Bind the context to root, and assign testContext to it: testContext = rootContext.bind_new_context(contextName); } catch(org.omg.CosNaming.NamingContextPackage.AlreadyBound ex) { // If the context already exists, this exception will be raised. // In this case, just resolve the name and assign testContext // to the object returned: org.omg.CORBA.Object tmpobj; tmpobj = rootContext.resolve(contextName); testContext = NamingContextHelper.narrow(tmpobj); if (testContext == null) { System.err.println("Failed to narrow naming context."); return false;} } Design of Distributed Software

13. Advanced Example (2) 1. Naming Service // Bind the object (obj) to testContext, naming it Echo: org.omg.CosNaming.NameComponent[] objectName=new org.omg.CosNaming.NameComponent[1]; objectName[0] = new org.omg.CosNaming.NameComponent(); objectName[0].id = "Echo"; objectName[0].kind = "Object"; // Bind obj with name Echo to the testContext: try { testContext.bind(objectName,obj); } catch(org.omg.CosNaming.NamingContextPackage.AlreadyBound ex) { testContext.rebind(objectName,obj); } // Note: Using rebind() will overwrite any Object previously bound // to /CORBA_test.ATLANTIS_tests with obj. // Alternatively, bind() can be used, which will raise a // CosNaming::NamingContext::AlreadyBound exception if the name // supplied is already bound to an object. Design of Distributed Software

14. 1. Naming Service Running server and client with NS • Start orbd : • UNIX command shell : $ orbd -ORBInitialPort 1050 -ORBInitialHost nameserverhost & • MS-DOS system prompt : start orbd -ORBInitialPort 1050 -ORBInitialHost nameserverhost • Start the Echo server : • UNIX command shell : $ java echoServer -ORBInitialPort 1050 -ORBInitialHost nameserverhost & • MS-DOS system prompt : start java echoServer -ORBInitialPort 1050 -ORBInitialHost nameserverhost • Result: echoServer ready and waiting ... • Run the client application : • $ java echoClient -ORBInitialPort 1050 -ORBInitialHost localhost • ResuIt: I said, “Hello!“. The Object said, “Hello!" 1050 = port on which Naming Service listens Design of Distributed Software

15. CORBA Trading Service 1. Naming Service • Trading Service: • Comparable to Naming Service • Allows objects to be located by attribute : directory service • Database: service types and attributes -> remote object references • Clients specify : • Constraints on the values of attributes • Preferences for the order in which to receive matching offers Design of Distributed Software

16. Other Name Services 1. Naming Service • Web Services • URIs are used to locate the web services • DNS (Domain Name Service) • .Net • No distributed directory, but a local directory on each participating machine • Based on Web Services Design of Distributed Software

17. 3.2 Event and Notification Service Design of Distributed Software

18. Events and Notifications 2. Event/Notification Service MethodCall data A Method 1 Method 2 Method 3 Client Event or Notification Design of Distributed Software

19. 2. Event/Notification Service Publish - Subscribe paradigm • Object that generates events : publishes the type of events it will make available • Objects that want to receive notifications: subscribe to the types that are of interest (or: register) • Event types : refer to different operations of object generating events • Objects that represent events = notifications • Asynchronous communication between publishers and the subscribers Design of Distributed Software

20. Event type 2. Event/Notification Service • Each event has attributes: • Name or identifier of generating object • Operation • Parameters • Time • Sequence Number • Subscribing = • specify event types • criterion about attribute values Design of Distributed Software

21. subscriber object of interest 1. notification object of interest observer subscriber 2. notification notification object of interest observer subscriber 3. notification 2. Event/Notification Service Architecture for distributed event notification Event service Notification : object that contains information about event Observer : decouple the object of interest from its subscribers (forwarding, filtering, patterns of events, notification mailbox) Design of Distributed Software

22. CORBA Event Service 2. Event/Notification Service • Defines interfaces for: • Suppliers • Consumers • Push (by supplier to consumer) • PushConsumer interface {push (...);} • Consumer register their object references • Pull (by consumer from supplier) • PullSupplier interface { pull (...); } • Suppliers register their object references Design of Distributed Software

23. Event Service (2) 2. Event/Notification Service • Event Channels • Allow multiple suppliers to communicate with multiple consumers • Buffer between suppliers and consumers • EventChannel interface • implemented by objects in event server • Chains of event channels Design of Distributed Software

24. Notification Service 2. Event/Notification Service • Extends Event Service with filters • Notifications have datatype ( <-> any ) • Event Consumers may use filters • Specify events they are interested in • Proxies forward notifications to consumers according to constraints specified in filters • Event Suppliers can discover the events the consumer are interested in • Event Consumers can discover a set of event types (subscribe to new event) • Configure properties of Event Channel • Reliability, priority of events, required ordering, policy for discarding stored events • Event type repository Design of Distributed Software

25. 2. Event/Notification Service Eventing in other technologies • Java RMI / JEE • write callbacks • Java Message Service • Web Services • WS Eventing : W3C draft • defines a protocol for eventing • http://www.w3.org/Submission/WS-Eventing/ • .Net Framework • support comparable to JEE Design of Distributed Software

26. Intermezzo :EJB : Enterprise Java Beans I1. Architecture I2. Types of EJBs I3. Stateless Session Beans I4. Stateful Session Beans Design of Distributed Software

27. Introduction I1. Architecture EJB components • have the remote capabilities of RMI or CORBA objects • are JavaBeans components : • allow introspection of properties • JavaBeans “design patterns” for component layout (properties, accessors, modifiers, events, ...) • architecture provides non-functional features • component life cycle management, • transaction processing, • security handling, • persistence • remotability • timer • state management • resource pooling • messaging Design of Distributed Software

28. Introduction I1. Architecture container hosted on application server java beans interactions mediated by container interactions : - with other beans locally (same container) remotely (different container) - with other JEE components (servlets, jsp, ...) - with client - with other resources (e.g. database) EJB EJB EJB EJB-container Design of Distributed Software

29. Architecture I1. Architecture Client Webserver Application Server Database system Web container browser webserver applet applet EJB container Servlet JEE client JSP EJB • Web container services • component life cycle management • handle communication with webserver HTTP <-> servlet • session tracking • EJB container services • component life cycle management • transaction service • security handling • resource pooling Design of Distributed Software

30. Server side architecture I1. Architecture persistent application data [POJO] business logic Persistence provider Web container EJB container Java EE container Servlet JSP External Resource persistent application data [RDBMS] EJB Entity Design of Distributed Software

31. Benefits (1) I1. Architecture • simplify the development of large, distributed applications. • the EJB container provides system-level services to enterprise beans, • the bean developer can concentrate on solving business problems. • the EJB container--not the bean developer--is responsible for system-level services such as transaction management and security authorization. Design of Distributed Software

32. Benefits (2) I1. Architecture • the client developer can focus on thepresentation of the client • because the beans--and not the clients--contain the application's business logic, • the clients are thinner (important for clients that run on small devices) • enterprise beans are portable/reusable components • the application assembler can build new applications from existing beans. • these applications can run on any compliant J2EE server. Design of Distributed Software

33. EJB Views I1. Architecture • EJBs have two possible views: • The local view • Used by local clients (only EJBs in the same container) • The remote view • Used by remote clients (not limited to EJBs; can include Servlets, etc.) • Can also be used by clients in the same container • A bean can implement both local and remote views EJB EJB remote local Design of Distributed Software

34. The Local View I1. Architecture • New since EJB 2.0 spec • Parameters are passed by reference • The client and the EJB must reside in the same container • The client itself must be an EJB • Much faster than remote view • No network latency • No marshalling/unmarshalling • No need to worry about remote exceptions Design of Distributed Software

35. The Local View (cont.) I1. Architecture 1. Client looks up a bean object - using Java Naming and Directory Interface (JNDI) - using Dependency Injection (DI) 2. Client finds EJB 3. Client uses EJB business methods from the local interface JNDI service InitialContext client(EJB) BeanInstance EJBLocalObject EJB container Design of Distributed Software

36. The Remote View I1. Architecture • Based on Java RMI • Uses remote interface, stub, and tie (skeleton) • Works with RMI/IIOP (“RMI over IIOP”) • Vendor-specific protocols are also possible • Parameters are passed by value • All parameter and return-value types must be serializable • Provides location independence and flexibility • API design consideration (method granularity) : • One method that does several related tasks is more effective than several smaller methods Design of Distributed Software

37. The Remote View (cont.) I1. Architecture Same 3 steps as before, but taken over the network: JNDI service InitialContext BeanInstance client(EJB) EJBObject remote tie remote stub client container EJB container Design of Distributed Software

38. Intermezzo EJB : Enterprise Java Beans I1. Architecture I2. Types of EJBs I3. Stateless Session Beans I4. Stateful Session Beans Design of Distributed Software

39. Types of EJBs I2. Types of EJBs EJBs Session Beans Message Beans Entities • session related object • always associated to one single client at most • types • stateful : • “conversational state” • stateless • asynchronous message handling • new since J2EE 1.3 • “real life” object • mostly associated to “row in database” • persistent • NEW since EJB3.0 • [replace (very) complex EntityBeans] • - NOT managed by EJB container synchronous asynchronous Design of Distributed Software

40. Session EJBs I2. Types of EJBs • A session bean instance is: • A non-persistent object • Implements some business logic (“procedural component”) • Runs on the server • Not shared among multiple clients Design of Distributed Software

41. Stateful Session EJBs I2. Types of EJBs • A stateful session bean maintains a state • values of its instance variables • also called : conversational state • The state is relevant only for a single client • cannot be seen by other clients • The state is not persistent • does not survive a server shutdown • when the client removes the bean or terminates, the session ends and the state disappears • Canonical example: ShoppingCart Design of Distributed Software

42. Stateless Session EJBs I2. Types of EJBs • Conceptually, the same as stateful session EJBs • No state • http-style request – reply interaction • Can have fields, but they are not unique to any client • Basically, it’s an optimization trick: • Since the container knows the bean has no state, it can: • Use a single bean instance (While each client thinks it has its own copy) • Destroy/re-instantiate on the fly • Redirect requests to different instances (load balancing) • Example: CurrencyConversionBean Design of Distributed Software

43. Entities I2. Types of EJBs • Object-oriented view of entities stored in persistent storage • Normally, each entity represents a row in a relational DB table • Persistence code generated through ORM-tool (Object-Relational Mapping, e.g. Hibernate, TopLink) • A single instance (on the server) can be accessed by multiple clients • Unlike stateful session EJBs • Each instance must be uniquely identifiable by means of a primary key. Design of Distributed Software

44. Message Driven Beans (MDBs) I2. Types of EJBs • process messages asynchronously • messages originate from JMS (Java Messaging Service)-compliant system • message can be sent by any source • other EJB • other JEE component (e.g. web component) • any other (legacy) component • indirectly accessed by clients • no interface, use message instead • similar to stateless session bean • all beans are equivalent (pooling !) – no client specific state • no conversational state maintained • can handle requests from multiple clients JMS queue MDB Client Design of Distributed Software

45. Bean packaging I2. Types of EJBs Bean contents • deployment descriptor (XML) [deploytool] • enterprise bean class (bytecode) [programmer] • interfaces [IDE] • local/remote • helper classes (utilities/exceptions/...) [programmer] EJB JAR-file JEE-application EJB JAR-file EAR-file deployable units toapplication server WAR-file Design of Distributed Software

46. Deployment descriptor I2. Types of EJBs • essentially contains meta-data of application/component • cumbersome to construct/maintain • alternative : Annotations • BUT : deployment descriptor can still override annotations @ = + JEE component POJO Design of Distributed Software

47. Naming Conventions I2. Types of EJBs syntax example bean name <name>Bean ExampleBean bean class <name>Bean ExampleBean remote [component] interface <name>Remote ExampleRemote local [component] interface <name>Local ExampleLocal Design of Distributed Software

48. IntermezzoEJB : Enterprise Java Beans I1. Architecture I2. Types of EJBs I3. Stateless Session Beans I4. Stateful Session Beans Design of Distributed Software

49. Session Bean services I3. Stateless SB • Thread safe and performant concurrency (techniques : pooling, session management, passivation – activation) • Remoting • Exposure as Web Service • Transaction Management • Security Management • Timer services (scheduling) Design of Distributed Software

50. Session Bean in EJB2.0 I3. Stateless SB public class MyBean implements javax.ejb.SessionBean,BeanInterface { private javax.ejb.SessionContext context; public void setSessionContext(javax.ejb.SessionContext aContext) { context = aContext; } // called when created public void ejbActivate() { } // called when activated public void ejbPassivate() {} // called when passivated public void ejbRemove() { } // called when removed from server public void ejbCreate() { } // called when created // business methods } • implements the SessionBean + BeanInterfaceinterface • is public • is NOT abstract or final • at least one ejbCreate method • implements required business methods (component i’face) • does NOT have a finalize method Design of Distributed Software