WSDL Tales From The Trenches, Part 1
by Johan Peeters
|
Pages: 1, 2
The Network is Not Transparent
The network is not transparent. There is an essential difference between invoking a local service and calling it remotely. Keep Peter Deutsh's eight fallacies of distributed computing pinned above your desk.
Failure semantics in a networked environment are different from the local case: when an invocation fails you do not always know whether the service executed or not.
WSDL 1.1 describes the following invocation styles: one-way, request-response, solicit-response, and notification. However, only one-way and request-response are supported by WSDL bindings. That's also pretty much the demarcation line between what is real and what is not. In other words, the usual case where the client expects a result back from the service cannot be realized asynchronously in a practical, production-grade, and standards-compliant way today. And that's a pity because that's the mechanism that is most resilient in the face of partial failure.
WSDL allows you to mix and match invocation styles and transport. Good judgment is needed here. A first requirement is that you understand exactly how the web service protocol stack you are proposing will behave, which is not always obvious. As an example, let us examine what happens when you invoke a web service asynchronously on top of a synchronous transport mechanism. Say you send a SOAP message one-way over HTTP: the client's business logic triggers the SOAP layer to invoke the remote service. This causes an HTTP request to be sent to the server. When the request is received by the server, it should immediately return an HTTP response without servicing the request. The server-side business logic should run after the response has been returned. The response should not contain a SOAP message. An HTTP 200 or 202 status code response does not mean that the service completed successfully. A failure code, on the other hand, should guarantee that the service invocation failed. The SOAP layer on the client side blocks until it receives the response or times out.
So one-way invocation does not mitigate network latency or network failure. At best it helps to avoid server-side business logic latency. I say "at best" because I would advise you to test this feature in your server's tool chain before you rely on it; it is not trivial for a vendor to implement correctly.
Using HTTP for transport the client may be sure that its request has been delivered. Note, however, that, if the client does not receive a response, it does not follow that the server has not received and correctly processed the request. For example, the network may fail as the response is being sent. In other words, implementing at least once invocation semantics is easy, not so for exactly once.
Web Services Aren't Distributed Objects
Objects are stateful. Try to avoid state as it ties up resources and compromises scalability. A loosely coupled architecture allows individual components to change without breaking the system. It's very likely that your web service will need to be extended in the future. How can you remain backward compatible? Old clients should not break with new versions.
While RPC trumps for ease of implementation, it does not sit well with loose coupling: it requires a fixed list of parameters to be passed with each invocation of the web service. This can be mitigated somewhat by allowing some of the parameters to be "nullable". I will not bore you with the details of the interoperability problems this may cause; a more fundamental limitation is that this technique allows parameters to be left out, not to be added. Document style invocations score better as parts of a document can be defined to be optional. They can also be designed for extensibility.
Define Narrow Interfaces
Examine carefully what you expose, both at the level of the data and the data encoding. Remember that you will need to continue to support the interface you export. The narrower the interface, the easier the implementation. The narrower the interface, the easier the maintenance. WSDL has been designed for flexibility. So it is easy to slip flexibility into web service specifications unwittingly and leave a lot of implementation options open. Resist this. Clients and servers are under an obligation to be able to handle all messages that are valid under the contract.
A typical beginner's error when implementing back-end systems is to open a new database connection to the database for each query. When I made this mistake, it turned out that opening database connections took more time than everything else combined. I know of two strategies for minimizing the performance hit: use a connection pool or use stored procedures.
In the web services biosphere, the cost of establishing a connection is also high. Again, the marginal cost of an invocation can be brought down by reusing an existing connection. On the other hand, also take into account that keeping a connection open ties up resources. However you look at it, the cost associated with web service invocations is much higher than a local function call and therefore they should be used sparingly.
At this point let us exercise the analogy with stored procedures. Instead of shipping out data and applying some logic to it in the client, only to find that more data is needed, stored procedures execute the logic within the database address space. The use of stored procedures in database applications is controversial for at least two reasons. First, the language to express stored procedures is not standardized and so their use leads to vendor lock-in. Second, the business logic should reside in a separate tier, not in the database.
Nonetheless, they address a real world problem and drawbacks need to be traded off against merits in each individual case. Similarly, in the web service area, you give the client control over logic at the expense of making many fine-grained calls. Coarse-grained services are more like stored procedures. They will not only have better performance, but also simplify the effort of implementation, deployment, and management of the system as a whole.
The rule of thumb is to design your web services to have narrow but coarse-grained interfaces. Narrowness is about exposing as little as possible, coarse-grainedness is about doing as much as possible with a single call.
Separate Business Logic From Policy
Do not address authentication and authorization in business logic. Transport level security may or may not satisfy your needs. The resources sections contains some references to articles that discuss this issue. If transport level security won't cut it, there are no standards yet. They are on their way, most notably from the OASIS Web Services Security Technical Committee. The mechanisms suggested do indeed promote a separation between business logic and policy: SOAP headers are pressed into service to provide security characteristics and the messages' payload is reserved for information pertinent to the business logic.
So much for the good news. The bad news is that the proposed standard only addresses web services with SOAP bindings. Another bit of bad news is that there is no standardized way to specify the Quality of Protection (QoP) of a service in a WSDL document. Microsoft, BEA, SAP, and IBM have put together a specification for Web Services Policy Attachments that addresses the issue. To my knowledge it has not been submitted to a standardization body.
Polluting the Design Space with Implementation Concerns
Ideally, when designing web services, you should not have to worry about implementation issues. The whole point of design is that you look at the system at a high level of abstraction, not allowing the implementation complexities to befuddle you. But you can make all the right design choices and the design will be useless if the tool chains that are going to be used do not support the constructs in your WSDL. I strongly recommend prototyping the design specification as a reality check. This edge is still raw.
Acknowledgments
Many thanks to Mark Portier and Caroline Greenman for their constructive comments.
ResourcesThe soap opera which is web services security will run for a long time. Here are some of the first episodes:
Martin Gudgin and Timothy Ewald delve deeper into the WSDL as IDL issue in The IDL That Isn't. Who Writes Your Web Service Contracts?, a white paper by the Karniak Corporation gives examples of how a precise description simplifies web service development. |
- Web Services and OO
2003-05-28 06:43:50 James Fuller
