OO-Middleware. Computer Networking 2 DVGC02 Stefan Alfredsson. (slides inspired by Annika Wennström, Sören Torstensson)

Transcription

1 OO-Middleware Computer Networking 2 DVGC02 Stefan Alfredsson (slides inspired by Annika Wennström, Sören Torstensson)

2 Object oriented middleware Extendend mechanism for objects Objects consist of data (state) and methods Methods accessible via interface Methods can be remotely invoked (RMI, remote method invocation) Distributed objects: object and interface on different machines Examples: Corba, Java RMI, DCOM,... 2

3 Some central concepts Object vs component Object reference IDL Static and dynamic invocation 3

4 Component vs object Component is a frequently occuring term, but has no formal defintion Some characteristic properties do exist It is larger than an object It is autonomous and can do certain tasks on its own It can have a graphical interface, may be distributed (compare to Java Beans) May contain application or business logic, but may also be of more technical nature A component is a binary, and independent of programming language 4

5 Remote object 5

6 Object reference Created when object is created/instantiated Identified/represents object Identifies where (address:port) the object is instantiated Clients get object reference from e.g. naming service Client does not know the content of the object reference ( opaque ) Local and remote objects are handled differently because of efficiency 6

7 Object reference example IOR: c3a48656c6c 6f576f726c642f48656c6c6f3a312e f e31302e e b afabcb a4b a

8 Interface Definition Language (IDL) Declarative language Defines the object interface (not logic) Client and server may be implemented in different languages Proxy and skeleton is generated by IDL compiler Not used by all oo-middleware, for example Java RMI IDL only support Java 8

9 Invocation style Static invocation Proxy and skeleton must be known at compile time A change in interface requires recompile Dynamic invocation Generic stubs are provided by the underlying system Proxy and skeleton are not needed at compile time Interface need not be known at compile time 9

10 Example products Java RMI Jini Corba 10

11 Java RMI RMI Remote Method Invocation Client/Server based Server creates object, returns reference Client use reference, calls object method via a local proxy object Client can send their own objects as arguments Thanks to serialization, where instantiated java objects can be exported to byte stream, complete with state and logic 11

12 12

13 RMI implementation Server interface extends java.rmi.remote, and declares java.rmi.remoteexception as exception Generate server and client stubs (rmic) Start rmiregistry, server, client 13

