1. Santa & CCM Jeff Parsons 1 Santa Claus and the CORBA Component Model Jeff Parsons November 2, 2005

2. Santa & CCM Jeff Parsons 2 A Child’s Innocent Christmas

3. Santa & CCM Jeff Parsons 3 Just Beneath The Surface Client – Role played by software that sends a request. Server – Role played by software that receives and processes a request. ORB (Object Request Broker) – Hides details of sending/receiving requests. Client & Server each start one up. Object – OO concept + distributed. Object Reference – String of info about connecting/sending to Server. Understood only by ORBs. Proxy – Local (to Client) stand-in for Server. Associated with an Object Reference by the Client’s ORB.

4. Santa & CCM Jeff Parsons 4 A Child’s CORBA Christmas 2. Proxy sends request 1. Server gets request 3. Client thread blocks 2. Server processes request 3. Server sends reply 4. Proxy gets reply 1. Client makes request on Proxy 5. Proxy returns reply to Client

5. Santa & CCM Jeff Parsons 5 Digging Deeper Servant – Local to Server, does the actual execution of the “function body”. Dispatch (verb) – To guide received requests to Servants. POA (Portable Object Adapter) – Part of Server’s ORB, does the Dispatching.

6. Santa & CCM Jeff Parsons 6 “There Ain’t No Santa Claus” “Household” POA Lookup Dispatch Servants (parents) Execute

7. Santa & CCM Jeff Parsons 7 A CORBA-Enhanced Christmas ORBs make remote calls look like local ones Definition language for Client/Server interface –Enables the generation of boilerplate code –Guides the application developer POA policies enable flexibility in dispatching –Single parent –Alternating custody –Extended family household –Multiple Clients (children) –Etc.

8. Santa & CCM Jeff Parsons 8 Scaling and Expanding POA policies multiply –X each policy type used –X each POA Client and Server roles intermingle –Shopping for presents In stores Online By phone –Optimizing efficiency Item in stock? Best price?

9. Santa & CCM Jeff Parsons 9 Refining and Enhancing Servant Configuration –Shopping concurrency –IPC –Replication Multiple Christmas QoS Requirements –Wrapping presents –Setting up Christmas tree –Completing tasks by Christmas Eve deadline –Keeping the Santa Claus implementation secret from the child (maybe)

10. Santa & CCM Jeff Parsons 10 What Are We Lacking? A systematic way of describing an object’s relationship to its environment. –Many standardized services exist –Use of these services is still ad hoc A more expressive way of describing relationships between objects. –All we have now is inheritance –Language independence limits its usefulness A way of reducing the proportion of hand-written code.

11. Santa & CCM Jeff Parsons 11 The Component And Its Parts Component – New centerpiece, Objects now play a more supportive role. Can be written by 3 rd party. –Attribute - More clearly intended for configuration. –Port – General term for interaction mechanism. Facet – Interface provided to Clients or other Components. Receptacle – Interface required by this Component. Event Source – Sends (publishes) asynchronous Events. Event Sink – Receives (subscribes to) asynchronous Events.

12. Santa & CCM Jeff Parsons 12 Component + Container Home – Configurable “factory” for Components. –Create –Retrieve from repository Container – Component’s virtual environment. –ORB –POA(s) –Services Selected from spec-defined or custom services. May mediate port activity

13. Santa & CCM Jeff Parsons 13 A Child’s Component-Aware, Network-Centric Christmas

14. Santa & CCM Jeff Parsons 14 Where We Started: Object-Oriented Programming Object-oriented (OO) programming simplified software development through higher level abstractions & patterns, e.g., Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, elegance –Decoupling interfaces & implementations –Associating related data & operations operation1() operation2() operation3() operationn() data class X

15. Santa & CCM Jeff Parsons 15 Motivations for Applying OO to Network Programming Abstract away lower-level OS & protocol-specific details for network programming Create distributed systems which are easier to model & build Result: robust distributed systems built with distributed object computing middleware –e.g., CORBA, Java RMI, etc. 11 Proxy service Service service AbstractService service Client We now have more robust software & more powerful distributed systems operation() Object : Class X : Client Middleware

16. Santa & CCM Jeff Parsons 16 Overview of CORBA CORBA is distributed object computing middleware that shields applications from heterogeneous platform dependencies e.g., languages, operating systems, networking protocols, hardware CORBA simplifies development of distributed applications by automating/encapsulating – Object location – Connection & memory mgmt. – Parameter (de)marshaling – Event & request demultiplexing – Error handling & fault tolerance – Object/server activation – Concurrency – Security CORBA defines interfaces, not implementations

17. Santa & CCM Jeff Parsons 17 Example: Applying OO to Network Programming CORBA IDL specifies interfaces with operations – Interfaces map to objects in OO programming languages e.g., C++, Java, Ada95, etc. –Operations in interfaces can be on local or remote objects interface Foo { void MyOp (in long arg); }; IDL class Foo : public virtual CORBA::Object { virtual void MyOp (CORBA::Long arg); }; C++

