I’ve got SOA on the brain lately. I’m in the process of writing a book on building service-oriented solutions using BizTalk Server 2006 R3 (due out right around the product release), and, trying to organize a service review board at my company. Good times.
So what’s a “service review board”? It’s a chance to look at services that have been deployed within our development environment and chat with the developer/architect about various design and deployment considerations. In reality, it’s a way to move from “just a bunch of web services” (JBOWS) to an architecture that truly supports our stated service-oriented principles. Now, clearly there are services that are meant to solve a specific purpose, and may not be appropriate for “enterprise” scale. But, I would argue that the goal of any service is to be designed with principles of reuse in mind, even if service reuse never happens.
Who should attend such a review board besides the service developer? I’d suggest the following representatives:
- Infrastructure. Make sure that all deployment considerations have been taken into account such as a host server (dev/test/prod), required platforms and the like.
- Enterprise architecture. Look at the service and compare that to other enterprise projects to see if there is overlap with existing services, or, the possibility to reuse the new service in an upcoming project.
- Data architecture. Confirm best practices for the data being sent as part of service requests or responses. Also, consider the data security and data privacy.
- Solution architecture. Review software patterns used and ensure that the service has the appropriate security considerations and repository registration.
With that in mind, what questions do we want to ask to verify whether this service is enterprise-ready?
| Infrastructure | |
| Question | Answer |
| What is the technology platform that this service is built upon (e.g. Java, .NET)? | |
| Do you have host servers identified for all deployment environments? | |
| Are there any SLAs defined for this service as a result of non-functional requirements? | |
| Have the appropriate service repository metadata elements been identified for this service? | |
| Has this service been sufficiently load tested? | |
| Security | |
| Question | Answer |
| Has a security policy been identified? | |
| Does this service use either transport-level security or message-based security, and if so, does it match corporate standards? | |
| Have the appropriate directory accounts/groups been created and assigned? | |
| Data | |
| Question | Answer |
| What type of data is received by the service: document, event or function parameter? | |
| Are the input/output types complex or simple types? | |
| Were standard, cross-platform data types used? | |
| Does this service use an enterprise shared entity as its input or output? | |
| If the answer above is “no”, should the input/output parameter be considered for a new shared entity definition? | |
| Is the input message self-contained? | |
| Software Architecture | |
| Question | Answer |
| Is this a data service, event service, or functional service? | |
| Does it support both synchronous and asynchronous invocation? | |
| Is the service an encapsulated, stand-alone entity? | |
| Are service dependencies dynamically loaded or configurable? | |
| Has the service been tested for cross-platform invocation? | |
| Does this service use an transactions? | |
| Can the service accept a flowed transaction? | |
| Has a lifecycle versioning strategy been defined? | |
| Is the interface SOAP, REST or POX based? | |
| Do common functions like exception handling and logging use enterprise aspects? | |
| Is the service contract coarse grained or fine grained? | |
| Is the WSDL too complicated (e.g. numerous imports) to be consumed by BizTalk Server? | |
| How are exceptions handled and thrown? | |
| Does the service maintain any state? | |
| Do the service namespace and operations have valid and understandable identifiers? | |
The goal of this is not to torture service developers, but rather to consider enterprise implications of new services being developed. Did I miss anything, or include something that doesn’t matter to you? I’d love your thoughts on this.
Technorati Tags: SOA
Richard Seroter's Architecture Musings 
On the infrastructure side, I might craft that first question into some kind of request for the developer to provide a kind of “resource map” showing what systems/services are used/impacted by the service(s) in question.
Another focus would be coupling. How tight are the service’s dependencies, and/or how tight of a dependency will be created by services that will eventually depend on the service in question? Close attention needs to be paid to ensure the service developer is developing with a “contract first” development methodology. For example, auto-generated WSDL and database schema files (such as those used almost routinely by BizTalk developers) should NEVER be exposed as a public contract for subscription/consumption. This kind of design decision should raise red flags in any design review board because it creates “brittle” dependencies and eliminates the benefits of loose coupling in service development.
At first it appears counter-intuitive to BizTalk developers – after all, BizTalk auto-generates so many schemas and interfaces for us, that it leads us to the temptation to do precisely what I’m recommending against. I am of the camp that believes that all good BizTalk development begins by focusing first on the schemas that will make up the contracts for all that we expose for consumption.
I would also make sure that infrastructure be present, whether by hook, by crook, or by gunpoint. BizTalk development is enterprise development, which is less coding and more resource configuration, and the resources being configured typically belong to the infrastructure team. Drawing from my own experiences it seems most infrastructure groups don’t seem to understand this dynamic.
Anyways, just a couple of things to keep in mind 🙂
Nice thoughtful response, Lucas. While I considered ALL service development (BizTalk or otherwise) when I wrote this, your points on BizTalk service generation are good ones.