Service Oriented Architecture, Service Factories and Modelling
As there some organisations are trying to find their way into SOA, some are still struggling. What I want to do here is to provide some guidance information and some answers to fundamental questions companies should answer to jump-start onto SOA.
And I am not going to bore you neither with yet another description of SOA nor explanation of the SOA tenets but look at SOA from a more real-life perspective, real questions and possible answers.
Please note that I assume you have some kind of an understanding about Capability Modelling. If not, have a look at this great article on Microsoft Services Business Architecure (MSBA aka Motion) before you continue.
First of all, organisations still need to answer the following questions in their domain to realise SOA's potential and what it can deliver for them.
- What is a Service? This is a critical question and despite the fact there are virtually unlimited number of answers in the industry, companies should answer the question within their own domain considering their organisational structure and enterprise architecture and it should also reflect their expectations from a service.
- How and Where to start SOA? This question is about finding the first service in your organisation to move onto SOA platform. Even with companies which justify the move onto SOA conceptually and commercially, it is a very common struggle finding the first service to implement. What are the characteristics of this first service? What makes of good service candidate?
- How to Develop and Integrate a Service? Another challenge for organisations as developing SOA service different from traditional development approaches. While methods such as OOAD support development of service components, they are not sufficient to identify, define, develop and deliver a service in SOA.
- How to Manage SOA (and its Services)? Operating, managing and governing services are one of the fundamental challenges with services and SOA environment. Because each and every company has different structures, different ownerships, it is very difficult to find a single solution and adapt it. When organisations answer the first question and there should be enough information to shape and management approach to SOA.
I will try to address all of the questions above and will try to provide high level solutions. Then I will look at Microsoft technology stack and map those solutions onto these technologies and products by also looking at patterns and best practices around them.
Service Factory is a unified set of integrated tools and processes to enable identification, definition, development and delivery of services in a consistent, repeatable and predictable way. Let's have a look at my proposed factory design which empowers modelling at its heart:
Modelling is a process of capturing information using model templates and schemas identified below. Combining with the automation capabilities of your service factory, it enables creation of templates for you from the previous model. For example, depending on the Service Model, right Source Templates are created for you, orchestration files, class files, XML schemas. Besides, automation also enables you to partially complete these templates.
Let's start with an example: if you want to create an agenda, you open up Word and choose agenda as your template, and then you capture your agenda items and save it. Or if you want to create a purchase order XML file, you use purchase order schema to do that. Same as here, to capture the models in your process, you need templates or schemas if you like to capture required information.
In your Service Factory, you can use the following templates to capture model information:
- Capability Model Templates: These templates are required to capture information about and related to the business capability you want to develop. For example, you capture information such as how owns the capability, how it works, what are the relations to other capabilities etc. Capability Model Templates help you capture more high level information, or metadata of the capability. This information will be used to create Service Model Templates which will capture more detailed information.
- Service Model Templates: These are required to capture service level information such as what is the function of the service, how it is secured, where is it hosted, how does it integrate to other services, how it is managed etc. This information is captured in a very detailed way to enable automation of source code and template generation.
- Source Code Templates: Source Code templates are used to capture the implementation details of the service and its related components. Today, we already use them, for example, we have templates for C# classes and BizTalk orchestrations. However, this time these templates are partially completed based the requirements you captured in your Service Model.
You can view models as detailed requirements captured as both human and software readable artefacts which ideally can represented visually and templates as tools to capture this information.
From the templates I identified above, you can produce:
- Capability Models: represent high level characteristics of the Business Capability you want to develop. Based on the information captured in this model, Service Model Templates are created.
- Service Models: represent the low level requirements of the Service, eventually the Business Capability you want to develop. Based on the information captured in this model, Source Code Templates are created.
- Source Code Models: represent the implementation details of the Service in an executable form.
Models also enable following core capabilities:
- Traceability: Because models represent the particular domain at different granularity, they are traceable; in other words you can trace information on model to information captured in another model. This provides high level visibility of the service being developed. When you are modelling particular feature of the service, you know how it relates back to the capability being developed.
- Forward Engineering: Models also enables us to automation of source code generation. For example, if I model a business process, my factory auto-generates a BizTalk orchestration file (Source Code Template) for me.
As you can imagine, because the Service Models capture very detailed information about the service, they can be very complicated and can be very difficult to manage, therefore it is wise to divide them into other models, sub-models if you like. In my proposal I use the following models to represent a Service Model:
Functional Model: This model represents functionality of the service such as the service interface, business logic, database schemas etc. It captures sufficient information to ultimate provide the Business Capability in terms of a service.
Security Model: It captures the security related information of your service, such as who can access what. You can also embed security Models into different models. For example, you can capture security information in a Functional Model to define identities, resources and permissions etc. or you can capture it in Hosting Model to define how the hosts will be secured or how in the information storage will be secures.
Hosting Model: This model captures information how and where the service will be hosted and forces you to plan/design your hosting platform. You must have an idea of how the service will be deployed so that within you Service Factory you can automate the creation of deployment units etc. for this platform.
Here is an example of a Service Hosting Platform: here our service is deployed onto different hosts, such as Business Process and Integration components can be hosted on BizTalk, database components on SQL 2005, Collaboration and Workflow components can be host on SharePoint, Business Services and User Interfaces can be hosted IIS/ASP.NET/WCF platform.
It is important to understand the Service Hosting Platform so that you can capture sufficient information in your Service Model (Hosting Model) to enable creation of partially-completed Source Code Templates, in our case, these could be WCF contracts, SharePoint Web-Parts, BizTalk Orchestrations or database schemas.
Furthering our example, my hosting platform will be using MOM and SMS technologies to operate and manage the platform; therefore, I need to make sure my service provides performance counters and event logs to enable administrators and operators to monitor my services. I can capture this information in my Service Model so that during automation, Source Code Templates can be produced which will have right hooks in the code to provide performance counter information and even a EventLogHelper class to help developer reuse to send event information to logs.
I may go further than that and I can capture alerts and tasks (because I know what the hosting platform look like) in my Service Model and automate the creation of a MOM Management Pack for my service.
Integration Model: This model captures your integration requirements, how the service will integrate with other services, what is the integration mechanism etc.
Here is an example of a Service Integration Platform:
In my example, I know that I am going to be using (Enterprise) Service Bus architecture to integrate with other services within and across my organisational boundaries. To do that my Service needs to be registered and provisioned so that it will be visible to other services and enable communication with them. I can capture this information within my Service Model so that during deployment, I can automate the creation of, for example, users and groups. I can also capture metadata information in my service model so that it can be used during the registration of the system.
Or in true service bus architecture, I can automate the creation of Service Bus Client in my service which can be used as an API to built-in Service Bus features such as dynamic address resolution, dynamic mapping (transformation and translation) etc. and create the links to Service Bus enable reporting.
Reporting Model: This model captures service reporting and analysis requirements to enable applications to produce reports and metrics on the service.
Here is an example of Service Reporting Platform:
In my example, because I captured reporting requirements in my Service Model such as service interfaces should log incoming and outgoing messages, during automation my WCF service decorated with extenders that capture and forward the information to a store leaving developers concentrate on the function of service. Because the information is captured in a consistent way, it is easy to build a reporting platform to provide different views on the captured information; from audit to Key Performance Indicators.
As a summary, Models help you capture requirements of the service you want to develop. As well as capturing high level information about the service such as name and description of the service, it also capture low level details so that it can be used to develop source code. Let's have a look at the high level process one more time: First you do Capability Modelling using Capability Model Templates to produce Capability Models which in turn you use to produces Service Model Templates to capture service information in order to create Service Models and sub-models in Service Modelling exercise. Finally, you use Service Models to create partially-complete Source Code Templates for you to fill in the rest of the implementation details such business logic of your service during Service Development process.
Now let's have a look at what is available to you today:
Complimentary resources on Microsoft Services Business Architecture (aka Motion)
I hope you got the idea, see you soon...
