I've finally uploaded my ESBSimpleSamples project to CodePlex here: ESB Simple Samples
It's intended as a quick-start for using the ESB Guidance package, and it has a client library for building strongly-typed service request objects. It has two very simple sample services which return the encoded value of a given character, either in ASCII or Unicode. The services are exposed as Web services and IIS-hosted WCF, and there's a WinForms client which lets you call them directly or via ESB.
Prerequisites
To use the samples you'll need the following up and running:
- Visual Studio 2005
- BizTalk 2006 R2
- ESB Guidance package
- ESB Guidance sample app ("GlobalBank" – this is only used to save me configuring a dynamic send/receive port)
- UDDI services
Deployment
Nothing helpful in the project I'm afraid. I stripped out all the test and build artifacts before uploading, but you should only need to:
- Build & deploy the ESBSimpleSamples solution
- Create the Web services virtual directory in IIS (import settings from ESBSimpleSamples.Services.Web\Config\IISConfig.xml)
- Add UDDI settings for the Web services (in ESBSimpleSamples.Services.Web\Config\UDDISettings.xml)
- Create the WCF virtual directory in IIS (import settings from ESBSimpleSamples.Services.WCF\Config\IISConfig.xml)
- Add UDDI settings for the WCF services (in ESBSimpleSamples.Services.WCF\Config\UDDISettings.xml)
You'll need to change the paths to the SNK file in the BizTalk project, and to the project outputs in the IISConfig files.
Running
Run the WinForms client and you'll get this form:
You can check all is well with your deployment by calling the various services – with InProcess the client app instantiates service objects locally; Web and WCF call the services directly; ESB calls the Web service via ESB and ESB.WCF calls the WCF service via ESB.
Any problems are likely to be config – if the services don't respond it'll be an IIS issue, and if the ESB calls don't respond it'll be UDDI (assuming your ESB Guidance is working for other calls).
Architecture
On the service side, there's not much to it – the ServiceComponents project has the business logic and the Services.Web and Services.WCF projects wrap access to the ServiceComponents. The BizTalk project holds the Request and Response schemas which are the same for the Web and WCF services – BizTalk owns the contracts.
The WinForms client uses generated code for the Web service and WCF calls (using VS 2005 Extensions for WCF). For the ESB call there are simple DTO entities for Request and Response objects, matching the schemas (note these are handwritten rather than use the clunky output from XSD.exe – they'd be codegened from very plain templates in a real project). The ServiceRequest classes wrap usage of ESB, and expose the typed DTOs so the client is abstracted from the message bus:
ServiceRequests.GetASCIICode esbASCII = new ServiceRequests.GetASCIICode();
esbASCII.Request.Character = "a";
byte[] code = esbASCII.Response.GetASCIICodeResult;
The interesting stuff is all in the ServiceClient project. There's a generated proxy for the ESB.ItineraryServices.Response Web service; the ResolverConnection and ItineraryBuilder classes make life much easier for building itineraries in code. ESBServiceRequest is the base class for clients to build their typed requests – child classes specify the Request and Response types and only need code to prepare the request, specifying the service steps they want:
public class GetASCIICode : ESBServiceRequest<GetASCIICodeRequest, GetASCIICodeResponse>
{
public override ItineraryRequest PrepareRequest()
{
ItineraryBuilder builder = new ItineraryBuilder();
builder.AddRoutingService("ESBSimpleSamples", "GetASCIICode");
builder.AddRequestResponseService();
ItineraryRequest request = new ItineraryRequest();
request.Header = builder.GetItinerary();
request.Body = this.GetRequestBody();
return request;
}
}
In the samples project, UDDI is the chosen resolver so AddRoutingService builds up a UDDI resolver connection for the specified service. When the Response property is accessed, the base class calls for the request to be prepared, sends it to the broker and caches the response.
The ESBSimpleSamples should make the learning curve for ESB Guidance a bit shallower, and the ServiceClient library is one approach you can take for consumers. With this library most of the code is abstracted and the specifics for services can easily be codegened. From a published service, the schema, Request and Response entities, ServiceRequest class, ServiceRequest unit tests and UDDI settings can all be generated. Even if there are no .Net consumers for a service, being able to generate all this and have unit tests verifying the service response should be useful.