Objektorienteret Netværkskommunikation Presentation 23 NET Remoting Introduced

Objektorienteret Netværkskommunikation Presentation 23: . NET Remoting Introduced

Outline • . NET Framework introduced • . NET Remoting • • Strategies Architecture Remoting object types Activation Lifetime Deployment Example application • Windows Communication Foundation short intro

Not a Windows. NET course • You will NOT be required to be an expert on. NET • You will be required to be knowledgeable about it • History: • Open source, Java, Linux the WWW threatened MS • Especially Java was gaining widespread support amongst developers for its ease of use, productivity and heterogeneity • The Empire Strikes back = the. NET Framework

Benefits of. NET • Changes EVERYTHING • Takes all that was nice in Java and enhances it • End of DLL incompatibilities, DLL Hell, COM registry hell • Enter world of VM’s and Java like code (C#) including Garbage collection – BUT with easy support for legacy unmanaged code (e. g. C++ for speed) and COM • Performs much better than Java, and almost equivalent with Win 32 C++ applications • Still only support Microsoft operating systems BUT • . NET and C# is ECMA standard: Mono (www. go-mono. org) for Linux is being developed. • IIOP. NET (http: //iiop-net. sourceforge. net/index. html) for CORBA interop

. NET Framework Any language conforming to the Common Language Visual C++ Specification Basic (CLS) may be used. C# Perl JScript XML Web Services For inter-process communications Source code Compiler User Interface Active. X Data Objects ADO. NET and XML Here we find the. NET Remoting libraries A collection of class libraries (over 9000) wraps Win 32 like Java API Application services. E. g. IIS, Message Queuing etc. … . NET Framework Class Library Common Language Runtime COM+ (Transactions, Partitions, Object Pooling) Message Queuing. NET Framework Intermediate Language Other IL libraries Linker IIS WMI Win 32 Linked Program 3 types of user interfaces: Web forms, Windows forms (Win 32), Command Console JIT-compiler Executable Program CLR: runtime execution environment. Equlas JVM of Java. Microsoft Intermediate Language (MSIL) equals Java Byte. Code

Strategies • Two. NET Remoting strategies (+ new strategy WCF) : • Web services for inter-business purposes • Is heterogeneous across platforms and languages • Supported by the. NET compact framework • Relies primarily on HTTP/SOAP protocols, • May be adapted for any type of protocol • Heterogeneous • Is slow when used with HTTP/SOAP • . 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 The Remoting System wraps most of the marshalling/unmarshalling work for you – like CORBA Using the classic Proxy pattern Channel: Takes a stream of data and transports it to another computer or process: Default: Tcp. Channel & Http. Channel

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

Remotable Objects in. NET Remoting • Marshal-by-reference objects • By-reference – no state is transferred • Marshal. By. Ref. Object • Corresponds to CORBA Interface IDL and Java RMI Remote objects (Unicast. Remote 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)

Activation • All server objects needs to be activated before a client proxy may access it • Two types of activation • Server Activation (SAO) • Activated when first client request arrives at server – Singleton: only one server instance for all clients – Single-call: a new server object pr. client request • Lifetime is defined by server • Client Activation (CAO) • Activated by the client with the Create. Instance method on the Activator object • Server object only associated with creating client • Lifetime is controlled by client (using leases) • Very different semantics than CORBA & RMI – closer to Web services (application, session, request scope) especially SAO

Lifetime management • • • . NET Remoting uses leases for lifetime management • All server objects has a lifetime lease – a time-to-live • Lease manager • controls the server object leases • If expired – check all sponsors (clients) • performs garbage collection on server objects In DCOM • reference counting & pinging In CORBA • ORB vendor specific • Often implemented as “time since last request” In Java RMI • uses leases (similar to. NET Remoting). Clients auto-update lease at 50% Web services • Toolkit specific (HTTP primitives: Application, Session, Request) • Application scope = runs for-ever / singleton

Configuration • Configuration: • Need to inform runtime which servers are available and at which address (URL) • Two types of configuration • Programmatic (shown in example next) • Configuration file • Web. config (e. g. with IIS) or Machine. config

Deployment • Server objects may be deployed as: • • Windows Form application Windows Console application Windows Service Internet Information Server deployment • no need for a server bootstrapping application

Development Steps – Remoting vs. CORBA & Java RMI CORBA. NET Remoting Design J 2 SE JDK Start with Server Interface Coding: JAVA Server Stub Generation Interface Definition CORBA: IDL CLS Interface RMI: JAVA interface Implicit stub gen. CORBA: IDL Client Stub Generation Java RMI: rmic CLS (C# …) C++, Java … Server Coding Client Coding RMI: JAVA CLS (C# …) C++, Java … Remoting Configuration with CLR Server Registration ORB rmiregistry

Making the Hello. World App • Using Microsoft Visual Studio. NET • may of course be done with. NET Framework alone • Make Client & Server solutions • Server: • IHello. World. cs interface • Hello. World. cs class implementation • Server. cs class implementation for boot-strapping • Add Reference to assembly System. Runtime. Remoting • Client • Must add IHello. World. cs • Client. cs class implementation • Add Reference to assembly System. Runtime. Remoting

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

Hello. World Implementation Code using System; using System. Runtime. Remoting; namespace Remoting. Hello. Server { // Hello. World is a server object that is available // "by-reference". It contains a constructor and a the // "say. Hello" method taking a string parameter "name" public class Hello. World : Marshal. By. Ref. Object, IHello. World { private string greeting; A remote object “by-reference” that implements the IHello. World interface public Hello. World() { greeting = "OOMI Christsmas greetings from the server to: "; } public string say. Hello(string name) { return (greeting + name); } Implementing the say. Hello method } } Like in Java RMI (& CORBA) – we need to have an implementation of the interface

Server Code – Console Bootstrapping using System; Like in Java RMI (& CORBA) – we need some using System. Runtime. Remoting; bootstrapping code – a server process using System. Runtime. Remoting. Channels; using System. Runtime. Remoting. Channels. Tcp; namespace Remoting. Hello. Server This may become a Windows NT service or a simple { application, e. g. a console or Windows Form application public class Server { [STAThread] static void Main(string[] args) { //Create a TCP channel Register the channel Tcp. Channel the. Channel = new Tcp. Channel(8085) on port 8085 /* Register the channel so that clients can * connect to the server */ Channel. Services. Register. Channel(the. Channel); //Register the service on the channel Remoting. Configuration. Application. Name = "Hello. World App"; Remoting. Configuration. Register. Well. Known. Service. Type( typeof(Hello. World), "Hello. World App", Well. Known. Object. Mode. Single. Call); /*Start the server and keep it running so that clients * can connect to it. May be aborted by keypress */ System. Console. Write. Line("Press Enter to end this server process"); System. Console. Read(); } } } Register the object

Client Code – Console Bootstrapping … include all the Remoting stuff namespace Remoting. Hello. Client { public class Client { [STAThread] static void Main(string[] args) { Tcp. Channel the. Channel = new Tcp. Channel(); Channel. Services. Register. Channel(the. Channel); Optional (may be done implicitly) /* Activate the server object. Activation will bring * the server object to life, and create a proxy * stub class of the Hello. World. In fact, as this is a * server-activated application, the call to the * server is NOT performed now, but instead waits until the * first request. It is thus the server who performs the * activation. This is the "Lazy-activation pattern" known * from e. g. CORBA */ IHello. World hello. World = (IHello. World) Activator. Get. Object( typeof(Remoting. Hello. Server. IHello. World), "tcp: //localhost: 8085/Hello. World App"); System. Console. Write. Line("Please enter your name and press Enter"); string name = System. Console. Read. Line(); //Make the call string greeting = hello. World. say. Hello(name); System. Console. Write. Line("We recieved from server: "+greeting); System. Console. Write. Line("Press Enter to end"); System. Console. Read(); } } } Create Proxy Call via Proxy object

Configuration Strategi • Alternative to Programmatic strategi: • Use a Server Configuration file (Listener. exe. config) configuration> <system. runtime. remoting> <application> <service> <wellknown mode="Singleton" type="Remotable. Type, Remotable. Type" object. Uri="Remotable. Type. rem" /> </service> <channels> <channel ref="http" port="8989"/> </channels> </application> </system. runtime. remoting> </configuration>

Server Side Config Bootstrap • Still need to implement: interface, Marshal. By. Ref • But boostrapping is much simpler using System; using System. Runtime. Remoting; public class Listener { public static void Main() { Remoting. Configuration. Configure("Listener. exe. config", false); Console. Write. Line("Listening for requests. Press enter to exit. . . "); Console. Read. Line(); } }

Client Configuration Strategi • A Client Configuration file (Client. exe. config) <configuration> <system. runtime. remoting> <application> <client> <wellknown type="Remotable. Type, Remotable. Type" url="http: //localhost: 8989/Remotable. Type. rem" /> </client> </application> </system. runtime. remoting> </configuration>

Client Side Config Load + Proxy • Still need to implement: interface, Marshal. By. Ref • Generating dynamic proxy stub is simpler (VB. NET) Imports System. Runtime. Remoting Public Shared Sub Main() Remoting. Configuration. Configure(“Client. exe. config") Dim remote. Object As New Remotable. Type() Console. Write. Line(remote. Object. Say. Hello()) End Sub 'Main

Windows Communication Foundation (Kursorisk) • 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 http: //msdn. microsoft. com/library/default. asp? url=/library/en-us/dnlong/html/wcfroadmap. asp http: //msdn. microsoft. com/library/default. asp? url=/library/en-us/dnlong/html/wcfarch. asp

Defining the Contract using System. Service. Model; //a WCF contract defined using an interface [Service. Contract] public interface IMath { [Operation. Contract] int Add(int x, int y); } //the service class implements the interface public class Math. Service : IMath { public int Add(int x, int y) { return x + y; } }

Implementing the Service public class WCFService. App { public void Define. Endpoint. Programmable() { //create a service host for Math. Service. Host sh = new Service. Host(typeof(Math. Service)); //use the Add. Endpoint helper method to //create the Service. Endpoint and add it //to the Service. Description sh. Add. Service. Endpoint( typeof(IMath), //contract type new WSHttp. Binding(), //one of the built-in bindings "http: //localhost/Math. Service/Ep 1"); //the endpoint's address Create the Service Endpoint Programmatically //create and open the service runtime sh. Open(); } public void Define. Endpoint. In. Config() { //create a service host for Math. Service. Host sh = new Service. Host (typeof(Math. Service)); //create and open the service runtime sh. Open(); } } Create the Service Endpoint Using a Configuration File (see next slide)

Configuration File  <configuration xmlns="http: //schemas. microsoft. com/. Net. Configuration/v 2. 0"> <system. service. Model> <services>  <service type="Math. Service">  <endpoint address="http: //localhost/Math. Service/Ep 1" binding="ws. Http. Binding" contract="IMath"/> </services> </system. service. Model> </configuration>

Implementing the Client Using Static Proxy //this class is generated by svcutil. exe //from the service's metadata //generated config is not shown here public class Math. Proxy : IMath {. . . } public class WCFClient. App { public void Send. Message. To. Endpoint() { //this uses a proxy class that was //created by svcutil. exe from the service's metadata Math. Proxy proxy = new Math. Proxy(); int result = proxy. Add(35, 7); }

Implementing the Client Using Dynamic Proxy public class WCFClient. App { public void Send. Message. To. Endpoint. Using. Channel() { //this uses Channel. Factory to create the channel //you must specify the address, the binding and //the contract type (IMath) Channel. Factory<IMath> factory=new Channel. Factory<IMath>( new WSHttp. Binding(), new Endpoint. Address("http: //localhost/Math. Service/Ep 1")); IMath channel=factory. Create. Channel(); int result=channel. Add(35, 7); factory. Close(); }

Plenum Discussion • Use 5 minutes in your groups: • Differences with Web services / Java RMI / CORBA? • Strength over Web services / Java RMI / CORBA? • Weaknesses compared to –”-? • Plenum: 5 minutes discussion of findings

Alignment med læringsmål Når kurset er færdigt forventes den studerende at kunne: • redegøre for de grundlæggende principper og teknikker omkring interproceskommunikation over såvel lokalnetværk som Internettet • redegøre for teknikker for distribuerede objektorienterede løsninger, herunder serialisering, marshalling, stub/skeleton, proxy, brug af Hvornår vælge hvilken teknolog, forskellige Interface Definition Language sprog som udviklingskontrakt der skal vælges • redegøre for principperne omkring transparens og heterogenitet (platforms og programmeringssprogs uafhængighed) • redegøre for anvendelsen af Java RMI, XML/SOAP (Webservices), herunder forskelle/ligheder, fordele/ulemper teknologierne imellem. Samt på overordnet niveau have kendskab til forskelle og ligheder med CORBA og. NET Remoting teknologierne • anvende socket programmering til at lave et mindre distribueret system baseret på objektorienterede principper • anvende objektorienterede teknikker og arkitekturer til at designe og Forstå at. NET Remoting programmere netværksforbindelser ved brug af middleware, og bevise kan bruges binært+SOAP, dette ved ingen IDL, er semi-heterogent at konstruere og dokumentere to distribuerede systemer der har en ”pæn” objekt brug af ovenstående teknologier gør struktur. Også bruger stubs. Kunne genkende på koden at det er. NET Remoting. Men ikke forstå koden i detaljer