14 Server example - registration... String name = "//host/compute"; try { Compute engine = new ComputeEngine(); Naming.rebind(name, engine); System.out.println("ComputeEngine bound"); } catch (Exception e) { 14

15 Client example, service call... try { String name = "//host/compute"; Compute comp = (Compute) Naming.lookup(name); Pi task = new Pi(Integer.parseInt(args[1])); BigDecimal pi = (BigDecimal)(comp.executeTask(task)); System.out.println(pi); } catch (Exception e) {... 15

16 Jini Developed by Sun Microsystems 1999 Network architecture optimized for scalability and independency Builds upon Java RMI 16

17 17

18 The purpose of the Jini architecture is to federate groups of devices and soft-ware components into a single, dynamic distributed system. The resulting federation provides the simplicity of access, ease of administration, and support for sharing that are provided by a large monolithic system while retaining the flexibility, uniform response, and control provided by a personal computer or workstation. The architecture of a single Jini system is targeted to the workgroup. Members of the federation are assumed to agree on basic notions of trust, administration, identification, and policy. It is possible to federate Jini systems themselves for larger organizations. (From The Jini Architecture Specification ) 18

19 Jini motivation Cooperating framework Simple, seamless, scalable interoperability Network plug and play with little administration Network connected soft and hardware provide services All units can find and use available services Examples Find all color-duplex printers nearby Start brewing coffee five minutes before the morning alarm clock sounds Let the cellphone use the car speakers 19

20 A more complex scenario A digital camera is plugged into the network It finds out the lookup-service (discovery phase) It registers its interface in the lookup-service (join) Basically says I m a camera, anyone want pictures? Later: A laptop is plugged into the network, and calls Camera.Snapshot() The camera detects that the light is too dark, and use Light.increase() until the light is OK Laptop asks camera to print photo Camera finds nearest printer via lookup-service, and calls its printing method 20

21 Jini promises... Desktop PC Lookup service Printer Service Coffee Maker Network Alarm Clock Service Cell Phone Stereo Speaker Service 21

22 Key technologies Services Name resolution (lookup service) Java Remote Method Invocation (RMI) Leasing Transactions Events 22

23 Bzzz, bzzz Instant On When a jini-enabled device is plugged into the network, it works right away with no fuss Its services and resources are immediately available Impromptu Community Devices working together, creating a personal network or community Connect home appliances and control them centrally Connect to services on the road Resilient Adapts very quickly to changes The community lives on, as users comes and goes Special delivery Services are available on demand, whenever needed 23

24 Impressive factors Drivers are provided by the service Only need to know interface Work load can be shared between client and server Leasing model handles network/client/server failures (a lease is renewed only as long as service is used) Distributed transactions (two phase commit) Flexible search for properties ( printing service, play sound ) 24

25 Some problems Need to know the interface in advance, and agree on provided functions Printer.Print(), Coffee.Brew(), Coffee.Print() <- oops Standardized at jini.org Needs a Java VM everywhere Can use a surrogate function to connect equipment incapable of running a JVM Sensor networks 25

26 Jini future outlook Great potential, but has not become a wide success Competition: UPnP (MS), Rendevouz (Apple) Demands well defined interfaces for standard services (Printer, etc) 26

27 Overview CORBA - Common Object Request Broker Architecture Developed by OMG (Object Management Group). An architecture for distributed objects. The Object Request Broker (ORB) is the middleware that establishes the client-server relationships between objects. CORBA 3.0 Commercial release at end of

28 OMG - Object Management Group Founded in May 1989 by 3Com, American Airlines, Canon, Data General, HP, Philips, Sun, Unisys. Now over 800 members. Vendor independent non-profit operations. Based in Framingham, Massachusetts, USA, but has regular meetings all over the world OMG produces specifications for standardized object software in order to create a component-based software marketplace. 28

29 Object Orientation Basics Objects and Classes (object types) Object members: Methods (CORBA: operations) Fields (CORBA: attributes) Inheritance Interface ( abstract class ) 29

30 OMG Reference Model User Interface Management, Information Management, The result of the System Management, programmers sweat! Task Management Finance, Health Care, Telecom, Manufacturing, etc. Application Objects CORBA Facilities CORBA Domains Object Request Broker (ORB) CORBA Services Naming, Event, Transaction, Persistence, Lifecycle, Security, Trader, Concurrency, Externalization, Query, Collection, Relationship, Time, Licensing, Properties 30

31 Services in CORBA Application Objects CORBAdomains CORBA Manufacturing, CORBA Med(icine), CORBA Finance, CORBA Telecoms CORBAfacilities: Common services User Interface Management, Information Management, Systems Management, Task Management CORBAservices: OS level object services Naming, Event, Transaction, Persistence, Lifecycle, Security, Trader, Concurrency, Externalization, Query, Collection, Relationship, Time, Licensing, Properties 31

32 CORBA Services (1) System level services. Interfaces to services defined by IDL. Several services overlap functions that are available in operating systems and programming languages. May be bundled with ORB products or sold separately. 32

33 CORBA Services (2) Life Cycle - create, copy, move, delete objects Persistence - permanent storage of objects to file / database Naming - binding of objects to names Event - event handling and event subscription Concurrency - lock services for threads and transactions Transaction - two-phase commit Relationship - dynamically created associations Externalization - convert objects to a binary stream Query - query service 33

34 CORBA Services (3) Licensing - registration of usage of objects Properties - dynamic information about objects Time - common time service Trader - announce and find services based on service characteristics Collection - handle collections of objects Security - protect objects against unauthorized usage 34

35 CORBAfacilities User Interface Management displaying, printing, compound documents, help information, Information Management modeling, storage, retrieval, compound documents, interchange of information, encoding, translation,... Systems Management management tools, monitor and control of system resources,... Task Management workflow automation, rule based objects, intelligent agents,... 35

36 CORBA ORB Architecture 36

37 Client Stub The client stub has the same interface as the server object that it represents. The client stub acts as a proxy for the server object. The client stub receives calls from the client to the server object performs marshalling of parameters receives results from the server object and forwards them to the client 37

38 Interface Repository The Interface Repository is a run-time database that contains information about all available IDL interfaces that the ORB recognizes. It can be called to read or write descriptions of registered objects (interfaces) perform type control of method calls The interfaces must be loaded into the Interface Repository when the server object is activated 38

39 Dynamic Invocation Dynamic Invocation Interface (DII) is an interface for exploring objects during execution. Meta-data about objects can be read from Interface Repository. A dynamic call from a client program does not need a client stub, the client generates the call itself. Dynamic Invocation is not used very much (yet). 39

40 Object Adapter The Object Adapter sits on top of the communication system and manages object registration, creates object-id:s, handles calls to objects, activates objects, etc. There are different types of Object Adapters: Basic Object Adapter (BOA) is required by the standard (but it tends to be implemented in a proprietary way) Portable Object Adapter (POA) shall be more strictly standardized 40

41 IDL - Interface Definition Language The language used to specify interfaces to CORBA objects It is a declarative language (i.e. no programming language) IDL has become an ISO-standard and is used in other contexts than with CORBA IDL-syntax is similar to C++ syntax (but only declarative parts) the same lexical rules as C++ but some new keywords are added C++ syntax for declaration of constants, types and operations C++ preprocessing features are supported future changes to ANSI standard for C++ will be adopted by IDL 41

42 An IDL Example interface grid1 { long get(in short n, in short m); void set(in short n, in short m, in long value); }; interface grid2 { void reset(in long value); }; interface grid: grid1, grid2 { }; 42

43 IDL compilation (Java example) IDL-file (xxx.idl) Interface Repository Compilation Client stub (_st_xxx) xxxhelper xxxholder Server Skeleton (_xxximplbase) Interface (xxx) Example (_example_xxx) (inherits) Implementation of Client Implementation of Server Implementation of Main 43

44 IDL language mappings There are mappings from IDL to the following programming languages: C/C++ Smalltalk Cobol Ada Java Nonstd: TCL, PL/1, LISP, Python, Perl,... These languages can be used to implement clients and server objects for CORBA. 44

45 Different ways to invoke a request A request can be invoked in three ways : Synchronous Request the client stops and waits for the result Deferred Synchronous Request (only dynamic invocation) the client continue to execute and must poll for the result later One-way Request (only dynamic invocation) the client ignores the result 45

46 Protocols for CORBA: GIOP GIOP - General Inter-Orb Protocol is used between ORB:s in order to get interoperability The GIOP specification consists of The Common Data Representation (CDR) definition. This is a transfer syntax mapping OMG IDL data types into a low-level representation to be used on the wire The GIOP Message Formats. Messages are for object requests, object location and management of communication channels. GIOP Transport Assumptions. This is general assumptions regarding the transport layer. 46

47 Protocols for CORBA: IIOP IIOP - Internet Inter-Orb Protocol is a mapping of GIOP to be carried over TCP/IP. The IIOP specification consists of The GIOP specification. Internet IOP Message Transport. This part describes how TCP/IP connections are opened and used for GIOP messages. IIOP is the protocol that makes it possible to interconnect ORB:s from different vendors, as well as using CORBA over Internet. Interoperable Object References (IOR) are globally unique names that has to be used between different ORB:s. 47

48 CORBA Products Inprise VisiBroker (Borland+Visigenic) (world leader) IONA Orbix (biggest in Sweden) OOC ORBacus (formerly OmniBroker) GNOME ORBit Included in J2SE 1.4 and onward The Free CORBA page gives a lot of information about CORBA products (both commercial and free): 48

49 Global Middleware In order to make it possible to integrate the IT systems of different organizations, looser coupling is needed. Service Oriented Architecture (SOA) Provide Services 49

50 Challenges for Global Middleware Firewalls that block most TCP/IP ports for security reasons But HTTP (i.e Web traffic on port 80) are mostly open Different component technology at each end requires n 2 interfaces CORBA EJB.NET COM/DCOM. 50

51 Web Services Solution Firewall problem: Use XML messages transported with HTTP -> SOAP Multiple Interface Problem Use one set of interconnect standards SOAP, WSDL, UDDI; Internet standards 51

52 Web Services Aim From the Web Services Activity Statement: ( Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machineprocessable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services. 52

53 Web Services Idea Exchange of messages Messages are encoded using XML, -> SOAP Using standard protocols to transport messages - >HTML, SMTP,.. Message paradigms One-way Request / response (most common style) Solicit - response Notification Major Use as integration technology Within a business Across businesses 53

54 Web Services 54

55 UDDI Universal Description, Discovery, and Integration (UDDI) Can be used for Web Services /SOAP, but also others A UDDI business registration consists of three components: White Pages address, contact, and known identifiers; Yellow Pages industrial categorizations based on standard taxonomies; Green Pages technical information about services exposed by the business. 55

56 Web services descriptions (WSDL) To use Web services in a loosely coupled system, Web services need to be described, so that their description can be used to discover them. A description has several parts: Abstract description Available services Which messages are needed for a service Description of the used messages Used data types Concrete description Binding to the message layer (e.g. SOAP) Bindings to the transport layer (e.g. HTTP) Where do I find the message 56

57 SOAP Simple Object Access Protocol Sending messages between applications Based on XML: platform & language independent Uses HTTP GET and POST methods to transfer data: easy traversal through firewalls etc. 57

58 SOAP request example (Example from POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> 58

59 SOAP response example (Example from HTTP/ OK Content-Type: application/soap; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> 59