COMS W4156: Advanced Software Engineering Prof. Gail Kaiser September 8, 2011COMS W41561

September 8, 2011COMS W41562 Topics covered in this lecture Distributed Computing -> Component Model Frameworks CORBA If time permits: COM overview Discussion of upcoming assignments

September 8, 2011COMS W41563 Distributed Computing

September 8, 2011COMS W41564 How does client identify server? How does server make its functionality known and available to prospective clients? How does client make its request? How does server return its response? What design-time support is available? What run-time support is available? Distributed Computing 101: “Plumbing” ClientServer

September 8, 2011COMS W41565 How does client identify server? One alternative: hard-wired solution –Tightly coupled code where any change to server may require modifications to client and vice versa –Must be able to operate in any deployment environment –Cannot plug-replace with new server from another vendor (better, faster, cheaper), possibly not even with a different version of the original server –System administration nightmare Better alternative: employ some standard “discovery protocol” that all prospective vendors agree to

September 8, 2011COMS W41566 How does server make its functionality known and available to prospective clients? Are interfaces used? If so, how expressive is the notation? Are interfaces enforced? What happens when the server functionality is “upgraded”?

September 8, 2011COMS W41567 How does client make its request? How does server return its response? “Communication protocol” How complicated? How (potentially) buggy? Percentage of code and development effort devoted to mechanism? ClientServer ClientServer Communication Layer

September 8, 2011COMS W41568 What design-time support is available? Quality Assurance –Errors caught after deployment 1000x more expensive to fix than at design time –Reduce errors in first place through intuitive idioms –Type-safety checks incredibly useful (do parameters supplied by clients match those anticipated by server? do responses from server match those expected by client?) Interoperability –Must client and server use same development language? –Is third-party code reuse possible?

September 8, 2011COMS W41569 What run-time support is available? Standardized infrastructure crucial –Reduced training, design, coding and testing costs –More reliable and robust –But need to consider impact on performance Interoperability (across vendors) essential –Countless incompatible proprietary “standards”

September 8, 2011COMS W Motivation for Component Model Frameworks Provide “standard” answers to the Distributed Computing 101 questions Designing, implementing, testing and deploying the “plumbing” is difficult and error-prone But nearly the same across many applications Put system programmers and distributing computing experts effort into doing it once per framework rather than once per application Leaves application logic (and business value) to application programmers and domain experts

September 8, 2011COMS W CORBA

September 8, 2011COMS W CORBA = Common Object Request Broker ArchitectureCommon Object Request Broker Architecture Historically, one of the first organized frameworks for distributed computing (c. 1991) –Specification developed and periodically revised by the Object Management Group Object Management Group –Extremely influential –Used especially as middleware in enterprise and business- critical infrastructures Not quite a component model as more recently envisioned, but on the way there… (later CCM = Corba Component Model)

September 8, 2011COMS W ORB = Object Request Broker Response Request CORBA Big Picture ClientServer IDL stub IDL skeleton IDL = Interface Description Language

September 8, 2011COMS W CORBA Big Picture Server interface specified in language-independent IDL notation Client communicates request to ORB –IDL compiler generates stub (in client’s implementation language) to hide complexity –Stub compiled and linked together with client ORB delivers request to Server –IDL compiler generates skeleton (in server’s implementation language) to hide complexity –Skeleton compiled and linked together with server Analogous return path for response

September 8, 2011COMS W Objects CORBA Objects are “object-oriented” in the sense that they are individual units of running software that provide interfaces and combine functionality and data Typically, there are many instances of an Object of a single type – e.g., an e-commerce website would have many shopping cart object instances (hosted in a server process) For some types, there may be only one instance – e.g., when a legacy application, such as an accounting system, is wrapped as a CORBA Object and opened up to clients on the network (here the object is the server process)

September 8, 2011COMS W CORBA Big Picture (Refined) Object type interface specified in language-independent IDL notation Client communicates request to ORB –IDL compiler generates stub (in client’s implementation language) to hide complexity –Stub compiled and linked together with client ORB delivers request to Server host, which in turn delivers request to an Object instance selected by the server –IDL compiler generates skeleton (in server’s implementation language) to hide complexity –Skeleton compiled and linked together with server Analogous return path for response

September 8, 2011COMS W Object Interfaces For each Object type, an interface is defined in OMG’s IDL (Interface Description Language) The interface is the syntax part of the “contract” that the Object offers to the clients Any client that wants to invoke an operation on the Object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends When the invocation reaches the target Object, the same interface definition is used there to demarshal the arguments so that the Object can perform the requested operation And analogously wrt marshalling/demarshalling response

