Well, 1st Approach: Stateful Service Most applications are finite state machines. People tend to want to put a web service on the front of their application, to say they are "SOA compliant" or simply because they think a web service will give their application some advantage. But because the application itself is stateful, most likely a first attempt at the web service will produce a stateful service.
You can definitely create stateful web services. It's just that they are very difficult to use. How do you force the client to make the operation calls in the expected calling sequence? The client will likely need to keep track of the order of the operations it has called. This is complicated book-keeping and often the client unable or unwilling to do this. Errors become a big issue. What do you do when the 5th call of 7 expected calls fails? Should you abandon altogether? How do you retry? The complexity gets ugly, quickly. 2nd Approach: Stateless Service Here, the designer begins to see that a stateless service is far easier to handle and create. Any operation on the web service interface can be called at any time. No sequence of calls is necessary. Each call is fully independent of each other. Errors are localized to that called operation, and soap faults sent back to the client are localized to that operation. It's all very clean. It sounds great, but if my above premise is true (that most applications are stateful) then how can you mesh the multiple states of the application with a set of operations in a stateless service? What if a request comes in and is passed to the application and the application cannot service that request because it is no longer in a state that can satisfactorily create the right response? 3rd Approach: Intermediate Composite Service My suggestion (and it is just one of many possible design solutions, I'm sure) is to create an intermediate web service that communicates to the client. This intermediate, composite service offers a stateless interface to clients. Each stateless operation on it results in a sequence of stateful calls to the actual web service on behalf of the client. The composite has some intelligence to decide what to do when one of the calls in the middle of the sequence fails. (Usually it abandons the whole calling sequence and returns a soap fault to the client, but not always. It could conceivably abandon the current sequence and start a new one. But that requires memory of the calls and data passed in previously, before the error occurred). a). The client is saved from knowing anything about the statefulness of your application. b). Your stateful application usually doesn't need altering. A big plus if the code is old and hard to maintain. c). The composite service takes approx. as long as the sum of stateful calls would take. (Slightly less because the marshaling of data into XML and back is less. It is only done on the one initial call from the client). d). Because the composite service is still a fairly long running service (you don't know exactly how long it will take on each of its operations), it is best called asynchronously, but that is another story. e). There are drawbacks. It means another service has to be written, tested, maintained and deployed to production. The best approach is obviously to simplify and just create a fully stateless service, if that will work with your application. But don't be surprised if it doesn't fit well. -jeff -----Original Message----- From: Michele Mazzucco [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 9:41 AM To: axis-user@ws.apache.org Subject: RE: Best way to realize stateful services architecture withmassivedata? On Mon, 2007-10-22 at 09:09 -0400, Walker, Jeff wrote: > 1. Web services shouldn't be stateful. (Far harder to keep that > promise than to recite it). My own current service is stateful, and it > breaks the SOA rules we have in place here, causing me no end to > issues. Removing the statefulness once it creeps into your project is > like getting blood from a stone. Best remedy is to create a composite > service that is stateless, and that talks to the client. It also > formulates a series of web service calls to your stateful service that > does the real work. The composite service then returns the result to > the client. BPEL could help here. Jeff, can you tell me about a non-trivial stateless web service? What is the difference between the first (i.e. the stateful WS talks to the client) and the second approach (i.e. the stateful WS is hidden by a stateless one)? > > 2. Web services are not suitable for large data transfer, at all. I > have found past about 20Mb of data per request/response and the > service starts to timeout. That is even when RAM is added and > processors are upgraded. On one of my previous web services gigs I was > asked to build a web service to transfer files. They grew from 20Mb to > 75Mb with few troubles except for the occasional timeout, then to 1 > Gig in size. The remedy was to call the service asynchronously. There > are various Microsoft and IBM websites that will explain that mode of > calling. (If you need them, I can send you the article urls, I just > don't have them handy right now). > Remedy is to rethink your architecture. Web services will perform very > badly for you on large data sets. (So bad as to be totally unusable). > So simply don't use the web services for the data transfer. Try FTP > instead, and use the web service to generate the files and pass back > the address of where to find the files. It sounds like the granularity > of your service is too fine-grained. You need to think in higher terms > for the web service operations. What about WS with JMS? Michele --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
