Why you should not deliver a client for web-services
Today I'd like to explain why a wise service consumer should not ask a service provider for a service client. Before I start with all the technical details, let me describe a sample scenario:Team A and team B are working on two different applications. Then one day the product owner wants to integrate both applications. Therefore team B has to access the data in the application of team A. The architecture board of the company decides that - if possible - all applications should be integrated using web-services via SOAP over HTTP. So team A implements a web-service and delivers a WSDL file to team B. But after a short time team B bemoans that they cannot access the service and asks team A to deliver a client for their web-service. Does this sound familiar to you?
Usually team B acts that way because of lack of time or simply because they don't have the knowledge how to access a web-service and sometimes it is just politics. If team B tries to argue that team A actually has everything they need to access the service, they often lose the debate. In case of escalation, project managers, team leaders or product owners who don't have any clue about the technology usually decide that team A in their role as service provider have to deliver a working service that includes a service client.
Because of their bad political standing team A usually decides to deliver an easy-to-use client. They generate stub classes from the WSLD file, package them with some kind of web-service framework like CXF and configure the client with the endpoints for different stages. Team B can now easily access the service and in short time that behavior seems to have many benefits for team B:
- no time investment for implementing the client
- no need of web-service know-how
- easy or no configuration of the client
- client code is in responsibility of service provider
The problem is that every service provider is using their own technology and their own service framework. Even if you agree on one framework for web-services, sooner or later the framework will be upgraded to an newer version or replaced by another framework. You can not avoid this, either way any innovation will stop. This means that every web-service client introduces a new set of libraries as dependency and if you decide to go this way you someday you will end in the dependency hell. The following diagram visualizes the issue:
Some people may argue that you can avoid that problem by using OSGi. In my opinion that is just partly right. First, you can not migrate every existing application to OSGi. Second, in some scenarios like deployment with Java-WebStart you need to minimize the size of your application to keep the network traffic down and startup time high. If every service brings its own dependencies, your deployment package will soon be very big. That is why I think that by using OSGi you just hide the problem without solving it. But don't get me wrong: I think that OSGi is a very cool technology that can help you to get your architecture and dependencies straight. In my eyes it's just not the answer to every problem.
I think that dependency management is one of the key aspects to avoid degeneration of your application over time. This dependency management is especially important if your application is part of a distributed system or SOA.
If you are working in a team that uses web-services as service consumer, then don't ask the service provider to deliver a service client. Instead decide for a web-service framework and create client stubs from WSDL files for all of your services. Use your energy and political influence to agree on following points with the service provider:
- versioning strategy for the service
- change management process
- service level agreement
How does your organization handle this issue?
0 Kommentare:
Kommentar veröffentlichen