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 call

CalledCalledCalledCalled

StubStub

StubStubStubStub

CallerCaller

CalledCalledCalledCalled

CallerCallerCallerCaller

Transport Layer (e.g. TCP or UDP)Transport Layer (e.g. TCP or UDP)Transport Layer (e.g. TCP or UDP)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://192.168.1.101/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 methodsfrom interface Hello.javaImplement all methods

from interface Hello.java

Extend UnicastRemoteand implemet Hello Interfacet

Extend UnicastRemoteand 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://192.168.1.101/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 stuband skeleton classes get generated

by the ”rmic” compiler

Remember – that the stuband skeleton classes get generated

by the ”rmic” compiler

AND THAT’S IT!AND THAT’S IT!

Architecture

ServerClient

Stub RegistryInterfaces

Skeleton ActivationInterfaces

RMI Runtime (rmid,rmiregistry)

coded manuallycoded manually

rmic generatedrmic generated rmic generatedrmic generated

bindbindlookuplookup

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/

panama/associates/join/developer/resources.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/

webserviceswsdl.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 attachmentsPossible to Attach binaries (images, cryptographic material) to attachments

Request to HelloWorld.jws

Input parameters type stringInput parameters type string

HTTP Post CallHTTP Post Call

HTTP Host TargetHTTP Host Target

Method nameMethod name

… and the HTTP Response from Server

HTTP ResponseHTTP Response

Method ResponseMethod Response

Parameter valueParameter valueParameter nameParameter name

Apache Tomcat Server RespondingApache 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 http://localhost:8080/axis/HelloWorld.jws?wsdl –p hello

Heterogeneous system C# to Java

Proxy DLL stubgenerated by VS

Proxy skeleton classgenerated 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 JavaC# to Java

Add Web Reference: We need to generate a new Proxy DLL

Add Web Reference: We need to generate a new Proxy DLL

Other way around works as wellOther way around works as well

Proxy: if we are not using .JWS deployment, we need to generate the skeleton classes in AXIS 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 handlesMicrosoft recommends -> use .NET not COMIs 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

ClientClient ComponentComponentIn the same process In the same process Fast, direct function calls

ClientClient ComponentComponentCOMCOM

Client ProcessClient Process Server ProcessServer ProcessOn the same machineOn the same machineFast, secure IPC

Across machinesAcross machinesSecure, reliable and flexible DCE-RPCbased DCOM protocol

COMCOMDCERPC

ClientClient

Server MachineServer MachineClient MachineClient Machine

COMCOM ComponentComponent

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 introTil 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 introTil 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 Ikan 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 Ikan 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