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?
|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?|
|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?|
|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?|
|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