1 / 29

Santa Claus and the CORBA Component Model

Santa Claus and the CORBA Component Model. Jeff Parsons November 2, 2005. A Child’s Innocent Christmas. Just Beneath The Surface. Client – Role played by software that sends a request. Server – Role played by software that receives and processes a request.

duscha
Download Presentation

Santa Claus and the CORBA Component Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. A Child’s Innocent Christmas

  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. A Child’s CORBA Christmas 1. Client makes request on Proxy 1. Server gets request 2. Proxy sends request 2. Server processes request 3. Client thread blocks 4. Proxy gets reply 3. Server sends reply 5. Proxy returns reply to Client

  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. “There Ain’t No Santa Claus” “Household” POA Lookup Dispatch Servants (parents) Execute

  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. 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. 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. 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. The Component And Its Parts • Component – New centerpiece, Objects now play a more supportive role. Can be written by 3rd 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. 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. A Child’s Component-Aware, Network-Centric Christmas

  14. class X operation1() operation2() operation3() operationn() • Associating related data & operations data • Decoupling interfaces & implementations 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

  15. Client Proxy Service AbstractService service service service 1 1 Object : Class X : Client operation() Middleware 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. We now have more robust software & more powerful distributed systems

  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. 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 C++ class Foo : public virtual CORBA::Object { virtual void MyOp (CORBA::Long arg); };

  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. Boiler Plate X Boiler Plate Y Config A Config B Boiler Plate X Config C 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 Server ObjImpl ObjImpl ObjImpl ObjImpl ObjImpl COS Svc ORB/POA ORB/POA CORBA BUS Client Server ObjImpl ObjImpl COS Svc invoke ORB/POA

  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. … … … Container Container Middleware Bus Replication Security Persistence Notification A/V Streaming Scheduling Load Balancing Overview of Component Middleware • 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 …

  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. 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. Deployment and Configuration 1/2 • Platform-Independent Model (PIM) • Three broad areas – software, target, execution • Defined in two dimensions

  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. D&C Actors Development • Different stages & different actors • Development • Specifier/ Developer • Assembler • Packager • Target • Domain Administrator • Deployment • Repository Administrator • Planner • Executor • Actors are abstract • Usually humans & software tools Component Component Assembly Creates Creates Component Component Impl Impl Impl Resource Properties Specifier/Developer Requirements Component Component Assembler Assembler Creates Creates Packager Uses Deployment Plan Planner Executor Component Packages Deploys Accesses Resources Repository Configures Administrator Laptop computer Printer Desktop COMPONENT REPOSITORY Bridge Ethernet Firewall Domain Dependencies QoS Specs Specifies Configurations Domain Administrator Deployment Target These actors & stages are simply making explicit existing processes

  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. Questions?

  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

More Related