Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Object Models for Distributed Systems (PowerPoint)

VIEWS: 11 PAGES: 42

									  Objektorienteret Middleware

          Presentation 24:
RMI, Web services, DCOM Introduction
Part 1: Java RMI
Java RMI

  • Java 1.0: object communication confined to objects in
    one Virtual Machine (VM)
  • Sun Microsystems thus decided to introduce inter VM
    communication
  • Remote Method Invocation (RMI) from Java 1.1
    supports communication between different VMs,
    potentially across the network
  • Provides tight OO integration with Java
  • Work in heterogeneous environment (servers)
  • BUT ONLY with Java (so far) – so no language
    transparency (not true when using IIOP)
Java RMI features

    • Build on Java’s existing object model -> easy
    • No need for IDL – use Java interfaces
    • Arguments & return values can be all types
      specializing java.io.Serilizable or java.rmi.Remote
    • Dynamic loading of classes
    • Use of build-in Java Security Manager
    • Distributed Garbage Collection
    • Integrates with CORBA (later)
    • BUT NOT IN J2ME!!! (use Web services)
       • J2ME CDC has an RMI profile!
Wire Protocol

    • Java RMI wire protocol:
       • JRMP (Java Remote Method Protocol) OR
       • IIOP (Internet Inter-ORB Protocol) for CORBA
         connectivity
       • Both build on top of TCP/IP
       • JRMP supports dynamic class loading, IIOP does not
    • Other Java RMI specification implementers
       •   Historic: BEA Weblogic, Object Voyager, NinjaRMI
       •   Object Voyager’s was JRMP compatible
       •   Others were not
       •   IIOP compatibility can not be guaranteed
Java RMI position Middleware

    •Transaction-Oriented      •Object-Oriented
       •IBM CICS                  •OMG/CORBA
       •BEA Tuxedo                •DCOM
       •Encina                    •Java/RMI
                                  •(SOAP)
    •Message-Oriented
       •IBM MQSeries
       •DEC Message Queue
       •NCR TopEnd
       •(SOAP)
    •RPC Systems
       •ANSA
       •Sun ONC
       •OSF/DCE
       •(SOAP)
Local Java call vs. Java RMI call



                  Similar to SOAP and CORBA – using Proxy
        Caller
        Caller                                  Called
                       Caller


                                                 Stub
                        Stub
       Called
                      Transport Layer (e.g. TCP or UDP)
package examples.hello;

    import java.rmi.Naming;                                      Server object
    import java.rmi.RemoteException;
    import java.rmi.RMISecurityManager;                          (HelloImpl.java)
    import java.rmi.server.UnicastRemoteObject;

    public class HelloImpl extends UnicastRemoteObject implements Hello {
                                                                                       Extend UnicastRemote
        public HelloImpl() throws RemoteException {                                  and implemet Hello Interfacet
          super();
        }

        public String sayHello() {                     Implement all methods
             return "Hello World! ;                   from interface Hello.java
        }

     public static void main(String args[]) {
       // Create and install a security manager
       //if (System.getSecurityManager() == null) {                        Security manager needs a security policy
       // System.setSecurityManager(new RMISecurityManager());               – for access control (i.e. file system).
       //}
          try {
             HelloImpl obj = new HelloImpl();

              // Bind this object instance to the name "HelloServer"
              Naming.rebind("rmi://192.168.1.101/HelloServer", obj);       Instantiate a new object and register
                                                                                (bind it) in the ”rmiregistry”
               System.out.println("HelloServer bound in registry");
            } catch (Exception e) {
               System.out.println("HelloImpl err: " + e.getMessage());
               e.printStackTrace();                              ”rmiregistry” is a simpel name server with
            }
        }
                                                             methods to bind objects (bind/rebind) – and
    }                                                            Find them again (lookup) –> client
package examples.hello;

import java.rmi.Naming;                                            Client object
import java.rmi.RemoteException;
                                                                   (HelloClient.java)
public class HelloClient {

    public static void main(String args[])
    {
      try {
            Hello obj = (Hello)Naming.lookup("rmi://192.168.1.101/HelloServer");   ”lookup” the HelloServer – and call
            String message = obj.sayHello();                                           Method sayHello() on Stub
            System.out.println(message);

        } catch (Exception e) {
             System.out.println("HelloApplet exception: " + e.getMessage());
             e.printStackTrace();
         }
    }

}                                                              AND THAT’S IT!


                     Remember – that the stub
                 and skeleton classes get generated
                       by the ”rmic” compiler
 Architecture


     Client                coded manually                    Server
                  lookup             bind



 Stub             Registry                  Skeleton            Activation
rmic generated   Interfaces                 rmic generated      Interfaces
                 RMI Runtime (rmid,rmiregistry)
