Introduction to Distributed Component Models

1. Introduction toDistributed Component Models Tomasz Haupt

2. Overview • What is a software component? • Two examples: AWT and JavaBeans • Distributed objects: CORBA • Distributed components: EJB • Academic example: WebFlow

3. What is a component? • Very intuitive, but often vaguely defined • A semiconductor chip is a component The chip vendor publishes manuals that tell developers the functionality of each pin A0-A16 I/O Address bus D0-D8 I/O Data bus ACK O Acknowledge: Accepted when low

4. Component one Component two Building complex systems • Hardware system integrators connect pins of chips together according to their functions to build complex electronic devices such as computers. • Pins functionality defines behavior of the chip. • Pins functionality is standardized to match functionality of the board (and take advantage of common services).

5. Component one Component two Software components • The software component model takes a very similar approach: • the “pins” of software components are called interfaces • an interface is a set of methods that the component implements • software integrators connects components according to the descriptions of the methods within the interface. component’s interface methods

6. Software components (2) • Component technology is still young, and there isn’t even agreement on the definition of its most important element - the component. • “a component is a software module that publishes or registers its interfaces”, a definition by P. Harmon, Component Development Strategy newsletter (1998). • Note: a component does not have to be an object!An object can be implemented in any language as long as all the methods of its interface are implemented. • Often COM (Microsoft) components are not objects. • For Java developer, a component is a specialized object.

7. Component one Component two Component wiring • The traditional programming model is caller-driven (application calls methods of a component’s interface, information is pulled from the callee as needed). Component never calls back. • In the component programming model, connecting components may call each other (connection-oriented programming). • The components can interacts with each other through event notification (a component pushes information to another component as some event arises). This enables wiring components at runtime.

8. Pragmatic definition • Software Components: • predictable behavior: implement a commoninterface • embedded in a framework that provides common services (events, persistence, security, transactions,…) • developer implements only business logic

9. Examples of component models • Before discussing distributed components let us see our definition at work: • AWT components • JavaBeans

10. AWT Component model:common behavior Java.lang.Object everything in Java is an object Java.awt.Component specialized object; knows its position on the screen, how to paint itself, knows its parent, fires events Java.awt.Button Java.awt.Canvas Java.awt.TextArea Java.awt. Container specialized component type that can contain other AWT components; methods: add, remove, getComponents Java.awt.Panel Java.awt.Window Java.awt.Frame Start Save Submit Exit This is a text area. The user can display andmodify a text

11. AWT Component model:common behavior Java.lang.Object everything in Java is an object Java.awt.Component specialized object; knows its position on the screen, how to paint itself, knows its parent, fires events Java.awt.Button Java.awt.Canvas Java.awt.TextArea Java.awt. Container specialized component type that can contain other AWT components; methods: add, remove, getComponents Java.awt.Panel Java.awt.Window Java.awt.Frame Predictable behavior Framework: event mechanism

12. JavaBeans: Power of the container • Generic Java objects that follow the JavaBeans coding conventions. This allows introspection. Thus no specific “common interface”. • Container (environment in which beans live • BeanBox, JSP, Java Development Environment) • discovers bean properties, methods and events • properties editors (bean customization) • event based communication • persistence (object serialization) • Take an off-shell bean and use it in your application

13. Class A { B b =new B(); Object c = b.m(); } Class B { Object m() {…; return Object o}; } ? Distributed objects • What if the objects live in different address spaces? • Standard Java method invocation will not work. We need a remote method invocation (RMI) mechanism.

