The Service Locator is one of the core pieces of an integration fabric that I feel needs to be available when building a common services based architecture. This is a shared service, preferably enterprise wide, which is a runtime component for the Service Registry. The root of the problem is that managing the physical end points is something of a burden.
This is missing on Windows and is something that maybe Oslo will support. A baked solution is needed as a standard for the Windows platform, whether it’s a platform service in Windows, or a server-based service like in IIS.
I’m still researching resolutions for Service Repository and Service Locator capabilities in our environment. However, instead of just complaining that I don’t have something readily available I decided it was roll up the sleeves time. I also don't relish shelling out dollars to vendors when I'm not completely convinced that these capabilities would be used, at least across business silos, even if they were already available in the enterprise.
I used David Pallmann’s blog entry Design Patterns in WCF: Service Locator as the launch point for the PoC. I think it may have been originally published on NetfxExperts.com, but is currently unavailable.
Some basic requirements I have are:
Service Repository
- Ability to store metadata about a service
- Centrally Located – well known location
- Ability to query
- Need UI
Service Locator
- Needed to query Service Repository
- Minimal client dependencies
- Needs to be abstracted away from the actual repository implementation
For the Service Repository, I chose SharePoint Server 2007 and a basic List structure - though I also used the xml file based repository along with Pallmann's sample.
I have a love/hate relationship with SharePoint, but several of our biggest value-adds back to the business have been delivered on top of SharePoint. For my initial repository, it met all of my requirements right out of the gate, with no work on my part, and I even gained several features that I hadn’t thought much about at the time, including:
- Security – use AD infrastructure to lock down service metadata changes. This is important for change management.
- Auditing – get auditing capabilities built into SharePoint through versioning.
- Workflow – get some rudimentary workflow for free that enable change approval (submissions, modifications) through SharePoint’s support for document approval.
- Notification – get alerts for free through email on item changes, including RSS subscription support.
- Views – really nice to have. Create custom views, again for free, on services that are important to you – maybe by organization, or environment.
The key pieces of information I’m looking to capture (taken directly from Pallmann) are:
- Service Name – friendly service name.
- Organization – company name, like Mary Kay, but could also be an external partner like DHL.
- Environment – development, staging, production; we actually have environments that support specific production implementations (almost a code line) - e.g. IDEV3, ICONFIG3 and PRODR3.
- Zone – intranet, internet (LAN, WAN, Internet).
- Security - what is the security supported by the service.
- Address – what is the physical end point of the service.
- Binding – what is the binding supported by the service.
- Contract – what is the contract implemented by the service.
After building the proof of concept, I thought of additional fields that might important to include:
- Region – this is a confused term in our environment, it doesn’t map 1:1 between physical (data center) and business entities (geographical region/subsidiary). For our purposes, it’s likely to mean the physical data center that hosts the service.
- Department – cost center within an organization.
- Contact - initially assuming that the entry creator is the contact person, as this is captured with SharePoint
The 'hardest' part about using SharePoint was getting a grip on CAML. I still don't have a grip on CAML, but this post on Querying Data with the CAML Query Builder V2 meant I didn't have to slow down too long.
The current SharePoint implementation looks something like this:
You can view the UI for adding a new service here.
You can view the UI for viewing an existing service here.
The Service Locator is currently a C# client library, but could just as easily be encapsulated behind a service to avoid deploying bits to a developer desktop – and likely one of my next steps. Though I did start down the road of adding a custom ConfigurationSection that supports service configuration like so:
<services>
<service name="Demo Service">
<context property="Environment" value="Development"/>
<!-- can get more specific by adding additional context -->
<context property="Organization" value="Mary Kay"/>
<context property="Contract" value="SupplyChain.IDemo"/>
</service>
</services>
When the client is promoted, its easier to update relatively static meta data values like what environment the service is running in rather than maintaining a list of urls, or addresses. Ultimately, I'd like to just have a reference to my configuration store, that is centrally located, and then have the service auto-config from that.
The client side access looks something like this:
ServiceLocator locator = new ServiceLocator();
DemoService proxy = new DemoService();
// resolve the endpoint location based
// on some configuration context
//
proxy.Url = locator.Resolve("Demo Service");
I arbitrarily chose the Spring.NET Framework as an Inversion of Control (IoC) container. This is an area that I’ve been noodeling around in as we are missing the capability from our core development library. I reviewed a couple (without actually installing) before deciding on Spring.NET. I may revisit this post PoC to see what offerings are actually pluggable with Enterprise Library. This made it easy to swap out the connection to the repository (Xml or SharePoint) through configuration.
Service Locator for Enterprise Library didn’t have any documentation and I ran out of time by the time I found it.
Does it support UDDI? No. Unfortunately, I've had a hard time wrapping my head around UDDI - I installed the Microsoft SDK. I've enabled the UDDI Service on my development server, but it just seemed overly complex (and confusing) for the basic service support I was looking for. We have big ERP and WMS implementations, which are still immature in their service offerings, but eventually standardization on something like UDDI may prove beneficial long term.
Anyway, this was a quick way to add a Service Repository and Service Locator to my teams capabilities. I'll post a revised update after we've had some burn in - I'm sure there will be many enhancements/changes along the way.
