Migrating to SOA - Composing Services
Well, I’ve nearly finished my talk. Today I completed the section entitled “Walk…”, where I talk about extensions to a simple Web Service architecture that improved the architecture, and allow you to build new business processes from existing services. This section breaks into three pieces, namely 1. Using interception services to provide functionality common to all services (many people call these cross-cutting concerns). A common mechanism for implementing this is to use pipelines to intercept the incoming and outgoing messages, and pass them through a series of handlers that provide the interception services (things like authentication, authorisation etc). A great example of this kind of architecture is Shadowfax (now called Enterprise Development Reference Architecture). BizTalk also uses a similar architecture.
2. Composing services from multiple other services (for an example of this, look at this chapter in the Integration Patterns book). This is a good pattern for combining information from multiple sources, providing a single interface to multiple (possibly horizontally) scaled systems etc.
3. Building completely new business processes from existing services (see this chapter in the Integration Patterns book). This pattern describes hoe build on your existing services to create new business processes, and how to make these new processes resilient, with transactions, exception handling etc.
Tomorrow, I’ll work on the final section (Run…), where I talk about Business Activity Monitoring, and Business Rules.
I do have one question to throw out to anyone that wants to venture an opinion. When designing schemas for an enterprise, it’s pretty common to build canonical schemas. These represent the authoritative definition for entities within the enterprise. I usually recommend that schemas be built for each business process being exposed as a web service. However, some architects I have encountered propose to create a single (large) canonical schema that represents the entire enterprise. I can see some benefits from this approach (guaranteed common definition across the entire enterprise), but I think there are also many disadvantages (very complex schema, difficult to create a schema that all business units agree on). If you have any thoughts, or experiences to share about this, I’d be interested to hear.
