Service Agent
SeeAlso: EDRAWiki What is a Service Agent - The patterns & practices "Application Architecture for .Net guide" talks about using Service Agents to manage communication with remote services either from within a client application or even another service. We have had a lot of customers talk to us about needing similar flexibility to what the EDRA provides only within the client of the service. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp?frame=true
Candidate Design Solution - I have described an approach that people might want to take that would allow a service agent to be developed using parts of the EDRA framework - and an in-proc service interface that we have posted on the workspace. I have not had a chance to try this completely - but thought it would be more fun for other people to try this approach and update the Wiki with appropriate detail based on your experience...
There are really two major parts to the service agent:
1. inProc interface – We are going to post a prototype of this to the
GotDotNet workspace.
2. WS Target – You will need to create a new target that can instantiate a web service – essentially it needs to call the proxy that wsdl.exe generates. For an initial implementation you might want to focus on a web service target… this should be sufficient as other people can customize as necessary for other transports. The target needs to read configuration information from the .config file so that people can specify which web service proxy is getting called declaratively. You can take a look at the
SerializationTargetInvocator as a starting point
or even the dispatching target although the major difference is that the interface for the dispatching target is constant (as it conforms to the command pattern style of invocation).
<ra:targets>
<!-- Service Agent Target" -->
<ra:target ra:name="WebServiceServiceAgentTarget" ra:type="ResourceLayer.ServiceAgent.WebServiceServiceAgentTarget, ServiceAgents"/>
.
.
.
<ra:pipelines>
[<ra:serviceInterfacePipelines>]
<!-- Idea with the inproc serviceinterface transport is that it is a service agent - hence only one pipeline is required -->
<ra:pipeline ra:name="HelloWorldInProc" ra:transportName="InprocTransport" ra:serviceActionName="HelloWorld" ra:targetName="WebServiceServiceAgentTarget"/> <!-- was businessAction -->
.
.
.