Get documents about "Object Models for Distributed Systems (PowerPoint)
Document Sample
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
