Presentation: Other Object Oriented Middlewares

Outline Web services Java RMI.NET Remoting WCF For each technology Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services For each technology Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services You may need to consult the web & litterature to gain further knowledge Strongly consider making a table (with room for all the technologies

Web Services 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.] In reality: a very much more cloudy definition

Overview SOAP & Web services Simple Object Access Protocol: A light-weight & ultra heterogenic alternative to CORBA, DCOM & RMI Openness in focus Not meant in the role of large scale, transaction heavy communication (as CORBA & J2EE) Limited support for services for transactions, concurrency, persistence, scalability Does have Interface Definition Language for heterogeneity (WSDL) Fails on several of the dist. system requirements! Easy to implement yourself And many, many frameworks

Service-Oriented Architecture Client Server Registry Abstract Architecture - Web service stack Abstract Architecture - Web service stack Legacy code on server Legacy code on server Opening up for doing business (the sharing of services)

Technologies for SOA SOAP for communication WSDL for contract & binding UDDI & WSDL for registration & discovery

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

HelloWorld.jws?wsdl Assignment: Have we defined any custom types? And how do they look like?

Alternatives to Web services based on SOAP/WSDL Hessian (binary Web services) XML-RPC (more simple, SOAP Origins) RESTFull Web services (close to HTTP) JSON (mainly for AJAX ) Burlap (much like XML-RPC but with DTO’s)

Comparision Part 1 5 minutes group work (put it into a table) Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services

Java RMI In Java 1.0 object communication confined VM Remote Method Invocation (RMI) from Java 1.1 Tight OO integration with Java Work in heterogeneous environment Designed for inter-Java communicatioin (UnicastRemoteObject/JRMP ) Limited support for inter-prog. (PortableObject 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 Distributed Garbage Collection BUT NOT IN JME!!!

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

package examples.hello; import java.rmi.Remote; import java.rmi.RemoteException; public interface Hello extends Remote { String sayHello() throws RemoteException; void someOther(String param) throws RemoteException; } rmic Compiler HelloImpl_Stub.class HelloImpl_Skeleton.class Stub Generation in Java RMI NOTE: In fact, it is the HelloImpl that is used! NOTE: In fact, it is the HelloImpl that is used! Hello.java Must Extend from Interface Remote Must Extend from Interface Remote From RMI v. 1.2 no skeleton is generated From RMI v. 1.2 no skeleton is generated

C++ Compiler, Linker Server Client.cc Server.cc C++ Compiler, Linker Client Team.idl included in generates reads IDL-Compiler Teamcl.hh Teamcl.cc Teamsv.cc Teamsv.hh CORBA Client and Server Implementation

Java compiler - javac Server HelloClient.java HelloImpl.java Java compiler - javac Client Hello.java included in generates reads rmic Compiler RMI Client and Server Implementation HelloImpl_Stub.class HelloImpl_Skeleton.class

Comparision Part 2 5 minutes group work (put it into a table) Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services

.NET Remoting.NET Remoting for intra-business purposes Is only heterogeneous across CLS languages Not supported by the.NET compact framework Relies on either HTTP/SOAP or TCP/Binary protocols, May be adapted for any type of protocol Is fast when used with TCP/Binary Only heterogeneity within.NET runtime In many ways very similar to Java RMI in Java 5

Simplified.NET Remoting Architecture Using the classic Proxy pattern The Remoting System wraps most of the marshalling/unmarshalling work for you – like CORBA Channel: Takes a stream of data and transports it to another computer or process: Default: TcpChannel & HttpChannel Channel: Takes a stream of data and transports it to another computer or process: Default: TcpChannel & HttpChannel

The Remoting Architecture Proxy created dynamically by the CLR. Creates a message to the server Serializes the message into a stream (SOAP or binary) Optional extra handling Writes the stream to the wire, e.g. TCP or HTTP Deserializes the message Developers are free to implement new channels or replace sink elements All server objects must be of type MarshalByRefObject or an descendant hereof Dispatch to server object

Remotable Objects in.NET Remoting Marshal-by-reference objects By-reference – no state is transferred MarshalByRefObject Corresponds to CORBA Interface IDL and Java RMI Remote objects (UnicastRemote objects) Proxy created Marshal-by-value objects By-value – complete object is serialized and transferred Implements ISerializable or decorated with Serializable Attribute [Serializable] Very similar to Java RMI Serializable objects Some similarity with CORBA valuetypes (Objects by Value)

The IHelloWorld Interface using System; namespace RemotingHelloServer { // IHelloWorld is the interface for the HelloWorld server class. // It is the interface that is shared across the Internet public interface IHelloWorld { string sayHello(string name); } using System; namespace RemotingHelloServer { // IHelloWorld is the interface for the HelloWorld server class. // It is the interface that is shared across the Internet public interface IHelloWorld { string sayHello(string name); } The “IDL” of.NET Remoting – similar to Java RMI

Comparision Part 2 5 minutes group work (put it into a table) Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services

Introducing WCF Windows Vista =>.NET Framework 3.0 Also for Windows XP and 2003 Server Unified Service-Oriented Programming Model Replaces / Suplements.NET Remoting DCOM ASP.NET Web services MSMQ (Queued Messaging).NET Enterprise Services Protocol Neutrality and Flexibility

WCF Basic Concepts Remote system (like.NET Remoting) is: Exchanging Messages Using Channels, consisting of Encodeders Transports Also called the Channel layer On top of this is the Service Model Layer

WCF Architecture

Bindings Many Bindings: Interopable basicHttpBinding webHttpBinding wsHttpBinding, wsFederationHttpBinding WCF Specific netTCPBinding netPeerTcpBinding netNamedPipeBinding netMsmqBinding MSMQ interop MsmqlIntegrationBinding Extensible (write your own)

Choose your Binding Before – you had to choose different middlewares Now – just choose different bindings

Bindings in WCF

Contracts Like in ASP.NET – only expose explict annotated operations

Meta Data Two ways of sharing contracts WSDL or Shared Contract DLL

Hosting Services Two models supported Self-hosting: own process (console, winform) WAS hosting Windows Activation Service IIS (Supported by IIS7, emulated for IIS6 for HTTP/S)

Configuration File <configuration xmlns=" <endpoint address=" binding="wsHttpBinding" contract="IMath"/> <configuration xmlns=" <endpoint address=" binding="wsHttpBinding" contract="IMath"/>

Comparision Part 3 5 minutes group work (put it into a table) Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services Compare: heterogenity (platform, OS, language), feasibility (ease-of-use & access transparency), object model/IDL, encoding, communication protocol, performance, price/openness, supported services