On my previous post I've listed some of the reasons because of which I believe Microsoft's Managed Services Engine (MSE) can be really useful in Enterprise SOA applications. The existing documentation of MSE emphasizes in the role this technology can play in design time governance scenarios but there is very little about its applicability in runtime governance scenarios. However, in this release MSE already includes various features that can serve as the foundation of future runtime governance technologies. It is not a secret that service repositories are at the center of every SOA governance technologies. Normally, these repositories catalog different service components such as contracts, binding, endpoints, etc. The centralized and/or federated (I honestly think that federated repositories are the future of SOA Governance technologies. But that's content for another post J) storage of endpoints is particularly useful to enterprise applications that need to dynamically resolve those components at runtime. The classical example is an application that queries the repository to find the endpoint of a specific service.
MSE includes a service catalog that it's responsible for storing service metadata that can be used for both design time and runtime governance scenarios. As its core, MSE's service catalog is composed by the following components:
- A SQL Server 2005 DB that stores the service metadata.
- A WCF-based service that can be used to query the metadata stored in the catalog. This WCF service its hosted in a variety of endpoints in order to maximize interoperability with different client applications.
- A Windows service that serve as the host of the above mentioned WCF service.
Although the WCF service interface is not widely documented in the current version; the operations it exposes are very descriptive and easy to figure out. At this point you might already know that the first case I used this WCF API for was for dynamic endpoint resolution. Unfortunately, I wasn't entirely happy with the results L. I founded the current version of the API too strongly typed and hardly extensible. For example, in order to resolve endpoints based on different criteria we need to invoke different operations of the WCF API. Traditionally this problem is addressed using a "query language" as proposed in the UDDI v3.0 and WS-Discovery specification or as implemented by successful Web Services APIs such as Salesforce.com and Amazon.com Flexible Payment System. Among the advantages of a query language we can list the following:
- Works better for a RESTful APIs
- Facilitates versioning
- Facilitates extensibility
- Can be used generically to resolve different services components such as contracts, endpoints of bindings.
Additionally the data model is very rigid to implement complex endpoint resolution scenarios. In the current implementation the only way to resolve endpoint is using a predefined unique identifier that is generated when the endpoint is stored in the MSE catalog.
Despite of its limitations I still think that the current version of the API can be really useful to some enterprise scenarios especially for endpoint discovery and resolution. Like I said in the previous paragraph, in order to resolve different service components in MSE you have to use a unique identifier that it is assigned to each item when is stored in the MSE's catalog. Lets start with a simple WCF service that performs a simple math operation.
|
[ServiceContract()]
public interface IMyService
{
[OperationContract]
int Add(int param1, int param2);
}
public class MyService : IMyService
{
public int Add(int param1, int param2)
{
return param1 + param2;
}
} |
The service is registered in the MSE catalog as illustrated in the following picture.
In order to dynamically resolve the endpoint of this service we can use the identifier generated by MSE as illustrated in the following code.
|
private static void ResolveEndpointByID()
{
WCFCatalogSvcClient service = new WCFCatalogSvcClient();
Endpoint endpoint = service.GetEndpoint("2f062ff6-44e9-40aa-998d-1d774af6da96");
InvokeOperation("http://" + endpoint.Address, 11, 11);
}
private static void InvokeOperation(string endpointuri, int param1, int param2)
{
MyServiceClient service = new MyServiceClient();
service.Endpoint.Address = new EndpointAddress(endpointuri);
int result= service.Add(param1, param2);
} |
Similarly in case the id is no known at design time there are alternatives to resolve the endpoint based on the name of the operation we are trying to invoke.
|
private static void ResolveEndpointByOperation()
{
WCFCatalogSvcClient service = new WCFCatalogSvcClient();
string operationId= service.GetIDFromName("Add", EntityClass.Operation);
Operation operation= service.GetOperation(operationId);
InvokeOperation("http://" + operation.EndpointList.Endpoints[0].URI, 11, 11);
}
private static void InvokeOperation(string endpointuri, int param1, int param2)
{
MyServiceClient service = new MyServiceClient();
service.Endpoint.Address = new EndpointAddress(endpointuri);
int result= service.Add(param1, param2);
} |
If you have been dealing with endpoint resolution scenarios I am sure you can really appreciate this effort regardless the limitations of the API. In my case, I've lost count how many times I've implemented endpoint discovery solutions based on existing Microsoft technologies like BizTalk Server Business Rules, WF Business Rules, etc. Specifically in the case of BizTalk Server, the combination of dynamic ports and MSE can be a very interesting option for a lot of message routing enterprise scenarios.
I had been waiting until my friend Harry Pierson finishes updating his weblog to highlight this fantastic comment about the importance of idempotence.
Yesterday was a great day for the Microsoft developer community:
During the last couple of weeks I've been experimenting applying Microsoft's Managed Services Engine (MSE) to SOA Governance scenarios that I've typically addressed with HP-Systinet2, SoftwareAG and SOASoftware. Although still in very early stages (the first CTP was just announced couple of weeks ago) we can already appreciate some of the core ideas behind this technology. So why am I so excited about this effort?
The first reason is that I am a strong believer on the possibilities of a SOA Governance technology based on WCF. If you follow this blog, you know that during the last year I've been doing a lot of work with the combining some of the lead SOA Governance frameworks with WCF and BizTalk. Multiple times I ran into scenarios in which the SOA Governance technologies were insufficient to manage some of the key features exposed by the "governed" services; specifically in the case WCF applications. The fact of the matter is that a SOA Governance technology is only as good as the Web Services engine behind it. Let's use a couple of examples , in order to govern interoperable security policies a SOA Governance technology should support the latest generation WS-* protocols which includes WS-Policy, WS-Security, WS-SecureConversation, WS-Trust, etc. Almost all the SOA Governance vendors in the market, arguably HP-Systinet could be seen as an exception, face tremendous challenges on this aspect mostly because they don't include a strong Web Services engine behind the governance technology. A similar case applies when comes to modeling Web Services components such as contracts, bindings, policies, etc which are better expressed as part of the programming model of a Web Services technology than as part of the SOA Governance framework itself. In the case of MSE, the fact that its completely based on WCF notably increases the options for addressing key SOA Governance scenarios such as WS-* protocols governance, contract management, policy management, binding management, etc.
The second reason is obvious: Microsoft's Connected Systems stack needs a SOA Governance technology. Although System Center provides some interesting options for implementing runtime governance there are lots of scenarios that needs a more domain specific (I love that term J) technology that leverages the WCF programming model. With more and more Microsoft products adopting WCF as its messaging engine; the need of establish a governance strategy that can fully leverage the rich set of capabilities of the WCF programming model it's becoming a fundamental requirement of Enterprise applications.
I am not sure what is going to be the future of MSE in the Connected Systems stack; but what is undeniable is that the ideas behind this technology should serve as the core for some of the most important components of Microsoft's SOA Governance story.
In the next days I plan to blog more details about the scenarios on which I've been playing with MSE.
BEA has released a Technical Preview of WebLogic 10.1.3. Some of my favorites features include the JMS .NET API and support for SAML 2.0.
I would like to thanks all the people who attended my session last Friday. It is undeniable that the WCF adapter SDK is gaining some traction out there J . You can download the demos I walked thru the session here.