18. Santa & CCM Jeff Parsons 18 Limitations of OO-based CORBA Middleware CORBA does not specify how “configuration” & “deployment” of object implementations should be done to create complete applications –Proprietary infrastructure & scripts are usually written to facilitate this CORBA IDL does not provide a way to logically group together related interfaces to offer a specific service –Such “bundling” must be done by developers

19. Santa & CCM Jeff Parsons 19 Boiler Plate X Boiler Plate YBoiler Plate X Example: Limitations of CORBA 2.x Specification Requirements of non-trivial applications: –Collaboration of multiple objects & services –Deployment on diverse platforms Limitations – Lack of standards for –Server configuration –Object/service configuration –Application configuration –Object/service deployment Consequences – tight couplings at various layers –Brittle, non-scalable implementation –Hard to adapt & maintain –Increase time-to-market Server ORB/POA Obj Impl Server ORB/POA Obj Impl COS Svc Server ORB/POA Obj Impl COS Svc Client CORBA BUS invoke Config CConfig C Config BConfig B Config AConfig A

20. Santa & CCM Jeff Parsons 20 Solution Approach: Component Middleware Component middleware capabilities: Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces Define standard container mechanisms needed to execute components in generic component servers Specify the infrastructure to configure & deploy components throughout a distributed system

21. Santa & CCM Jeff Parsons 21 Components encapsulate application “business” logic Components interact via ports Provided interfaces, e.g.,facets Required connection points, e.g., receptacles Event sinks & sources Attributes Containers provide execution environment for components with common operating requirements Components/containers can also Communicate via a middleware bus and Reuse common middleware services SecurityReplicationNotificationPersistence SchedulingA/V StreamingLoad Balancing … Container … … Middleware Bus Container … Overview of Component Middleware

22. Santa & CCM Jeff Parsons 22 Object Model – IDL Only Interface Definition Language (IDL) + compiler generates code to – Create and manage connections – Send and receive data Problem: Generic lifecycle & initialization server code must be handwritten Ad hoc design Code bloat No reuse

23. Santa & CCM Jeff Parsons 23 Component Model – IDL + CIDL Solution: Component Implementation Definition Language (CIDL) is part of CCM strategy for managing complex applications Helps separation of concerns Helps coordination of tools Increases the ratio of generated to hand-written code Server code is now generated, startup automated by other CCM tools delegates

24. Santa & CCM Jeff Parsons 24 Deployment and Configuration 1/2 Platform-Independent Model (PIM) Three broad areas – software, target, execution Defined in two dimensions PIMData ModelRun-time Model Component Software Meta-data to describe component based applications and their requirements Interfaces to browse, store and retrieve such meta-data TargetMeta-data to describe heterogeneous distributed systems & their capabilities Interfaces to collect & retrieve such meta-data and commit resources ExecutionMeta-data to describe a specific deployment of an application into a distributed system Prepare environment, Execute on target to Deployment plan, manage lifecycle

25. Santa & CCM Jeff Parsons 25 Deployment and Configuration 2/2 XML schema and file extensions capture the various kinds of packaging, configuration and deployment information –Component Package Descriptor:.cpd –Component Implementation Descriptor:.cid –Implementation Artifact Descriptor:.iad –Component Interface Descriptor (CORBA Component Descriptor):.ccd –Component Domain Descriptor.cdd –Deployment Plan Descriptor (Component Deployment Plan):.cdp –Top Level Package Descriptor package.pcd –ZIP file containing all of above + binaries.cpk

26. Santa & CCM Jeff Parsons 26 D&C Actors Different stages & different actors –Development Specifier/ Developer Assembler Packager –Target Domain Administrator –Deployment Repository Administrator Planner Executor Actors are abstract –Usually humans & software tools Development Target Deployment Domain Accesses Resources Assembler Planner Domain Administrator Specifies Creates Component Resource Requirements Impl Properties COMPONENT REPOSITORY QoS Specs Configurations Dependencies Specifier/Developer Creates Component Assembly Component CreatesPackager Repository Administrator Component Packages Configures Desktop Printer Laptop computer Ethernet Bridge Firewall Creates Executor Deployment Plan Uses Deploys These actors & stages are simply making explicit existing processes

27. Santa & CCM Jeff Parsons 27 An Evolving Specification Deployment and Configuration –Recently revised by OMG. –IDL and XML schema versions published. –Revised Component Assembly concept more powerful. Lightweight CORBA Component Model –Tailored for embedded systems. –Prunes away parts of spec oriented toward enterprise applications. Research feedback can influence evolution.

28. Santa & CCM Jeff Parsons 28 Questions?

29. Santa & CCM Jeff Parsons 29 Current Work – The ARMS Project Adaptive Reflective Middleware System Goal – design and implement Total Shipboard Computing Environment (TSCE). –“Stealth” ship. –Crew size 1/3 that of similar size ships. –~1000 nodes, ~5000 applications in multi-level network. TSCE will adapt to mission modes (port, navigation, battle) and to battle damage. TSCE-wide Dynamic Resource Management (DRM) system uses components. –Lockheed-Martin –BBN –Vanderbilt/ISIS –Raytheon –Johns Hopkins –Telcordia –SRC –University of Ohio –University of Illinois –Boeing