Presentation 24: RMI, Web services, DCOM Introduction Objektorienteret Middleware

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 IBM CICS BEA Tuxedo Encina Message-Oriented IBM MQSeries DEC Message Queue NCR TopEnd (SOAP) RPC Systems ANSA Sun ONC OSF/DCE (SOAP) Object-Oriented OMG/CORBA DCOM Java/RMI (SOAP)

Local Java call vs. Java RMI callCalledCalled Stub CallerCalledCalledCaller Caller Transport Layer (e.g. TCP or UDP) Similar to SOAP and CORBA – using Proxy

package examples.hello; import java.rmi.Naming; import java.rmi.RemoteException; import java.rmi.RMISecurityManager; import java.rmi.server.UnicastRemoteObject; public class HelloImpl extends UnicastRemoteObject implements Hello { public HelloImpl() throws RemoteException { super(); } public String sayHello() { return "Hello World! ; } public static void main(String args[]) { // Create and install a security manager //if (System.getSecurityManager() == null) { // System.setSecurityManager(new RMISecurityManager()); //} try { HelloImpl obj = new HelloImpl(); // Bind this object instance to the name "HelloServer" Naming.rebind("rmi:// /HelloServer", obj); System.out.println("HelloServer bound in registry"); } catch (Exception e) { System.out.println("HelloImpl err: " + e.getMessage()); e.printStackTrace(); } Server object (HelloImpl.java) Security manager needs a security policy – for access control (i.e. file system). Security manager needs a security policy – for access control (i.e. file system). Instantiate a new object and register (bind it) in the ”rmiregistry” Instantiate a new object and register (bind it) in the ”rmiregistry” Implement all methods from interface Hello.java Implement all methods from interface Hello.java Extend UnicastRemote and implemet Hello Interfacet Extend UnicastRemote and implemet Hello Interfacet ”rmiregistry” is a simpel name server with methods to bind objects (bind/rebind) – and Find them again (lookup) –> client ”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; import java.rmi.RemoteException; public class HelloClient { public static void main(String args[]) { try { Hello obj = (Hello)Naming.lookup("rmi:// /HelloServer"); String message = obj.sayHello(); System.out.println(message); } catch (Exception e) { System.out.println("HelloApplet exception: " + e.getMessage()); e.printStackTrace(); } ”lookup” the HelloServer – and call Method sayHello() on Stub ”lookup” the HelloServer – and call Method sayHello() on Stub Client object (HelloClient.java) Remember – that the stub and skeleton classes get generated by the ”rmic” compiler Remember – that the stub and skeleton classes get generated by the ”rmic” compiler AND THAT’S IT!

Architecture ServerClient Stub Registry Interfaces Skeleton Activation Interfaces RMI Runtime (rmid,rmiregistry) coded manually rmic generated bind lookup

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 engineGoogle's Web Service Amazon's Web Service - access Amazon's product informationAmazon's Web Service anama/associates/join/developer/res ources.html XMethods - collection of information about existing Web servicesXMethods SalCentral - WSDL / SOAP Web services search-engineSalCentral 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: 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 Input parameters type string HTTP Post Call HTTP Host Target Method name

… and the HTTP Response from Server HTTP Response Method Response Parameter value Parameter name Apache Tomcat Server Responding

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) 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); } Start by generating the Clients stub given the WSDL (-p = destination package = hello): java org.apache.axis.wsdl.WSDL2Java –p hello

Heterogeneous system C# to Java Proxy DLL stub generated by VS Proxy skeleton class generated by AXIS // 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"); } C# to Java Add Web Reference: We need to generate a new Proxy DLL Other way around works as well Proxy: if we are not using.JWS deployment, we need to generate the skeleton classes in AXIS 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 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 To provide a component object model that facilitates: 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

Client Component In the same process Fast, direct function calls Client Component COM Client Process Server Process On the same machine Fast, secure IPC Across machines Secure, reliable and flexible DCE-RPC based DCOM protocolCOM DCE RPC Client Server Machine Client Machine COM Component Accessing COM Services

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: Definere, beskrive og sammenligne forskellige typer af objektorienterede middleware frameworks til apparater og computere, med primær fokus på CORBA og sekundært.NET Remoting teknologierne, herunder fordele og ulemper forbundet med de forskellige 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 distribuerede systemer Designe og konstruere et distribueret system der gør brug af CORBA og.NET Remoting teknologierne med tilhørende værktøjssupport Med dagens intro Til DCOM, Java RMI, Web Services, WCF, skal I kunne redegøre for forskelle og ligheder, styrker, svagheder, i forhold til CORBA og.NET Remoting. Med dagens intro Til DCOM, Java RMI, Web Services, WCF, skal I kunne redegøre for forskelle og ligheder, styrker, svagheder, i forhold til CORBA og.NET Remoting. Det forventes ikke at I kan redegøre for DCOM, Java RMI, Web services, WCF i detaljer og med kodeeksempler. Kun forstå hvornår de kan bruges fremfor CORBA og.NET Remoting, og hovedprincipperne bag Det forventes ikke at I kan redegøre for DCOM, Java RMI, Web services, WCF i detaljer og med kodeeksempler. Kun forstå hvornår de kan bruges fremfor CORBA og.NET Remoting, og hovedprincipperne bag