COMS W4156: Advanced Software Engineering

1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/ COMS W4156

2. Topics covered in this lecture • Distributed Computing -> Component Model Frameworks • CORBA • If time permits: COM • Discussion of upcoming assignments COMS W4156

3. Distributed Computing COMS W4156

4. Client Server Distributed Computing 101:“Plumbing” • 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? COMS W4156

5. 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 COMS W4156

6. 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”? COMS W4156

7. Client Server Client Server Communication Layer 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? COMS W4156

8. 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? COMS W4156

9. 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” COMS W4156

10. 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 COMS W4156

11. CORBA COMS W4156

12. CORBA • = Common 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 • 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) COMS W4156

13. CORBA Big Picture Client Server IDLstub IDLskeleton ORB = Object Request Broker Request Response IDL = Interface Description Language COMS W4156

14. 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 COMS W4156

15. 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) COMS W4156

16. 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 COMS W4156

17. 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 COMS W4156

18. 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). COMS W4156

19. 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). COMS W4156

20. CORBA Big Picture (Refined) Client Server IDLstub IDLskeleton ORB Object Object IDL file COMS W4156

21. 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 COMS W4156

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

23. 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 COMS W4156

24. 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 { … } COMS W4156

25. CORBA Client-side • Connect to ORB • Contact NameService (standard service provided by any CORBA implementation) • Locate (‘resolve’) Object by name • Typecast (‘narrow’) to specific Interface • Invoke desired method COMS W4156

26. 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)); COMS W4156

27. Client-side perspective • Client shielded by Interface • Client accesses ORB services • Client communicates with stub ‘proxy’ Client interface IDLstub ORB COMS W4156

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

29. Server-side perspective • ORB receives call • ORB passes request to Object implementation through skeleton • Response sent back from Object to skeleton • Sent back to client Server 3. Response 1. Call IDLskeleton 4. To Client 2. Invoke ORB COMS W4156

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

31. 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 COMS W4156

32. CORBA Evaluation • Strengths • Interfaces hide complexities • Automatic language interoperability • Weaknesses • Client must know server’s interface(s) • Java RMI and other modern language facilities do everything CORBA does … • And today’s component model frameworks do even more… COMS W4156

33. 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) COMS W4156

34. 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 COMS W4156

35. 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 COMS W4156

36. 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 COMS W4156

37. COM COMS W4156

38. 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 objects • 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) COMS W4156

39. 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) COMS W4156

40. 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 COMS W4156

41. 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 allof 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 allthe functions that the class supports COMS W4156

42. Calling an Interface Method • With appropriate compiler support (inherent in C and C++), a client can call an interface method through its name, rather than its position in the array • Because an interface is a type, the compiler, given the names of methods, can check the types of parameters and return values of each interface method call • In contrast, if a client uses a position-based calling scheme, such type-checking is not available, even in C or C++ COMS W4156

43. 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 COMS W4156

44. COM Overview COMS W4156

45. Types of COM Server • An in-processserver resides in a dynamic link library (DLL) and runs in the same address space as the COM client • A localserver 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 COMS W4156

46. 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 COMS W4156

47. 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 COMS W4156

48. 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 COMS W4156

49. COM Limitations • Same as CORBA: No support for common programming idioms (other than RPC) • 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) COMS W4156

50. Upcoming Assignments COMS W4156