presentation 24: rmi, web services, dcom introduction objektorienteret middleware
TRANSCRIPT
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