14. Distributed Objects (2) Class A { B b =new B(); Object c = b.m(); } CLIENT Class B { Object m() {…; return Object o}; } SERVER interface B { Object m() ; } Class A { B b =new b(); Object c = b.m(); } Class Bimpl implements B { Object m() {…; return Object o}; Class StubB implements B { Object m() { send request; return Object o;} } Class skeletonB { receive request; Object o = B.m(); send(o); }

15. Distributed Objects (3): CORBA ORB: object request broker Vendor provided classes interface B { Object m() ; } Class StubB implements B { Object m() { send request; return Object o;} } Class skeletonB { receive request; Object o = B.m(); send(o);} IIOP INTERNET INTER-ORB PROTOCOL Language independent IDL (Interface Definition Language) Server Client Class A { B b =new B(); Object c = b.m(); } Class Bimpl implements B { Object m() {…; return Object o};

16. CORBA IDL • Language independent, totally declarative language to define object interface (contract with a potential client) • The IDL grammar is a subset of C++ with additional keywords to support distributed concepts • Can be mapped to many languages, including Java BTW: Java RMI does not need IDL; DCOM uses binary interfaces

17. package Example IDL Java Module MyAnimals { interface Dog:Animal { attribute integer age; exception NotInterested {string explanation}; void Bark(in long how_long) raises (NotInterested); void Sit(in string where) raises(NotInterested); } interface Cat:Animal{ string saySomething(); } } String Java int Java

18. Interface Repository Implementation Repository Client Stubs Server Stubs Object Implementations Developing CORBA applications Create IDL definitions Developer’s Task IDL precompilation Extend Skeleton or implement interface Object Implementation Compilation Object Adapter Client Server

19. Dynamic CORBA Responsible for life cycle of server objects Dynamic Stub Invocation (DSI) and Dynamic Skeleton Invocation (DII) allows constructing applications at runtime, without prior knowledge of stubs and skeletons. Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons

20. Yes, you have seen this slide! Distributed Objects (3): CORBA ORB: object request broker Vendor provided classes interface B { Object m() ; } Class StubB implements B { Object m() { send request; return Object o;} } Class skeletonB { receive request; Object o = B.m(); send(o);} IIOP Language independent IDL (Interface Definition Language) Server Client Class A { B b = new B(); Object c = b.m(); } Class Bimpl implements B { Object m() {…; return Object o}; B b = getObjectReference(…);

21. How to get an object reference • IOR: interoperable object reference • part of IIOP definition • includes all information needed to invoke • created when the object is created • orb.object_to_string(o); • can be stored in a file (make sure that is not stalled!) • maintained by the CORBA naming service

22. Simple Client Public class Client { public static void main(String args[]) { ORB orb = ORB.init(args, new java.util.Properties(...)); String masterURL = args[0]; String ref=getIORFromURL(masterURL); org.omg.CORBA.Object obj=orb.string_to_object(ref); MyRemoteObject mro=MyRemoteObjectHelper.narrow(obj); mro.method(); } Instantiate ORB (vendor specific) Read IOR from a web server Deserialize IOR Generated by JIDL Ready to use

23. CORBA: the Big Picture Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons

24. Distributed Component Models • Hide implementation details • Remove vendor dependencies • Bring power of a container • Focus on business logic • Enable development of third-party interoperable components

25. Enterprise JavaBeans • Java objects that implement EJB interfaces • Container that provides environment for beans • implements common object services such as life cycle, security, naming, persistence, communication, transaction processing, resource pooling, … • provides tools or bean development such as idl compiler

26. Enterprise JavaBeans (2)CORBA enthusiast’s view Off-shell Beans Custom Beans EJB Container Of course, can be implemented in pure Java (RMI, JNDS,…)

27. home interface remote interface home interface remote interface EJB home stub EJB remote stub EJB home EJB object Enterprise JavaBeans (3) server client EJB container EJB bean EJB bean implements only business logic

28. Enterprise JavaBeans (4) • Home interface: • provides methods for a client to create, locate, and destroy EJB objects that it uses • Remote interface: • defines business methods of the bean

29. Types of Components • Sessions beans • provide business logic to a client, is accessed by a single client at a time and is nonpersistent. • Entity beans • representation of persistent data, it can be accessed by multiple clients concurrently. • Note: • COM: only session components • CCM: services, sessions, processes and entities

30. WebFlow Component Model • Developed at NPAC, Syracuse University • most of coding done by Erol Akarsu • Used to implement the Middle Tier of computational Web portals • Build on top of CORBA • Exploits both common behavior and power of the container

31. Compare AWT and WebFlow Org.omg.CORBA.Object WebFlow Component specialized CORBA object implements BeanContextChild WebFlow Module WebFlowContext (a Container) can contain other WebFlow components responsible for life cycle, persistency, communications Java.lang.Object everything in Java is an object Java.awt.Component specialized object; knows its position on the screen, how to paint itself, knows its parent, fires events Java.awt.Button Java.awt.Canvas Java.awt.TextArea Java.awt. Container specialized component type that can contain other AWT components; methods: add, remove, getComponents Java.awt.Panel Java.awt.Window Java.awt.Frame

32. Application A Host B Host A Application C Context B Host C Module B Host D Module A Context C Context D Module C1 Module C2 Module D WebFlow Distributed Applications

33. WebFlow component model • A WebFlow component is a CORBA object implemented in Java • A WebFlowContext object implements an extended BeanContext interface, maintains a persistent state, controls its children life-cycle, and is responsible for inter-JVM communications through a custom event model. The master (“root”) context maintains a hierarchy of proxy objects to facilitate communication with clients implemented as Java applets without violating the sandbox restrictions.Acts both as a CONTAINER and an ENTITY component. • A WebFlow Module implements BeanContextChild interface, is stateless (more precisely, it maintains a conversational state), and has access to all data maintained by its parent context.Acts as a SESSION component.

34. WebFlow Contexts and Modules (2) Org.omg.CORBA.Object WebFlow Component specialized CORBA object implements BeanContextChild WebFlow Module WebFlowContext (a Container) can contain other WebFlow components responsible for life cycle, persistency, communications User Context Problem Context Session Context Job context code descriptor, job id, date submitted, completed, input file(s), output file(s) A module in a context extends the context functionality

35. User Context Credentials (proxy) profile Session Context Job object Job object Job object Middle Tier Components Task Specification PSEsupport context lifecycle access control Component Container XML parser data analysis resource broker Multi-disciplinary task control data flow manager NetSolve Linear Algebra proxy batchscriptgenerator Fileaccess &transfer Informationservices job control archivization databaseaccess Resource Specification

36. WebFlow Events • WebFlow components (modules) are developed independently of each other. • They can interact with each other through WebFlow events. (They can use remote invocation, but it requires the caller to have reference to the target module, which violates the WebFlow “module independence” rule). • There is only one type of WebFlow events. An event is an (self-describing) object that encapsulates data to be transferred from one module to another. • Each module can serve as a sink. • Event sources and sinks are associated at run time.

37. EventAdapter usesCORBADSI,DII Context 1 A Event e Client WebFlow Events A B B Method m Dynamic Interfaces Context 2 Method m is a public method: anyone can invoke it, including the Event Adapter of Context 1.No protection against misuse! Module A does not care who is expecting the event; method fire Event invokes a method of its parent context

38. Summary • A pragmatic definition of software components: • predictable behavior: implement a commoninterface • embedded in a framework that provides common services (events, persistence, security, transactions,…) • developer implements only business logic

39. Summary (2) • Best known distributed component models: • DCOM (Microsoft) • Enterprise JavaBeans (Sun Microsystems) • CCM: CORBA Component Model (OMG) • Academic example: • WebFlow system

40. End

41. Distributed Objects are less secure • can play both client and server • in client/server you trust the server, but not the clients • evolve continually • objects delegate parts of their implementation to the other objects (also dynamically composed at runtime). Because of subclassing, the implementation of an object may change over time • interactions are not well defined • because of encapsulation, you cannot understand all the interactions between objects • are polymorphic (ideal for Trojan horses!) • can scale without limit • how do you manage the access right to millions of servers? • are very dynamic

42. CORBA security is built into ORB Client Server Object Adapter ORB Credentials Authentication Encryption Encryption Audit Authorization Secure Communications

43. Authentication • A principal is authenticated once by ORB and given a set of credentials, including one or more roles, privileges, and an authenticated ID. • An authenticated ID is automatically propagated by a secure ORB; it is part of the caller context Client Server authenticate Principal Credentials Current set_credentials get_attributes

44. Privilege Delegation Client Target Object Target Client Target Client Target Client • No delegation • The intermediary uses its own credentials • Simple delegation • The intermediary impersonates the client • Composite delegation • The intermediary uses both IIOP

45. Secure CORBA connection client server Instantiate ORB (creates credentials object) get IOR and deserialize (server authentication) make request receive request (ORB appends the current (decryption and encrypts) =binding= client authentication) (client authorization)