September 8, 2011COMS W Object Marshalling/Demarshalling When objects in memory are to be passed across a network to another host or persisted to storage, their in-memory representation must be converted to a suitable out-of-memory format. This process is called marshalling (or serializing), and converting back to an in memory representation is called demarshalling (or deserializing).

September 8, 2011COMS W Object Marshalling/Demarshalling During marshalling: –Objects must be represented with enough information that the destination host can understand the type of object being created. –The objects’ state data must be converted to some platform-independent format. –Complex object trees that refer to each other via object references (or pointers) need to refer to each other via some form of ID that is independent of any memory model. During demarshalling: –The destination host must reverse all that. –And must also validate that the objects it receives are consistent with the expected object type (e.g., it checks that it doesn’t get a string where it expects a number).

September 8, 2011COMS W CORBA Big Picture (Refined) Client IDL stub IDL skeleton ORB Object Object IDL file Server

September 8, 2011COMS W IDL = Interface Description Language Neutral wrt implementation language IDL notation looks and feels remarkably like C, with some Pascal concepts added There are defined (or at least draft) mappings to C, C++, Java, C#, Python, Perl, Ruby, Lisp, XML, numerous others IDL Compilers generate native code in target language

September 8, 2011COMS W IDL ‘HelloWorld’ example module HelloApp { interface Hello { string sayHello(); }; Module is a scoping unit Interface is set of Object method signatures Base types defined by CORBA include string, int, double, float, boolean, etc…

September 8, 2011COMS W More complicated example module StockObjects { struct Quote { string symbol; long at_time; double price; long volume; }; exception Unknown{}; interface Stock { Quote get_quote() raises (Unknown); void set_quote (in Quote stock_quote); readonly attribute string description; }; Exception associated with a module may be raised by its methods Attribute provides additional information

September 8, 2011COMS W IDL expressiveness Method Signatures –Declare parameters as { in|out|inout } –Can raise exceptions –Can return a value Declarative Attributes –{ readonly } attribute {type} {name} –Equivalent to _get_att/_set_att Multiple Inheritance –interface ISpec:I1,I2 { … }

September 8, 2011COMS W CORBA Client-side 1.Connect to ORB 2.Contact NameService (standard service provided by any CORBA implementation) 3.Locate (‘resolve’) Object by name 4.Typecast (‘narrow’) to specific Interface 5.Invoke desired method

September 8, 2011COMS W CORBA client // 1. Connect to ORB ORB orb = ORB.init(args, null); // 2. Contact NameService org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // 3. Locate Object NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = { nc }; Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));

September 8, 2011COMS W Client-side perspective Client shielded by Interface Client accesses ORB services Client communicates with stub ‘proxy’ Client IDL stub ORB interface

September 8, 2011COMS W CORBA Server-side Connect to ORB Contact NameService Register (‘rebind’) Object by name HelloServant helloRef = new HelloServant(); orb.connect(helloRef); ncRef.rebind(path, helloRef);

September 8, 2011COMS W Server-side perspective 1. ORB receives call 2. ORB passes request to Object implementation through skeleton 3. Response sent back from Object to skeleton 4. Sent back to client IDL skeleton ORB 1. Call 2. Invoke 3. Response 4. To Client Server

September 8, 2011COMS W Response 1a. Activate Server-side perspective (Refined) 1. ORB receives call a.ORB activates server b.Server calls BOA::impl_is_ready c.BOA instantiates Object in Server 2. BOA passes request to Object implementation through skeleton 3. Response sent back from object to skeleton 4. Sent back to client IDL skeleton ORB 1. Call 2. Invoke BOA 1b. Ready 1c. 4. To Client BOA = Basic Object Adapter

September 8, 2011COMS W CORBA Summary Object Request Broker (ORB) acts as a “mediator” that abstracts –Object location: server method invocations always local, then ORB redirects –Networking issues: stub/skeleton code automatically generated, usually programmer can ignore –Activation issues: ORB automatically activates and deactivates server objects –Persistent state: Clients should not care whether server objects are persistent or not

September 8, 2011COMS W CORBA Evaluation Strengths 1.Interfaces hide complexities 2.Automatic language interoperability Weaknesses 1.Client must know server’s interface(s) 2.Java RMI and other modern language facilities do everything CORBA does … 3.And today’s component model frameworks do even more…

September 8, 2011COMS W CORBA Limitations [Before version 3.0, which includes “CORBA Component Model”] No common (mandatory) set of services implemented by all ORBs No standard way of deploying server Objects (adding new server Objects to an ORB) –Each ORB infrastructure implementation had different approach to IMR (IMplementation Repository)

September 8, 2011COMS W CORBA Limitations No support for common programming idioms –Most server Objects implemented as “factories”, creating a new Object instance to deal with each new client, but new factory code needs to be written for each case –Every programmer has same choices to make, between persistent and transient references, Objects identified or not by a primary key, Objects maintain persistent state or not, … and then has to implement the decisions

September 8, 2011COMS W CORBA Needs “Components” Binary (executable) units that can really be used interchangeably with any ORB –Allows graceful evolution by replacing one component with another –Eases porting to another ORB (better, faster, cheaper) Applications can then be built by assembling components –Components must define what they need and what they offer –Once assembled, deployment should be semi-automatic Need standard development, deployment and runtime environment

September 8, 2011COMS W CORBA Component Model (CCM) Part of CORBA 3.0 specification, June 2002 Extends CORBA object model –New component meta-type –Development by composition –Similar to EJB (Enterprise Java Beans) Not widely used – most CORBA implementations not compliant with 3.x spec

September 8, 2011COMS W COM

September 8, 2011COMS W Component Object Model (COM) COM specifies an object (or component) model, and programming and compiler requirements, that enable COM objects to interact with other COM objectsCOM A COM object is made up of a set of data and the functions that manipulate the data A COM object’s data is accessed exclusively through one or more sets of related functions called interfaces COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface Interfaces defined in Microsoft Interface Definition Language (analogous to CORBA IDL, but NOT the same)

September 8, 2011COMS W Component Object Model (COM) COM is a binary standard—a standard that applies after a program has been translated to binary machine code COM methods and interfaces must follow a prescribed in- memory layout Objects can be written in different languages, including languages that don’t have “objects” COM allows objects to interact across process and machine boundaries as easily as within a single process Marshalling/demarshalling method parameters and return values across process and machine boundaries handled by operating system (in Windows COM implementation)

September 8, 2011COMS W COM Overview

September 8, 2011COMS W COM Interfaces COM allows objects to interact across process and machine boundaries as easily as within a single process COM enables this by specifying that the only way to manipulate the data associated with an object is through an interface on the object “Interface” here refers to an implementation in code of a COM binary-compliant interface that is associated with an object COM methods and interfaces must follow a prescribed in-memory layout

September 8, 2011COMS W But COM Interface Different from C++ Interface COM uses the word interface in a sense different from that typically used in C++ programming A C++ interface refers to all of the functions that a class supports and that clients of an object can call to interact with it A COM interface is a pure virtual definition that carries no implementation A COM interface refers to a predefined group of related functions that a COM class implements, but a specific interface does not necessarily represent all the functions that the class supports

September 8, 2011COMS W COM Clients and Servers A COM client is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interface(s) A COM server is any object that provides services to clients These services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object

September 8, 2011COMS W Types of COM Server An in-process server resides in a dynamic link library (DLL) and runs in the same address space as the COM client A local server resides in its own executable (e.g., *.exe file), in a different process but on the same machine as the COM client A remote server runs on a different machine than the client

September 8, 2011COMS W Same Machine For clients and servers on the same machine, the CLSID of the server is all the client ever needs On each machine, COM maintains a database (using the system registry on Windows) of all the CLSIDs for the servers installed on the system This is a mapping between each CLSID and the location of the DLL or EXE that houses the code for that CLSID COM consults this database whenever a client wants to create an instance of a COM class and use its services, so the client never needs to know the absolute location

September 8, 2011COMS W Different Machines For distributed systems, COM provides registry entries that allow a remote server to register itself for use by a local client Applications need know only a server's CLSID, because they can rely on the registry to locate the server However, COM allows clients to override registry entries and specify server locations

September 8, 2011COMS W COM vs. DCOM COM client applications do not need to be aware of how server objects are packaged, whether they are packaged as in-process objects (in DLLs) or as local or remote objects (in EXEs) Distributed COM (DCOM) is not separate—it is just COM with a longer wire

September 8, 2011COMS W COM Overview

September 8, 2011COMS W COM Limitations Same as CORBA: No support for common programming idioms (other than remote procedure call) Unlike CORBA: Has one “main” implementation - from Microsoft for Windows, so by definition “compatible” Needs component services: distributed transactions, resource pooling, disconnected applications, event publication and subscription, better memory and processor (threads) management, … COM ~1993, DCOM ~1996, (D)COM + MTS ~1998, COM+ ~2000, partially superseded by.NET ~2002 (but compatible)

Upcoming Assignments September 8, 2011COMS W415650

Upcoming Assignments Homework #1 due Tuesday 13 September, 10am Homework #1 Team Formation due Thursday 15 September, 10am Team Formation Teams will (hopefully) be finalized by Tuesday 20 September September 6, 2011COMS W415651

COMS W4156: Advanced Software Engineering Prof. Gail Kaiser September 8, 2011COMS W415652