Yes, I agree. Coarse grained operations on the composite interface. But a stateful service will be so difficult to build, coarse grained or not, if you have little or no control over the clients. If you do have control over them then a stateful service could possibly be the better choice. (Just be careful with error situations).
I did forget network delay. Compare that to marshaling/unmarshaling of data to XML for every fine-grained stateful call. Still, the composite calls will take a long time and since it is difficult to estimate, the client is better off making the calls asynchronously. That is the point I really wanted to make. You mentioned WS over JMS. Again, added delay, since another protocol layer is employed. I've never built a web service running over JMS, but it is certainly possible. Other posters have previously mentioned JMS and web services. They might be able to help you out there. -jeff -----Original Message----- From: Michele Mazzucco [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 10:49 AM To: axis-user@ws.apache.org Subject: RE: Best way to realize stateful services architecturewithmassivedata? Ok, now I get your point. But solution # 3 will work *only* if the "front-end" service exposes coarse grained operations, right? If so, can't you expose coarse-grained operations in your stateful WS as well? In point (c) of your conclusions you state that the third approach would be a bit faster than the first one. However you forget to take the network delay into account. Michele On Mon, 2007-10-22 at 10:38 -0400, Walker, Jeff wrote: > 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] > --------------------------------------------------------------------- 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]
