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