Part 2: Web services: SOAP & WSDL
Web Service Defined

   • W3C definition:
      • [Definition: A Web service is a software system
        designed to support interoperable machine-to-machine
        interaction over a network. It has an interface described
        in a machine-processable format (specifically WSDL).
        Other systems interact with the Web service in a
        manner prescribed by its description using SOAP
        messages, typically conveyed using HTTP with an XML
        serialization in conjunction with other Web-related
        standards.]
Overview SOAP & Web services
•   SOAP – Simple Object Access Protocol - &
    Web services:
     •   A light-weight & ultra heterogenic alternative to
         CORBA, DCOM & RMI
     •   Openness in focus – meant for opening legacy
         applications for others
     •   Not meant in the role of Inter business, large
         scale, transaction heavy communication (as
         CORBA & J2EE)
     •   No services for transactions, concurrency,
         persistence, scalability
     •   Discovery services (UDDI) giving some degree
         of location transparency
     •   Interface Definition Language for heterogeneity
         (WSDL)
     •   Fails on several of the dist. system
         requirements!
     •   But easy to implement yourself!
Why Web Services with SOAP
When We Have CORBA?
 • CORBA has been considered too complex by many
    • May not be true with new development tools using wizards
 • They aim at solving different tasks:
    • SOAP covers light-weight application integration within the
      enterprise, exposing legacy business objects across enterprises,
      and sharing resources (like Google Search Engine, or Sonofon
      SMS/MMS API) on the net, as well as technology openness
    • CORBA has a wide range of services for (as we have seen):
       • Locating, creating & moving objects
       • Object relationship management between hosts
       • Persistency services – activation frameworks etc.
       • Distributed concurrency and transaction management
       • Security
    • Only some are supported in SOAP tech family – its lightweight
    • Lesson: define your needs – and find the right technology
Regarding SOAP
 •   SOAP is not by it self revolutionary – its merely:
      • a framework for exchanging XML-based information in a network
        (via protocols of the TCP/IP family) – with RPC capabilities
      • the currently most hyped XML / Web service technology
 •   But when combined with other technologies like
      • WSDL &
      • UDDI
      • It solves several of the requirements of a Distributed System
 •   And the fact that it is an open standard – supported by all major software
     vendors and programming languages:
      •   C++
      •   Java
      •   C#
      •   Delphi
      •   Visual Basic and many more
 •   Makes it somewhat revolutionary! A practical solution – like WWW
Examples of Web Services
 • Google's Web Service - access the
   Google search engine
    • http://www.google.com/apis/
 • Amazon's Web Service - access
   Amazon's product information
    • http://associates.amazon.com/exec/p
      anama/associates/join/developer/res
      ources.html
 • XMethods - collection of information
   about existing Web services
    • http://www.xmethods.com
 • SalCentral - WSDL / SOAP Web
   services search-engine
    • http://www.salcentral.com/salnet/web
      serviceswsdl.asp
What is SOAP?

   • Simple Object Access Protocol
   • Wire protocol similar to
      • IIOP for CORBA
      • JRMP for RMI
   • XML is used for data encoding
      • “text” based protocol vs. “binary” protocol
   • Supports XML-based RPC
   • W3C XML Protocol working group
      • SOAP 1.2 current version: http://www.w3.org/TR/soap12/
   • Microsoft, SUN, Oracle, HP, IBM all support the W3C
     recommendation
      • but there are still differences to be overcome
      • security issues, transactions etc.
SOAP Message Format




   Possible to Attach binaries (images, cryptographic material) to attachments
Request to HelloWorld.jws




                                     HTTP Host Target

                            HTTP Post Call

                              Method name


                        Input parameters type string
… and the HTTP Response from Server




                     Apache Tomcat Server Responding

                                       HTTP Response




                                  Method Response




              Parameter name                 Parameter value
How to make a Web service
  •   You need an application or API capable of supporting:
       • Communication over the Internet (HTTP)
       • XML Parsing capabilities

  •   Two examples of Application Servers with support:
       • Apache Tomcat Application Server with AXIS
       • Microsoft Internet Information Server

  •   JAX-RPC (JSR-101)
       • Java™ API for XML-based RPC
       • Need to implement features manually
WSDL the IDL of Web services

  WSDL is used for describing
  WebServices
  XML language for describing web
  services
  Web service is described as
     – A set of communication endpoints
     (ports)
  Endpoint is made of
     •Abstract definitions of operations and
     messages
     •Concrete binding to networking
     protocol and message format
HelloWorld.jws?wsdl
Tools

   • Generate WSDL document from
        • existing Java classes or EJB components
        • AXIS: Java2WSDL
   • Generate SOAP messages from
        • WSDL document (via client stub and server skeleton)
   • JAX-RPC, Forte for Java, JBuilder, JDeveloper
