One of the areas that concerns me with SOA deployments is their generally poor operational characteristics.
I'll give two examples, using the same hypothetical topology. Service S is consumed by Clients A, B, C, .. J.
Example 1: Client J is either greedy or malfunctioning, so it floods Service S with requests, effectively denying the service to other clients.
Example 2: Service S stops responding due to an internal error. Now Clients A through J are all down. There's no damage containment when something breaks; indeed just the opposite! Damage is amplified as the failure cascades from one layer to the next.
Example 3: Service S must be upgraded. The protocol at the endpoint has to change. Because they were written using the common SOA toolkits, such as Axis, Clients A through J must all be upgraded simultaneously with Service S, thus coupling the development and deployment schedules of 11 different groups.
(OK, I threw in a bonus example.)
To what extent does your book address operational and governance concerns such as these?
Cheers, -Mike Nygard
Michael T. Nygard<br /><a href="http://www.michaelnygard.com/" target="_blank" rel="nofollow">http://www.michaelnygard.com/</a><br /> <br />Release It! Design and Deploy Production Ready Software<br /><a href="http://pragmaticprogrammer.com/titles/mnee/index.html" target="_blank" rel="nofollow">http://pragmaticprogrammer.com/titles/mnee/index.html</a>
Joined: Oct 08, 2004
It looks like your examples are not something that Web Services should look to solve, but should be handled by the interfacing client app or in the deployment plan:
Example 1: A denial of service attack is not unique to web services and should be handled like any other denial of service attack (blocking the requestor or other approach to shut down a denial of service attack, be it HTTP or some other protocol).
Example 2: A Web Service crash/malfunction should be handled by the client application the same as a crash/malfunction of any other Servlet, server, or other outside application with which a client application must interface. E.g., if your application invokes a Google search engine and Google's servers crash, your application must deal with it as it deems best (displaying an error or informational message, using an alternate service, etc.
Example 3: This is a migration/deployment issue, rather than a technology issue. A responsible provider of web services would provide a migration path for it's customers/consumers. If the protocol or API changes, both versions of the service service could be provided for a time (a new URL for the new version) with the phase out of the old service advertised well in advance, including a termination date. Customers should be notified periodically, including an urgent notice the day before the termination of the old service. Of course, in some cases, it may be beneficial to continue supporting the old service for a more extended period of time or indefinitely.
Joined: Jan 03, 2007
I wouldn't expect an individual web service to address these concerns, but I would expect a Service Oriented Architecture to address them.
A complete architecture is more than just the functional aspects of the software and systems. It must also account for operational and service-quality issues. This absolutely includes questions about change over time and maintaining service levels in the face of badly behaved clients.
As an analogy, I would not expect a single Apache server (web server) to address issues like load-balancing, failover, or global traffic management. But I would absolutely expect a complete web site architecture to address all of those.
Mark D. Hansen
Joined: May 29, 2007
My book is primarily a programmer's guide to Java Web Services (JWS) - aimed at teaching programmers how to write SOA endpoints and clients using JWS. So, the book does not cover fault-tolerance, governance, or maintenance issues. Perhaps, that could be "SOA Using Java Web Services - Volume #2"
I agree with you that these are issues that need to be build into a SOA, and not necessarily at the individual Web service level.
Example 1 strikes me as a deployment issue. DOS attacks, and other such malicious client problems need to be handled via monitoring of the SOA deployment and management tools that alert an administrator when an attack or malfunction is going on. If it is non-macilions, and just a spike in the load, GlassFish and other Java EE 5 can (or will soon) provide clustering to handle such things.
Example 2 requires the SOA to have some basic fail over mechanism built into the infrastructure. Again, monitoring and administration is required.
Example 3 leaves me a little confused. What do you mean by "upgraded"? If you mean that the WSDL has to change because the interface definition changes, then, yes, the clients also need to change. But, that has nothing to do with the SOA toolkit used to develop the client. If the service makes a change in the XML structure of its messages, then that will require retooling the client side regardless of the toolkit in use.
While, I agree that this "change management" issues is a problem, I think it is no worse with SOA than with standard OO development. In Java, if you change a method signature, all the method invocations throughout your code have to be changed. These days, we have nice IDEs that make it relatively painless to manage such changes. These can be used with JWS sometimes as well. If you generate your service endpoint interfaces (SEI) - that Java representation of the WSDL - from WSDL, then any change in the WSDL can be pulled into your IDE by regenerating the SEI and all client invocations can be upgraded inside the SEI.