Object Models for Distributed Systems
Download
Report
Transcript Object Models for Distributed Systems
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
Win32 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 C++
(CLS) may be
used.
XML Web Services
For inter-process
communications
Source
code
Compiler
JScript
…
User Interface
ActiveX Data
Objects
ADO.NET and XML
Here we find the .NET Remoting libraries
A collection of
class libraries
(over 9000)
wraps Win32 like
Java API
Application
services. E.g.
IIS, Message
Queuing etc.
Perl
.NET Framework Class Library
Common Language Runtime
COM+
(Transactions, Partitions,
Object Pooling)
Message
Queuing
.NET
Framework
Intermediate
Language
Other IL
libraries
Linker
IIS
WMI
Win32
Linked
Program
3 types of user
interfaces: Web
forms, Windows
forms (Win32),
Command Console
JIT-compiler
Executable
Program
CLR:runtime
execution
environment.
Equlas JVM of
Java. Microsoft
Intermediate
Language (MSIL)
equals Java
ByteCode
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:
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)
All server objects must be of
type MarshalByRefObject 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
• 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)
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 CreateInstance 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
J2SE 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 HelloWorld App
• Using Microsoft Visual Studio .NET
• may of course be done with .NET Framework alone
• Make Client & Server solutions
• Server:
• IHelloWorld.cs interface
• HelloWorld.cs class implementation
• Server.cs class implementation for boot-strapping
• Add Reference to assembly System.Runtime.Remoting
• Client
• Must add IHelloWorld.cs
• Client.cs class implementation
• Add Reference to assembly System.Runtime.Remoting
The IHelloWorld Interface
The “IDL” of .NET Remoting – similar to Java RMI
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);
}
}
HelloWorld Implementation Code
using System;
using System.Runtime.Remoting;
namespace RemotingHelloServer
{
// HelloWorld is a server object that is available
// "by-reference". It contains a constructor and a the
// "sayHello" method taking a string parameter "name"
public class HelloWorld : MarshalByRefObject, IHelloWorld
{
private string greeting;
A remote object
“by-reference” that
implements the IHelloWorld
interface
public HelloWorld()
{
greeting = "OOMI Christsmas greetings from the server to: ";
}
public string sayHello(string name)
{
return (greeting + name);
}
Implementing the
sayHello 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 RemotingHelloServer
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
TcpChannel theChannel = new TcpChannel(8085)
on port 8085
/* Register the channel so that clients can
* connect to the server */
ChannelServices.RegisterChannel(theChannel);
//Register the service on the channel
RemotingConfiguration.ApplicationName = "HelloWorld App";
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(HelloWorld),
"HelloWorld App",
WellKnownObjectMode.SingleCall);
/*Start the server and keep it running so that clients
* can connect to it. May be aborted by keypress */
System.Console.WriteLine("Press Enter to end this server process");
System.Console.Read();
}
}
}
Register the
object
Client Code
– Console Bootstrapping
… include all the Remoting stuff
namespace RemotingHelloClient
{
public class Client
{
[STAThread]
static void Main(string[] args)
{
TcpChannel theChannel = new TcpChannel();
ChannelServices.RegisterChannel(theChannel);
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 HelloWorld. 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 */
IHelloWorld helloWorld = (IHelloWorld) Activator.GetObject(
typeof(RemotingHelloServer.IHelloWorld),
"tcp://localhost:8085/HelloWorld App");
System.Console.WriteLine("Please enter your name and press Enter");
string name = System.Console.ReadLine();
//Make the call
string greeting = helloWorld.sayHello(name);
System.Console.WriteLine("We recieved from server: "+greeting);
System.Console.WriteLine("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="RemotableType, RemotableType"
objectUri="RemotableType.rem"
/>
</service>
<channels>
<channel ref="http" port="8989"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Server Side Config Bootstrap
• Still need to implement: interface, MarshalByRef
• But boostrapping is much simpler
using System;
using System.Runtime.Remoting;
public class Listener
{
public static void Main()
{
RemotingConfiguration.Configure("Listener.exe.config", false);
Console.WriteLine("Listening for requests. Press enter to exit...");
Console.ReadLine();
}
}
Client Configuration Strategi
• A Client Configuration file (Client.exe.config)
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown
type="RemotableType, RemotableType"
url="http://localhost:8989/RemotableType.rem"
/>
</client>
</application>
</system.runtime.remoting>
</configuration>
Client Side Config Load + Proxy
• Still need to implement: interface, MarshalByRef
• Generating dynamic proxy stub is simpler (VB.NET)
Imports System
Imports System.Runtime.Remoting
Public Shared Sub Main()
RemotingConfiguration.Configure(“Client.exe.config")
Dim remoteObject As New RemotableType()
Console.WriteLine(remoteObject.SayHello())
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.ServiceModel;
//a WCF contract defined using an interface
[ServiceContract]
public interface IMath
{
[OperationContract]
int Add(int x, int y);
}
//the service class implements the interface
public class MathService : IMath
{
public int Add(int x, int y)
{ return x + y; }
}
Implementing the Service
public class WCFServiceApp
{
public void DefineEndpointProgrammable()
{
//create a service host for MathService
ServiceHost sh = new ServiceHost(typeof(MathService));
//use the AddEndpoint helper method to
//create the ServiceEndpoint and add it
//to the ServiceDescription
sh.AddServiceEndpoint(
typeof(IMath), //contract type
new WSHttpBinding(), //one of the built-in bindings
"http://localhost/MathService/Ep1"); //the endpoint's address
Create the
Service Endpoint
Programmatically
//create and open the service runtime
sh.Open();
}
public void DefineEndpointInConfig()
{
//create a service host for MathService
ServiceHost sh = new ServiceHost (typeof(MathService));
//create and open the service runtime
sh.Open();
}
}
Create the
Service Endpoint
Using a Configuration
File (see next slide)
Configuration File
<!-- configuration file used by above code -->
<configuration
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.serviceModel>
<services>
<!-- service element references the service type -->
<service type="MathService">
<!-- endpoint element defines the ABC's of the endpoint -->
<endpoint
address="http://localhost/MathService/Ep1"
binding="wsHttpBinding"
contract="IMath"/>
</service>
</services>
</system.serviceModel>
</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 MathProxy : IMath
{
...
}
public class WCFClientApp
{
public void SendMessageToEndpoint()
{
//this uses a proxy class that was
//created by svcutil.exe from the service's metadata
MathProxy proxy = new MathProxy();
int result = proxy.Add(35, 7);
}
Implementing the Client
Using Dynamic Proxy
public class WCFClientApp
{
public void SendMessageToEndpointUsingChannel()
{
//this uses ChannelFactory to create the channel
//you must specify the address, the binding and
//the contract type (IMath)
ChannelFactory<IMath> factory=new ChannelFactory<IMath>(
new WSHttpBinding(),
new EndpointAddress("http://localhost/MathService/Ep1"));
IMath channel=factory.CreateChannel();
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 at konstruere og dokumentere to distribuerede systemer der
ingen IDL, er semi-heterogent
har en ”pæn” objekt
gør brug af ovenstående teknologier
struktur. Også bruger stubs.
Kunne genkende på koden
at det er .NET Remoting. Men ikke forstå
koden i detaljer