![]() |
Spring's .NET Remoting support allows you to export a 'plain CLR object' as a .NET Remoted object. By "plain CLR object" we mean classes that do not inherit from a specific infrastructure base class such as MarshalByRefObject. On the server side, Spring's .NET Remoting exporters will automatically create a proxy that implements MarshalByRefObject. You register SAO types as either SingleCall or Singleton and also configure on a per-object basis lifetime and leasing parameters. On the client side you can obtain CAO references to server proxy objects in a manner that promotes interface based design best practices when developing .NET remoting applications. The current implementation requires that your plain .NET objects implements a business service interface. Additionally you can add AOP advice to both SAO and CAO objects. You can leverage the IoC container to configure the exporter and service endpoints. A remoting specific xml-schema is provided to simplify the remoting configuration but you can still use the standard reflection-like property based configuration schema. You may also opt to not use the IoC container to configure the objects and use Spring's .NET Remoting classes Programatically, as you would with any third party library. A sample application, often referred to in this documentation, is in the distribution under the directory "examples\Spring\Spring.Calculator" and may also be found via the start menu by selecting the 'Calculator' item. Exposing a Singleton SAO service can be done in two ways. The first
is through programmatic or administrative type registration that makes
calls to
AdvancedMBRCalculator calc = new AdvancedMBRCalculator(217); RemotingServices.Marshal(calc, "MyRemotedCalculator"); The class AdvancedMBRCalculator used above inherits from MarshalByRefObject. If your design calls for configuring a singleton SAO, or using a
non-default constructor, you can use the Spring IoC container to create
the SAO instance, configure it, and register it with the .NET remoting
infrastructure. The <object id="singletonCalculator" type="Spring.Calculator.Services.AdvancedCalculator, Spring.Calculator.Services"> <constructor-arg type="int" value="217"/> </object> <!-- Registers the calculator service as a SAO in 'Singleton' mode. --> <object name="saoSingletonCalculator" type="Spring.Remoting.SaoExporter, Spring.Services"> <property name="TargetName" value="singletonCalculator" /> <property name="ServiceName" value="RemotedSaoSingletonCalculator" /> </object> This XML fragment shows how an existing object "singletonCalculator"
defined in the Spring context is exposed under the url-path name
"RemotedSaoSingletonCalculator". (The fully qualified url is
tcp://localhost:8005/RemotedSaoSingleCallCalculator using the standard
.NET channel configuration shown further below.)
A custom schema is provided to make the object declaration even easier and with intellisense support for the attributes. This is shown below <objects xmlns="http://www.springframework.net" xmlns:r="http://www.springframework.net/remoting"> <r:saoExporter targetName="singletonCalculator" serviceName="RemotedSaoSingletonCalculator" /> ... other object definitions </objects> Refer to the end of this chapter for more information on Spring's .NET custom schema. The following XML fragment shows how to expose the calculator service in SAO 'SingleCall' mode. <object id="prototypeCalculator" type="Spring.Calculator.Services.AdvancedCalculator, Spring.Calculator.Services" singleton="false"> <constructor-arg type="int" value="217"/> </object> <object name="saoSingleCallCalculator" type="Spring.Remoting.SaoExporter, Spring.Services"> <property name="TargetName" value="prototypeCalculator" /> <property name="ServiceName" value="RemotedSaoSingleCallCalculator" /> </object> Note that we change the singleton attribute of the plain CLR object
as configured by Spring in the <object> definition and not an
attribute on the SaoExporter. The object referred to in the
<object id="singletonCalculatorWeaved" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop"> <property name="target" ref="singletonCalculator"/> <property name="interceptorNames"> <list> <value>Log4NetLoggingAroundAdvice</value> </list> </property> </object> <object name="saoSingletonCalculatorWeaved" type="Spring.Remoting.SaoExporter, Spring.Services"> <property name="TargetName" value="singletonCalculatorWeaved" /> <property name="ServiceName" value="RemotedSaoSingletonCalculatorWeaved" /> </object>
When using <system.runtime.remoting> <application> <channels> <channel ref="tcp" port="8005" /> </channels> </application> </system.runtime.remoting> A console application that will host this Remoted object needs to initialize the .NET Remoting infrastructure with a call to RemotingConfiguration (since we are using the .config file for channel registration) and then start the Spring application context. This is shown below RemotingConfiguration.Configure("RemoteApp.exe.config"); IApplicationContext ctx = ContextRegistry.GetContext(); Console.Out.WriteLine("Server listening..."); Console.ReadLine(); You can also put in the configuration file an instance of the
object <objects xmlns="http://www.springframework.net" xmlns:r="http://www.springframework.net/remoting"> <r:configurer filename="Spring.Calculator.RemoteApp.exe.config" /> </objects> The ReadLine prevents the console application from exiting. You can refer to the code in RemoteApp in the Remoting QuickStart to see this code in action. If you are deploying a .NET remoting application inside IIS there is a sample project that demonstrates the necessary configuration using Spring.Web. Spring.Web ensures the application context is initialized, but if you don't use Spring.Web the idea is to start the initialization of the Spring IoC container inside the application start method defined in Global.asax, as shown below void Application_Start(object sender, EventArgs e) { // Code that runs on application startup // Ensure Spring has loaded configuration registering context Spring.Context.IApplicationContext ctx = new Spring.Context.Support.XmlApplicationContext( HttpContext.Current.Server.MapPath("Spring.Config")); Spring.Context.Support.ContextRegistry.RegisterContext(ctx); } In this example, the Spring configuration file is named Spring.Config. Inside Web.config you add a standard <system.runtime.remoting> section. Note that you do not need to specify the port number of your channels as they will use the port number of your web site. Ambiguous results have been reported if you do specify the port number. Also, in order for IIS to recognize the remoting request, you should add the suffix '.rem' or '.soap' to the target name of your exported remote object so that the correct IIS handler can be invoked. Administrative type registration on the client side lets you easily
obtain a reference to a SAO object. When a type is registered on the
client, using the new operator or using the reflection API will return a
proxy to the remote object instead of a local reference. Administrative
type registration on the client for a SAO object is performed using the
There is a simple means for following this design when the remote
object is a SAO object. A call to ICalculator calc = (ICalculator)Activator.GetObject ( typeof (ICalculator), "tcp://localhost:8005/MyRemotedCalculator"); To obtain a reference to a SAO proxy within the IoC container, you
can use the object factory <object id="calculatorService" type="Spring.Remoting.SaoFactoryObject, Spring.Services"> <property name="ServiceInterface" value="Spring.Calculator.Interfaces.IAdvancedCalculator, Spring.Calculator.Contract" /> <property name="ServiceUrl" value="tcp://localhost:8005/RemotedSaoSingletonCalculator" /> </object> The ServiceInterface property specifies the type of proxy to create while the ServiceUrl property creates a proxy bound to the specified server and published object name. Other objects in the IoC container that depend on an implementation
of the interface Creating a client activated object (CAO) is typically done by
administrative type registration, either Programatically or via the
standard .NET remoting configuration section. The registration process
allows you to use the 'new' operator to create the remote object and
requires that the implementation of the object be distributed to the
client. As mentioned before, this is not a desirable approach to
developing distributed systems. The best practice approach that avoids
this problem is to create an SAO based factory class on the server that
will return CAO references to the client. In a manner similar to how
Spring's generic object factory can be used as a replacement creating a
factory per class, we can create a generic SAO object factory to return
CAO references to objects defined in Spring's application context. This
functionality is encapsulated in Spring's
To expose an object as a CAO on the server you should declare an
object in the standard Spring configuration that is a 'prototype', that is
the singleton property is set to false. This results in a new object being
created each time it is retrieved from Spring's IoC container. An
implementation of This is best shown using an example from the Remoting Quickstart application. Here is the definition of a simple calculator object, <object id="prototypeCalculator" type="Spring.Calculator.Services.AdvancedCalculator, Spring.Calculator.Services" singleton="false"> <constructor-arg type="int" value="217" /> </object> To export this as a CAO object we can declare
the <object id="caoCalculator" type="Spring.Remoting.CaoExporter, Spring.Services"> <property name="TargetName" value="prototypeCalculator" /> <property name="Infinite" value="false" /> <property name="InitialLeaseTime" value="2m" /> <property name="RenewOnCallTime" value="1m" /> </object> Note the property 'TargetName' is set to the name, not the reference, of the non-singleton declaration of the 'AdvancedCalculator' class. Alternatively, you can use the remoting schema and declare the CAO object as shown below <r:caoExporter targetName="prototypeCalculator" infinite="false"> <r:lifeTime initialLeaseTime="2m" renewOnCallTime="1m" /> </r:caoExporter> Applying AOP advice to exported CAO objects is done by referencing the adviced object name to the CAO exporter. Again, taking an example from the Remoting QuickStart, a calculator with logging around advice is defined as shown below. <object id="prototypeCalculatorWeaved" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop"> <property name="targetSource"> <object type="Spring.Aop.Target.PrototypeTargetSource, Spring.Aop"> <property name="TargetObjectName" value="prototypeCalculator" /> </object> </property> <property name="interceptorNames"> <list> <value>ConsoleLoggingAroundAdvice</value> </list> </property> </object> If this declaration is unfamiliar to you, please refer to Chapter 13, Aspect Oriented Programming with Spring.NET for more information. The CAO exporter then references with the name 'prototypeCalculatorWeaved' as shown below. <r:caoExporter targetName="prototypeCalculatorWeaved" infinite="false"> <r:lifeTime initialLeaseTime="2m" renewOnCallTime="1m" /> </r:caoExporter> On the client side a CAO reference is obtained by using the
<object id="calculatorService" type="Spring.Remoting.CaoFactoryObject, Spring.Services"> <property name="RemoteTargetName" value="prototypeCalculator" /> <property name="ServiceUrl" value="tcp://localhost:8005" /> </object> This definition corresponds to the exported calculator from the
previous section. The property 'RemoteTargetName' identifies the object on
the server side. Using this approach the client can obtain an reference
though standard DI techniques to a remote object that implements the
Alternatively, you can use the Remoting schema to shorten this definition and provide intellisense code completion <r:caoFactory id="calculatorService" remoteTargetName="prototypeCalculator" serviceUrl="tcp://localhost:8005" /> Please install the XSD schemas into VS.NET as described in Chapter 36, Visual Studio.NET Integration. XML intellisense for the attributes of the saoExporter, caoExporter and caoFactory should be self explanatory as they mimic the standard property names used to configure .NET remote objects. Two articles that describe the process of creating a standard SAO factory for returning CAO objects are Implementing Broker with .NET Remoting Using Client-Activated Objects on MSDN and Step by Step guide to CAO creation through SAO class factories on Glacial Components website.
|