This is a lengthy and contentious subject -
* Lengthy meaning my book is on the entire subject. We have different types of best practices or
patterns, e.g. architecture/deployment/quality of services patterns (ch 4), interoperability patterns (ch 5), integration patterns (ch6), security patterns (ch 7). I've attempted to summarize a few patterns for you from my book ch 4.
The quality of service patterns discusses how to improve the service quality of Web Services deployment. This includes scalability (
SOAP Cache, JMS Bridge, Multiple
Servlet Engines), reliability (State Management, SOAP logger), manageability (Publishing Web Services, Service Versioning, and Service Registry Content Management), availability (High Availability of Service Registry), and security (Service Registry Deployment). Some of these patterns are programmatic design patterns, and some of them are architecture patterns or best practices.
SOAP Cache � This pattern provides a structure to cache client-side or server-side service look-up that can reduce dynamic service look-up overhead. This can be used in conjunction with the Service Locator pattern.
JMS Bridge � This pattern illustrates how SOAP over JMS can be used to provide reliable messaging between two different JMS-based middleware. It can be used to bridge between two different middleware products or two system infrastructures using SOAP over JMS mechanism. The JMS Bridge is usually used in conjunction with Service Activator pattern. There are also object database products or middleware products that provide the same function.
Multiple Servlet Engines � This pattern is a best practice to apply horizontal scaling (multiple SOAP server hosts connected to a HTTP load balancer) or vertical scaling (multiple SOAP server instances in the same host) technique to improve scalability and performance throughput.
SOAP Server Farm � This pattern is a best practice to scale the SOAP processing capability (namely, SOAP server) horizontally or vertically using a HTTP load balancer. The SOAP server is primarily a servlet running on top of a web container, and handles SOAP message routing and processing. It is crucial to have more than one SOAP servers to ensure the SOAP-based Web Services are scalable and available by having a HTTP load balancer connected to a number of SOAP servers horizontally or vertically.
State Management � This pattern discusses the best practices of stateful and stateless Web Services. The design of stateful and stateless Web Services is dependent on the business requirements and technical constraints. Stateless Web Services that use RPC invoke remote business service (for example, from a mainframe), and thus they do not typically store state information. Stateful Web Services can use either RPC-style or document-style Web Services, and manage the state information for roll-back or failover programmatically. This will incur additional system resources overhead and more complex exception handling design.
SOAP Logger � This pattern makes use of the logging API infrastructure in J2SE 1.4 to provide service invocation and troubleshooting information for Web Services. It is important to track the service requester�s credentials, the remote service invoked, and the timestamp to a single logging infrastructure (or a Web Services management server) for managing Web Services and service level. The logged messages should have some structure or tiers, instead of disorganized or piecemeal logging information. Otherwise, application support personnel will not be able to diagnose the root cause with sufficient Web Services calls details.
Publishing Web Services � This pattern re-capitulates a common programmatic structure to use JAXR to publish, un-publish or discover Web Services from the service registry. It addresses the complexity of using different APIs for each UDDI or ebXML service registry product with standardized
Java APIs.
Service Versioning � This pattern explains how different versions of the same business services can be defined and deployed in the service registry. This is usually implemented by associating the service version with the �Service Bindings� and the service end-points (or service bindings access URI). In parallel, the SOAP header also needs to specify the service version.
Service Registry Content Management � This pattern applies the content management process to managing service registry contents. If an enterprise has a single master service registry, then the contents update can be replicated to the replica service registry using the service registry infrastructure (for example, LDAP replication, proprietary registry replication features). However, if an enterprise has multiple service registries, the administrator should define a set of registry content management process, including the use of a staging service registry to host all service information changes, and the approval process to update and replicate the changes to the replica service registries.
High Availability of Service Registry � This pattern simply explains how to make the service registry highly available using hardware clustering or container clustering features. If the service registry is implemented using directory server, the LDAP replication topology may provide high availability or failover feature, and it may not require hardware clustering.
Service Registry Deployment � This pattern depicts the variation of deployment scenarios where a service registry should be deployed. For a private service registry or an intranet environment, the service registry can be deployed behind the de-militarized zone (DMZ). For a public service registry environment, the service registry should be deployed before the de-militarized zone for security reasons.
* Contentious, because not every one agrees there needs to be web services patterns. For some
J2EE architects, web services patterns may be something they can re-use existing J2EE patterns if they are using J2EE to build web services.
