Justifying the extra investment for developing a single-purpose service – a service expected to solve only one large business problem - instead of putting the single-purpose logic inside a non-service-oriented application can be challenging. Reuse, the most popular motivation for creating services, will not apply. So where's the business case? Acceptable justifications can include: enabling support for multiple providers, isolating logic from change, centralizing IT-support for a given business process, service composition optimization, and separation of concerns. Although performance is commonly referenced as a reason to not create services, that line of thought is not always valid.

With the help of patterns referenced from the recently published SOA Design Patterns book [REF-1] and the soapatterns.org site [REF-17], this article will delve into these issues as we explore the case for the single-purpose service.

Les hele artikkelen her....

Relaxed Service Implementation som kandidatpattern på soapatterns.org:

Problem

Standardized WSDL definitions make life easier for client developers in that it allows them to generate the code necessary to actually call the services. If the auto-generation doesn’t work due to legacy software or differences between technical platforms a service might receive input data of poor quality.

Solution

Publish a standardized WSDL but allow any kind of message to get through the message processing layer. Let the underlying implementation inspect the message and act according to the contents of the message.

Les mer her...