SOAP and Distributed Objects

    • SOAP in it self has nothing to do with objects
    • There is SOAP API’s for C and COBOL
    • The trick is the supporting API’s converting objects to
      WSDL and SOAP for serialization across the network
    • Using the Proxy Pattern for decoupling – perhaps with
      the Façade Pattern for larger granularity
Example Java Client
(AXIS Framework)
• Start by generating the Clients stub given the WSDL (-p = destination package = hello):
      • java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/axis/HelloWorld.jws?wsdl –p hello

      package hello;

      public class HelloWorldClient {

          public static void main (String args[]) throws Exception {


                  // Make a service
                  HelloWorldService service = new HelloWorldServiceLocator();


                  //Now use the service to get a stub which implements the SDI
                  HelloWorld stub = (HelloWorld) service.getHelloWorld();

                  String text = stub.getHelloWorldMessage("Test af OO indpakning");
                  System.out.println(”Recieved from server: "+text);
          }
      }
 Heterogeneous system C# to Java
           C# to Java

                                                     // Hello World.Java

                                                     public class HelloWorld {

                                                         public HelloWorld() {
                                                         }

                                                         public String getHelloWorldMessage(String name) {
                                                           return "Hello World to "+name;
                                                         }
                                                     }
    private void button1_Click(object sender,
      System.EventArgs e)
    {
      localhost.HelloWorldService hello =
        new localhost.HelloWorldService();
      textBox1.Text =
       hello.getHelloWorldMessage("Stefan");
    }




                         Proxy DLL stub                                  Proxy skeleton class
                        generated by VS                                   generated by AXIS
                                   Add Web Reference: We               Proxy: if we are not using
                                   need to generate a new              .JWS deployment, we
                                   Proxy DLL                           need to generate the
                                                                       skeleton classes in AXIS
Other way around works as well
                                                                       as well
Web Service Support

   • Windows
      • COM, Win32, C++/ATL, .NET (CLS e.g. C#), Java
   • Windows CE
      • eC++/eVB, .NET CF (CLS e.g. C#)
   • UNIX / LINUX
      • C++, Java
   • Mobile Devices:
      • C++ based Frameworks
      • JME CLDC MIDP 2.0 JSR 172
   • Web
      • PHP, ASP.NET, JSP/Servlets
Part 3: COM/DCOM
Goals of COM

  To provide a component object model that facilitates:
   •   Binary encapsulation
        • Clients do not have to be re-compiled if server objects change
   •   Binary compatibility
        • Client and server objects can be developed with different development
           environments and in different languages
   •   Access & Location transparency
        • in-process
        • cross-process
        • cross-machine
   •   Zero sacrifice in-proc performance
   •   Simplest model possible
        • Enable extensibility and adaptability

Almost exactly what the .NET Frameworks handles
Microsoft recommends -> use .NET not COM
Is still a major part of Win32 operating systems incl. .NET
The COM Runtime
  •   COM is a proprietary Microsoft standard
       • But other companies have implemented COM on other platforms
           (e.g. Software AG on Unix)
  •   Highly debugged and tuned
       • The COM Runtime first shipped in 1993
       • Used by 1000s of commercial applications
  •   DCOM first released in Windows NT 4.0, August 1996
       • Win95 version released January 1997
  •   COM/DCOM Available today on
       • Win95, Win98 and WinME
       • NT, Win2K and XP , Windows CE
       • Solaris, HPUX, Linux, MVS, VMS, Mac and others
  •   Free! (Built-into Win32 Platforms)
       • No separate client access license or expensive “developer” version
  •   Full source code licensable
COM History
 • COM is some what tainted by its legacy
    • 16 bit OLE 1.0: for advanced clipboard (replacing DDE)
    • 16 bit OLE 2.0: more advanced -> introducing COM
    • Visual Basic VBX: for extending Visual Basic with e.g. C++ and
      other components -> later OCX
    • OLE Controls (OCX): container implemented in DLL
    • 32-bit OLE: NT 3.51 (an shortly after Windows 95). An inter-
      process infrastructure was build on MS-RPC
    • Network-OLE: pre NT 4.0 (name dropped)
    • COM & DCOM: NT 4.0
    • ActiveX: light weight OLE Controls for e.g. Web pages. Can be
      written in C++, Delphi, VB
    • COM+: Final step of COM
COM is not C++ objects

   • COM is a Component Model
   • Distributed middleware features are only spin-off
   • And as as such is very different from C++
       • The Binary component makes the difference
       • Implemented as a DLL or an EXE (Service or stand-
         alone)
   • Like CORBA it uses an IDL language for decoupling
     (MIDL)
   • A descendent of RPC/IDL with extensions
From COM to DCOM

   • “DCOM is just COM with a longer wire” ;-)
      • It’s possible to configure even an in-proc COM-server
        DLL to be accessed from a remote PC
   • But there are differences:
      •   New kind of errors
      •   Slower response times
      •   Security becomes a very important subject
      •   No GUI - server objects can’t access GUI on Client
      •   Marshalling necessary – done in proxy-stub-DLL
 Accessing COM Services
In the same process
                                               Client                     Component
Fast, direct function calls


On the same machine                 Client Process       Server Process


Fast, secure IPC                  Client           COM                    Component




                                  Client Machine     Server Machine
Across machines
                                               DCE
Secure, reliable and     Client        COM
                                               RPC
                                                   COM                    Component
flexible DCE-RPC
based DCOM protocol
 DCOM Access Transparency

• All COM components communicate in the same way
   • on the same machine
      • In-process or
      • Out-of-process
   • across a Local Area Network
   • across a Wide Area Network
   • across the Internet
• Same tools, knowledge, code
DCOM Wire Protocol

   • Wire Protocol
      • Based on DCE RPC Specification
         • Interoperable with OSF DCE RPC
           implementations
      • MS call it “ORPC”
      • Efficient and Scalable
      • Documented in Internet-Draft
         • (ftp://ietf.org/internet-drafts/draft-brown-dcom-
           v1-spec-01.txt)
DCOM How to activate a server

   • Like all COM communication, everything starts when the client
     requests an interface from a server.
   • In DCOM, the client calls CoCreateInstanceEx(), passing in a
     description of the server computer and requesting a class
     identifier (CLSID) and Interface
   • This request is handled by the Service Control Manager (SCM),
     which is a part of Windows. The SCM is responsible for the
     creation and activation of the COM object on the server
     computer
   • In the case of DCOM, the SCM will attempt to launch the server
     on the remote computer (by contacting the SCM on the remote
     machine)
DCOM System Relationships
•   Once the remote COM server has been created, all calls will be
    marshaled through the proxy and stub objects.
•   The proxy and stub communicate using RPCs (Remote Procedure
    Calls), which handle all the network interaction.
•   On the server side, the stub object takes care of marshaling.
•   On the client, the proxy does the work.
•   The standard RPC protocol is UDP (User Datagram Protocol).
•   UDP is a connectionless protocol, which seems like a bad fit for a
    connection-oriented system like DCOM. This isn't a problem however;
    DCOM automatically takes care of connections.
The Server Doesn't Change (much)
  • Any COM server that runs as a program (EXE) will work across a
    network.
  • In general, you don't have to make any changes to a server to
    get it to work for DCOM.
  • You may, however, want to add some security to your server,
    which will involve some effort.
  • If you're using an in-process server (DLL), you will need to make
    some changes.
      • An in-process server is a DLL, which can't load across a
        network.
      • A DLL loads into the client program's address space, which
        will not work for remote connections.
      • There is a work-around called a surrogate, which wraps the
        DLL in an executable program
      • However, it is usually more appropriate to change the server
        DLL over to an EXE.
COM Support
  • Windows
    • Full COM Support
    • Make COM objects in C++
    • Use VB, Delphi, PHP, JavaScript, Java to call COM
    • .NET CLS languages has full COM wrapper support

  • Windows CE
    • No DCOM support

  • UNIX / LINUX
     • Some proprietary distributions exist
     • Assumable not easy to implement
Læringsmål Alignment
 Når kurset er færdigt forventes den studerende at kunne:               Med dagens intro
                                                                      Til DCOM, Java RMI,
 • Definere, beskrive og sammenligne forskellige typer             Web Services, WCF, skal I
    af objektorienterede middleware frameworks til               kunne redegøre for forskelle
    apparater og computere, med primær fokus på CORBA          og ligheder, styrker, svagheder,
    og sekundært .NET Remoting teknologierne, herunder            i forhold til CORBA og .NET
    fordele og ulemper forbundet med de forskellige                         Remoting.
    teknologier
 • Definere og beskrive principper omkring transparens og
    heterogenitet i relation til middlewareteknologier
 • Definere og beskrive gængse teorier, metoder og
    retningslinier indenfor det objektorienterede middleware
    paradigme og anvende disse til at designe effektive              Det forventes ikke at I
                                                             kan redegøre for DCOM, Java RMI,
    distribuerede systemer
                                                              Web services, WCF i detaljer og
 • Designe og konstruere et distribueret system der gør        med kodeeksempler. Kun forstå
    brug af CORBA og .NET Remoting teknologierne med           hvornår de kan bruges fremfor
    tilhørende værktøjssupport                                  CORBA og .NET Remoting,
                                                                   og hovedprincipperne bag

								
To top