Mark, What I notice missing from most books related to SOA is 'Testing'. In a larger Corporation that utilizes SOA there is quite a large cost in testing services. Can you speak about best practices with regard to planning a large scale SOA implementation that accounts and plans for a formal testing process?
Some typical issues may be:
Costly to replicate a production like SOA environment due to the sheer number of systems and data dependancies.
Versioning of services is not standard. While we can tell when a WSDL changes it's difficult to know when your service has changed.
Services require something closer to exhaustive testing due to the API like nature and enhanced risks due to the possibility of mutiple business units consuming the services.
Performance needs are difficult to predict in shared environments
Unfortunately, my book doesn't include any advice on testing a SOA either! Although the build process (Maven) for some of the code samples include JUnit based integration testing. Basically, having a test client fire a variety of messages at a service and checking that the returned messages conform to expectation. I guess you would call that "service level" testing. It is OK for testing individual services. But, there is a whole additional layer of integration testing required to test a SOA application.
Sounds like another book ..... ;-)
I did find this article by David Linthicum that might be helpful.
As I think about this, I am realizing that nobody "tests" the Web - right? I mean, people are building useful mashups, and doing eCommerce over the Web. It is one giant SOA. But nobody tests the whole thing. The applications are loosely-coupled, so they can be designed to be fairly fault tolerant. Maybe with SOA applications, we just need to accept that they cannot be tested to the same rigorous level as tightly coupled OO applications that run in a single address space. Each individual service can be rigorously tested. And a specific business process can be tested. But, I don't see how you can realistically test an entire SOA.
Those are just some thoughts. I'd be interested in what other have to say about it. [ May 30, 2007: Message edited by: Mark D. Hansen ]
.. But, I don't see how you can realistically test an entire SOA.
Tell that to the people who are responsible for doing just that!
I think it's a serious problem that in most discussions and books the long term care and feeding of a SOA architecture is not addressed. Testing is a huge issue and its even more important with SOA due to the loosely coupled nature.
I would be very interested in a new book from you on the real world care and feeding of SOA with emphasis on the SDLC and how a SOA architecture must account for all phases of testing. From someone who works with this daily I can tell you that there is much need to educate the architects and developers who are planning SOA implementations.
I think most people just look at the individual service when they think of testing SOA. This may be ok if you are putting your service on the internet as a one-off. For a large company that moves to SOA the reality is that the applications that consume the services need to be tested as well so it is very important to plan for holistic solutions. SOA is not just the services it's the services and the consuming applications.
Talking mashups is one thing. Talking mission critical banking applications is a completely different discussion. If SOA is so difficult to test at a large scale is SOA really good idea for things like Banking where a formal SDLC is followed? Because testing is never really discussed when talking about SOA are companies making choices to move to SOA without knowing all the risks?
Do you (or really anyone else) think that SOA creates addtional complexity for the testing phase regardless of application?
I'm not trying to be critical of you, but your answer is an example of the problems I am seeing in companies today. The SOA experts are not giving the testing phase enough thought before initiating the project to build the ESB and it puts an enormous strain on the initiative and the resources responsible for planning and performing the testing of services and the applications that consume those services.
An exmple of building testing into your approach might be to build your services with two modes. A production mode and a test mode. This can possibly provide some ability to test the service in production.
I would definately like to see more discussion on 'real world' SOA. If you are really interested in a second book I'd be willing to connect you with some real world implementations.