Introduction to Distributed Component Models Tomasz Haupt Overview

Introduction to Distributed Component Models Tomasz Haupt

Overview • • • What is a software component? Two examples: AWT and Java. Beans Distributed objects: CORBA Distributed components: EJB Academic example: Web. Flow

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 A 0 -A 16 D 0 -D 8 ACK I/O Address bus I/O Data bus O Acknowledge: Accepted when low

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

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 Component one component’s interface Component two methods – software integrators connects components according to the descriptions of the methods within the interface.

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.

Component wiring Component one Component two • 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.

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

Examples of component models • Before discussing distributed components let us see our definition at work: – AWT components – Java. Beans

AWT Component model: common behavior Java. lang. Object everything in Java is an object Java. awt. Component Start Save Submit Exit This is a text area. The user can display and modify a text 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. Text. Area Java. awt. Container specialized component type that can contain other AWT components; methods: add, remove, get. Components Java. awt. Panel Java. awt. Window Java. awt. Frame

AWT Component model: common behavior Java. lang. Object everything in Java is an object Java. awt. Component Predictable behavior Framework: event mechanism 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. Text. Area Java. awt. Container specialized component type that can contain other AWT components; methods: add, remove, get. Components Java. awt. Panel Java. awt. Window Java. awt. Frame

Java. Beans: Power of the container • Generic Java objects that follow the Java. Beans coding conventions. This allows introspection. Thus no specific “common interface”. • Container (environment in which beans live – Bean. Box, 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

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

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

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

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

package Java Example IDL Module My. Animals { String interface Dog: Animal { Java attribute integer age; exception Not. Interested {string explanation}; int Java void Bark(in long how_long) raises (Not. Interested); void Sit(in string where) raises(Not. Interested); } interface Cat: Animal{ string say. Something(); } }

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

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

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

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

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

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

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

Enterprise Java. Beans • 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

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

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

Enterprise Java. Beans (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

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

Web. Flow 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

Compare AWT and Web. Flow 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. Text. Area Java. awt. Container specialized component type that can contain other AWT components; methods: add, remove, get. Components Java. awt. Panel Java. awt. Window Java. awt. Frame Org. omg. CORBA. Object Web. Flow Component specialized CORBA object implements Bean. Context. Child Web. Flow Module Web. Flow. Context (a Container) can contain other Web. Flow components responsible for life cycle, persistency, communications

Web. Flow Distributed Applications Application A Host B Host A Application C Context B Host C Module A Module B Context C Module C 1 Host D Context D Module C 2 Module D

Web. Flow component model • A Web. Flow component is a CORBA object implemented in Java • A Web. Flow. Context object implements an extended Bean. Context 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 Web. Flow Module implements Bean. Context. Child 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.

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

Middle Tier Components Task Specification Component Container User Context Credentials (proxy) profile PSE support context lifecycle XML parser data flow manager Multidisciplinary task control Session Context Job object File access & transfer access control Information services resource broker batch script generator job control Resource Specification data analysis Net. Solve Linear Algebra proxy archivization database access

Web. Flow Events • Web. Flow components (modules) are developed independently of each other. • They can interact with each other through Web. Flow events. (They can use remote invocation, but it requires the caller to have reference to the target module, which violates the Web. Flow “module independence” rule). • There is only one type of Web. Flow 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.

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

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

Summary (2) • Best known distributed component models: – DCOM (Microsoft) – Enterprise Java. Beans (Sun Microsystems) – CCM: CORBA Component Model (OMG) • Academic example: – Web. Flow system

End

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

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

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 authenticate Principal Client Server Credentials set_credentials Current get_attributes

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

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