Java Reference
In-Depth Information
this particular network with these external constraints that must be accounted for. Baking such
items into your service can severely curtail or obliterate its possibilities for reuse, especially
in federated environments. But the need to deal with them remains; when possible, move such
requirements into decorators.
This requirement may guide your choice of platform or implementation. The fact that there
are so many non-functional requirements that so often come into play in software components
(and the fact that so many of them are recognized by WS-* specifications) is a leading reason
why I have chosen to focus on SOAP-based services in this topic (and in building a real-world
SOA). To have such common requirements dealt with in a standard way within these specs
offers a boost to interoperability and maintainability, and allows developers to focus on their
business problem.
Other considerations
What else might be true of the operation if it is to qualify as a service? It seems that a service
is worth all the trouble to define and create only if it will be reused. A chief aim of SOA is
that its components are self-contained and do not represent overlapping functionality. Its com-
ponents should provide a degree of reusability. That is, they must not be limited to a narrowly
defined business context that has little or no relevance elsewhere in the enterprise. It is pos-
sible that you will write a service that does not get reused. It is possible that your business
will change directions, or that a service is too poorly defined, either too granular or too broad
in scope, to ever fit into another use case. Sniffing out such matters is where architects are
valuable.
Some architects will add the requirement that a service must be stateless. I agree that in gen-
eral it is a good idea to ensure that your service operations are stateless, but I would not re-
quire it as a defining feature of services. If they must maintain state, they can do so externally
through a database or other temporary serialization mechanism. Conversational state is often
best avoided if possible, but when it must be maintained within the service composition, it can
be handled through a specification such as WS-SecureConversation and WS-Conversation.
This is a spec that has been around for a few years now, and is implemented in containers like
WebLogic 10gR3.
