Introduction
Not knowing precisely the services developed and deployed in an environment is not something anyone serious about service oriented architectures can afford. In this regards, business service cartography is a key pillar of SO architectures and valuable help to get insight on your business related developments. Being able to draw a map of your business, at any time, is a must to start capitalizing, industrializing and get enough insight to predict with maximum reliability the impact of change within an organization.
Beneath the notion of business services cartography lays two main directions of work:
The first one, which is the goal of the first part of this article, is driven by the necessity to formalize contractually business processes, services and operations and is seen as static referencing.
The second one, which will be addressed in our next article, addresses the agility required by such a capability in the form of dynamic referencing.
The notion behind static referencing rests on the fact that by coupling a repository to a negotiation process you can have enough materials to build the first blocks towards contractual business services definition.
When talking about services and repository, one of the first acronyms that come up is UDDI. Universal Description Discovery and Integration is the de-facto standard when it comes to web services repository. Because UDDI comes for free with any version of Windows Server 2003, it is an inexpensive way of building business repositories. Thanks to its very expandable categorization mechanism it is the ideal candidate to build your business service repository on. Even though, its API has its flaws, once you get your grip on the philosophy behind the concepts of tModels, Categories, Bindings and so on, you are ready to rumble. This is what will be covered later on in the implementation section of this paper. The business data being referenced within the UDDI repository has to be contextualized to reflect business cases.
Once the repository issue is sorted, the next step is to find a streamlined way to formalize a negotiation process. When you mention business process and Microsoft in the same sentence, developers like us think about Microsoft Biztalk straight away. Even if the first versions had their draws, we must say that Microsoft Biztalk with 2006 release made a good step forward and more importantly in the right direction. It is therefore a safe bet to rely on Business Activity Services (BAS) and its trading partner management (TPM) feature to handle the negotiation process associated to the business repository. The negotiation phase outlined here is not about “magically” discovering new business partners but to effectively choose the most appropriate one for a particular situation. All these suppliers are already referenced within the information system and well known.
In order to achieve the level of introspection, preciseness and completeness required to draw an effective cartography of your business, Microsoft released a new methodology, technologically agnostic, meant to help you conduct the tedious phase of defining and sometime discovering your business services cartography. This methodology, called Motion, is provided by Microsoft Consulting Services. This is far from being trivial to achieve but once completed it offers a very valuable source of data that helps you drive your business as well as quickly spot where to put your $$ on.
Uddi
Introduction
UDDI is an industry wide initiative based on XML technology aiming at facilitating the publication and discovery of web services on the web. This initiative driven by OASIS has been pushed by many major actors of the IT world such as Microsoft, IBM, BEA, HP and so on. To accelerate its adoption, they quickly provided public repositories implementing this technology on the web. Unfortunately, even if it had the advantage o f showcasing the technology, those public repositories cannot be seen as the source of new commercial partnerships between companies. Indeed, it is not enough to remove the technological constraints to pretend to automate this process; UDDI is best seen as a facilitator. A similar effort to what has been done on the technological point of view has to be realized on the business side. Companies addressing the same market should come up with a common formalization of their business if they want to go further into the discovery process and follow the footsteps of business initiatives such as RosettaNet. Standardization requires a massive investment, this is why before targeting the WWW, it can be valuable to address a smaller scope that is the company and use UDDI private repositories.
As a reminder, a UDDI repository is composed of:
· White pages: similarly to phone books, they list company details, contact information and other company identifiers.
· Yellow pages: they organize data published based on business information. These pages list all the business services.
· Green pages: they regroup all the technical information related to the referenced business services.
In a situation where it is about focusing on private repositories, the enterprise notion is replaced by the notion of departments or business units.
As outlined earlier, this paper does not intend to address business classifications therefore we will focus on what we described earlier as the “Green pages” and how to publish such information in relation to Windows Communication Foundation (WCF).
Service cartography
Publishing services offered by each departments of a company does not come for free. However, for a reasonable investment a first step towards companywide service cartography is possible.
Indeed, using private repositories will allow the company, once each department completed its publication process, to benefit from a central location with a description of each business services available within its information system.
A solution exists to ensure that each department maintains the private repositories up to date are to include two new steps within the development cycles. The first one that precedes the development phase constrains the business analysts to, before writing down specifications of a new service, ensure that none is already available within the company by search through the UDDI repository. This is during this phase that the investment made on the business classification takes all its sense because the analysts will take into account the business value of the services as well as their usage context. The first obvious advantage of such as procedure is to promote capitalization and reuse.
The second step is address during the deployment phase where it consists of publishing the new services developed. This task, accomplished by technicians, is all about publishing into the repository the business information provided by the analysts as well as the technical information related to the service such as its access points, security policies and so on.
Service dependencies
Departments within a company are not isolated from one another and usually do not work in an autonomous manner. Describing these dependencies can provide crucial information when it comes to address new business requests as well as modifying existing services offerings.
By formalizing those dependencies, companies can foresee the impact of a particular modification companywide and more easily estimate its impact. UDDI offers specific elements to define dependencies between companies therefore departments. However, these elements cannot be used to describe service dependencies. The solution is therefore to define dedicated elements.
Typical scenario
This scenario which is illustrated in the video provided with this article demonstrates the whole process of referencing services, how they can be searched, published and the extra level of information it offers to developers. The scenario is inspired by the reference implementation provided by the Web Service Software Factory team.
The action takes place at Global Bank where a new module needs to be implemented. This module requires getting customer related information as well as handling payments. Three personas from a typical development cycle are involved in this process.
Business analyst
He is responsible to check that no existing services are available prior start specifying as well as ensuring the relevance and accuracy of the business categorization information added to each WCF artifacts published in the UDDI repository. He is also responsible for defining the business context and business categorization to be applied to the services that he is specifying.
Service developer
The second actor involved is the service developer; he has the responsibility to develop the service as well as its publication into the UDDI repository. If business categorizations are already available, he can include them into the service configuration file in order to be picked up automatically when publishing the service. To do so, he uses the Visual Studio add in provided to publish directly from the IDE into UDDI (as shown in the video).
Client developer
Finally, the client developer can then use Visual Studio’s “add service reference” feature to search the UDDI repository and find the WCF service he needs and if WSDL information have been publishing let Visual Studio generate a proxy to communicate with the service.
The last step in this process that is not shown in the video is that the business analyst, once the service is published into UDDI repository, will add all the business related categorization information to make this service discoverable easily to maximize its reuse.
The video available with this article demonstrates the whole process: from the business analyst who first checks for existing services, then the service developer who publishes the new service into the UDDI repository and finally the client developer who uses UDDI to find services and their WSDL if any and just adds a service reference directly from Visual Studio.
Going further
Transactional context
Most attentive will have noted that the actual version of UDDI does not offer a transactional context. Even if this lack will probably be addressed in the future UDDI release, there is no reason to constrains ourselves to not transactional publication. By migrating the UDDI web services to WCF we could easily take advantage of the built-in transactional support thus offering a more reliable experience when it comes to publishing information into the UDDI repository.
Reporting
As soon as the repository is in place and that the first services have been published, it becomes trivial to extract reports presenting the number of business services, what is the department publishing the most services, what is the most used security policy, does these critical services are all secured and so on…
And why not expect a LINQ provider to ease the creation of the queries used to generate reports?
Extend service publication
It would be very useful to offer a mean to personalize the WCF binding representation mechanisms in the form of a categorization in order to take into account all its properties and not only Enum and bool. It could also be valuable to publish the WSDL document associated with a service by taking advantage of the import / export mechanisms offered by WCF. The first step could be that when loading the service description during the publication process, indicate in the WSDL/MEX address in the tModel’s overview document associated with the binding.
Service deployment
The deployment of services could be automated by developing dedicated actions within TFS team projects.
Wrap-up
The goal of this first part was to introduce the concept of business service cartography and how, with a minor investment, UDDI can address this problematic. The most expansive part of the business service cartography is not the server or the software to operate it but the level details that you are willing to put into the categorization of your business data. In the article, we propose our own interpretation of the WCF categorization and can be seen as a starting points to derivate it to suit your business description. This solution offers a technical vision of your information system in terms of WCF services and let you easily extract meaningful report as well as promoting reuse of existing services and capitalization instead of re developing the same services.
The add in provided is also a starting points to integrate the business cartography into the development cycle by facilitating the publication process.
However, be extremely careful, even if the most vicious of you could have thought about it, and even if all the information to do it is available, your UDDI repository is not intended to address dynamic discovery. As outlined in the introduction, UDDI is all about static referencing that can be automated but more importantly tightly linked to your development cycle. It is not about updating the repository information each and every time the service starts. The problematic of dynamic discovery will be covered in the next part of this article.
Downloads
Pdf version including technical implementation details is available here
Visual Studio addin installer is available here
Video is available here
Format: wmv
Duration: 15:34