1 / 62

Distributed Objects and Components

Distributed Objects and Components. Distributed Objects. The benefits of an object oriented approach to software development are greatly enhanced when they can be distributed over a network. A classical object encapsulates code and data.

kalonice
Download Presentation

Distributed Objects and Components

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. Distributed Objects and Components

  2. Distributed Objects • The benefits of an object oriented approach to software development are greatly enhanced when they can be distributed over a network. • A classical object encapsulates code and data. • A distributed object is an object that can live anywhere on a network, and can be invoked by remote clients via method invocations.

  3. Components • Distributed objects are independent software components. Components are not bound to a particular program, computer language, or implementation. • Components are packaged as the basic unit of work and distribution for an application made up of distributed objects.

  4. Key Characteristic • Possibly the most important distinguishing characteristic between an application and a component is that components can be used in unpredictable combinations, while applications tend to be focused on a particular task or environment.

  5. Why Components? • Interoperability between: • Different Languages • Different Compilers • Different Vendors • Different Operating Systems • Different Tools • Different Networks • Different Applications • Different Address Spaces (Microsoft doesn’t believe in Vendor independence.)

  6. Properties of Components • A marketable entity • Not a complete application • Usable in unpredictable combinations • Well specified interface • Toolability • Event notification • Configuration and property management • Scripting • Metadata and Inspection • Interoperability • Ease of Use

  7. Server Side Components • Components on the Server side need added intelligence. They need to be more concerned with Security, Licensing, Versioning, Life Cycle Management, Transaction Control and Locking, Persistence, Relationships, Self-Testing, Semantic Messaging and Self-installation than Client side components.

  8. Server Security Issues • Distributed Objects create special security problems for Servers: • They can play both Client and Server roles • Distributed objects evolve constantly • Their interactions are not well understood • Distributed objects are less predictable • Distributed objects are polymorphic • Distributed objects can scale without limit • Distributed objects are very dynamic • Most of these problems can be solved by moving security into the CORBA ORB.

  9. Distributed Object Technologies • CORBA • Enterprise Java Beans • COM+ • Object Oriented Databases • JINI

  10. Component Standards • On the desktop, Java Beans and ActiveX are competing component standards. • On the server, component standards include Enterprise Java Beans, CORBA Beans, and COM+. • CORBA Internet Inter-ORB Protocol (IIOP) provides a transactional pipe for EJBs, linking Java and CORBA.

  11. Distributed Object Topics • Object Brokers • Object Services • Object Transaction Monitors • Object Groupware • Object Databases • Object Web Technology • Object Linking • Object Frameworks

  12. Object Request Brokers • An Object Request Broker (ORB) provides the connections that allow components to interoperate. • An ORB must be augmented with a high-level component infrastructure that defines how the objects can work together. • This component infrastructure defines how object operate within containers (or frameworks).

  13. Object Transaction Monitors • OTMs are the state of the art in component management. Instead of the ORB approach, where you need to write separate code to call each needed service separately, an OTM provides a suite of services with a common call structure.

  14. Enterprise Java Beans • Possibly the most fashionable components today are Enterprise Java Beans, a component structure in Java that has been designed from the ground up to be compatible with CORBA. • EJBs use the RMI/IDL CORBA subset for their distributed object model, and the Java Transaction Service, a subset of the CORBA OTS, for distributed transactions.

  15. An EJB Application Example

  16. Internet Inter-ORB Protocol • Enterprise Java Beans use the CORBA IIOP (Internet Inter-ORB Protocol) to • Operate across multi-vendor servers • Propagate transaction and security contexts • Service multilingual clients • Support ActiveX clients with DCOM to CORBA bridges

  17. JavaBeans Component Model BeanInfo Customizer JavaBean Component Methods Events Properties JAR (.jar)

  18. The Promise of Distributed Objects • Assemble complex client/server applications with reusable software components • Objects can be modified or replaced without affecting the rest of the components in the system or their interactions.

  19. Packaging Distributed Objects • Components will be delivered in suites that run within application frameworks. • Within an application framework, all pieces are known to work together to perform domain level applications.

  20. Benefits of Distributed Objects • Visual tools and other applications can discover an object’s interfaces, events, and properties dynamically. • Granular components can be visually assembled with tools, interoperate across networks, run on different platforms, and manage themselves and their resources.

  21. Benefits of Distributed Objects (2) • Object Oriented client server applications can be more flexible than traditional approaches. • Components can be mixed and matched without sacrificing robustness. • Interfaces are separated from implementations, so you can use an object wrapper to make an existing legacy application look like an object.

  22. Defining Standards • The Object Management Group and Microsoft Corporation are the key competitors that are driving the movement toward distributed objects. • OMG is the force behind CORBA and its integration with Java. • Microsoft is trying to establish its own proprietary standard based on DCOM, ActiveX, COM+ and .NET

  23. What is CORBA? • CORBA is a middleware that that sits between the application and the system. • CORBA is based on the OO model. • CORBA allows software reusability. • CORBA uses a broker to handle messages. • The broker provides the ability to choose servers that best fill the client’s request.

  24. Comparing CORBA to DCE • DCE uses a procedure-oriented distributed model (RPC), while CORBA is based on objects. • DCE clients need to know what servers are available. CORBA clients request from the ORB, which connects them to a server. • CORBA provides a more abstract level of programming

  25. OMA (Orfali, Harkey, Edwards, Figure 22-2) Common Facilities Vertical Common Facilities Horizontal Common Facilities Application Objects Distributed Documents Information Management Systems Management Task Management Object Request Broker Collection Naming Persistence Life Cycle Concurrency Properties Time Trader Externalization Events Relationships Security Transactions Startup Licensing Query Common Object Services (CORBA Services)

  26. The Object Request Broker (ORB) • ORB is the object bus. • ORB is the middleware that establishes the client/server relationship between objects. • ORB lets objects communicate transparently without concern for : • the hosts where the objects run • the operating systems • the programming languages

  27. Data RPC vs. ORB (Orfali, Harkey, Edwards, Figure 22-4) Server Client Server Client Object X Object Y Invoke foo on Object X Invoke foo on Object Y foo foo Code Call foo RPC link Object Request Broker

  28. Structure of a CORBA 2.0 ORB (Orfali, Harkey, Edwards, Figure 22-4) Client Object Implementation Dynamic Invocation Client IDL Stub ORB Interface Static Skeletons Dynamic Skeleton Invocation Interface Repos- itory Object Adapter Imple- mentation Repository Object Request Broker Core

  29. CORBA Beans • The CORBA 3.0 Components model will include an extension of Enterprise Java Beans to CORBA’s language independent model, so that you are not locked into Java for all your components.

  30. CORBA Beans Component Model Component Info/IDL Customizer CORBA Component Methods Events Properties CAR (XML) (.car) This model should look familiar!

  31. General Inter-ORB Protocol • Key to the interoperability of CORBA is the bus structure that allows different Object Request Brokers on different hosts in different networks to communicate with each other. • The CORBA specification anticipates several of these, all based on the General Inter-ORB Protocol. (GIOP) • GIOP specifies seven message formats to cover all ORB request reply formats and a Common Data Representation (CDR).

  32. Internet Inter-Orb Protocol • The first implementation of a CORBA GIOP is the Internet Inter-ORB Protocol. (IIOP). • The IIOP specifies how GIOP messages are to be exchanged over a TCP/IP network. • Future specifications may cover other networks, but all CORBA implementations after 2.0 must either support IIOP or connect to it via a half bridge.

  33. A CORBA/EJB application

  34. COM+ The Component Bus From Microsoft

  35. The other component model • Microsoft, as one of the world’s largest and most profitable companies, must protect and increase its revenues to survive. • Its primary approach has been to attempt to make all computing within most corporations dependent upon proprietary products for which high fees must be paid to Microsoft. • It has already succeeded in capturing the desktop with Windows and Microsoft Office. Now it wants to capture the Network and the Internet.

  36. Server, COM+, and .NET • The Microsoft product to drive Unix out of corporations is MS Windows Server. • To capture the Internet, Microsoft is deploying the Microsoft Component Object Model (COM) and extending it to the Internet and Client/Server in general with COM+ and .NET • If Microsoft succeeds, a lot of companies will go out of business as dBase, Netscape, and Word Perfect did, and everyone will pay a lot more for software. They use low prices and good features to kill the competition, then raise prices.

  37. Parallels between COM and CORBA • CORBA and COM provide competing Object Request Brokers (ORB). • Both attempt to provide a universal approach to connecting components • Both require interfaces to be standardized through an IDL. The COM IDL is based on DCE and is not CORBA compliant.

  38. COM Interfaces • A COM interface is a collection of function calls (methods or member functions) based on a table of pointers. A COM client uses pointers to a virtual table or vtable, which is an array of function pointers. The functions addressed through those pointers are the server object’s implementation methods.

  39. COM Plug-in Jacks • COM traditionally uses bullet-and-stick diagrams, or plug-in jacks, to represent the vtable in Interface descriptions, because they are less intimidating. Plug-in Jack Client Application Component Object Interface Pointer

  40. COM IIDs • By convention, an interface in COM is given a name beginning with I, such as IFoo. This name is only a symbol for a source level programming tool. At run time each interface is known by a unique Interface Identifier (IID). An IID is a COM generated 128-bit globally-unique identifier (GUID) for interfaces.

  41. DCOM Objects • A COM object, also known as an ActiveX object, is a component that supports one or more interfaces defined by the object’s class. • A COM interface refers to a predefined group of related functions. • A COM Interface implements one or more interfaces and has a unique 128 bit Class ID (CLSID).

  42. IUnknown • All COM objects must implement the IUnknown interface to control the lifetime of the object and handle interface negotiations. IUnknown Interface A DCOM Object Interface B Interface C

  43. A Key Difference • In CORBA, Objects have unique IDS. • COM does not support Object IDs. With COM, clients obtain a pointer to an interface. DCOM clients cannot reconnect to the same object instance at a later time with the same state. This greatly reduces the role of object instances in COM as opposed to classic object systems.

  44. COM Server Functions • Implement a class factory interface • Register the supported classes • Initialize the COM Library • Verify compatibility of the library • Provide an unloading mechanism • Uninitialize the COM library after use

  45. Variations of COM Servers • In-process Servers execute in the same process space as clients, and are implemented as Dynamic Link Libraries (DLL) • Local Servers execute in a separate process and use DCOMs Lightweight RPC (LRPC) mechanism to communicate. Local servers have their own EXE file. • Remote Servers execute in a separate process on a remote machine and use a DCE-like RPC mechanism to communicate.

  46. Stub Stub DCOM DCOM Client Process Local Server Process In-Process Object Local Object Local Server Client Application In-Process Server Local Object Proxy LRPC Remote Machine Remote Server Process DCOM Remote Server Process Remote Object Proxy RPC Remote Object Remote Server DCOM Client Server Boundaries (Figure 23-5)

  47. IUnknown member functions • Every COM interface must implement three key IUnknown functions: • QueryInterface for interface negotiations • AddRef to create an interface instance • Release to destroy an interface instance • IUnknown is the base interface from which all other interfaces inherit.

  48. MIDL, the COM IDL • To develop a COM interface, you create a file that describes the interface’s methods and their arguments and run that file through the Microsoft IDL (MIDL) Compiler. • The MIDL Compiler is actually a precompiler that turns text descriptions of the interface into code for proxies and stubs, and creates header files with the interface definition.

  49. .NET Products and Services • Microsoft offers: • Visual Studio .NET, a web development platform using multiple languages, but the programs will only run on .NET • .NET myServices, that developers can use to create services. Microsoft will use those as a base to offer “user experiences” that will capture data and get people to subscribe. • A .NET version of Office by subscription • bCentral for small business by subscription

  50. A Comparison of 3 most popular distributed object paradigms Microsoft's Distributed Component Object Model (DCOM), OMG's Common Object Request Broker Architecture (CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI). Source: A Detailed Comparison of CORBA, DCOM and Java/RMI by Gopalan Suresh Raj

More Related