Jeff,
I think you forgot to mention the concurrency issues related with
stateful WS. So, at least under this point of view, stateless WS are
much more easier to build.
Michele
On 22 Oct 2007, at 17:08, Walker, Jeff wrote:
Ok,
So we have moved-off topic here.
My original email was to Florian Georg, who asked about stateful
services and very large data set transfer, via a stateful web service,
if I remember correctly.
Then Michele asked my opinion on stateful vs stateless.
My point here is that stateless services are far easier than stateful,
but almost useless because most situations require services in
front of
stateful applications. That's an assertion that I'm sure many will
refute! That's fine, that's what this board is for. (I'm here to learn
as well).
Yes, stateful services are relatively easy to build from an
engineering
point of view. But retrofitting them into an existing architecture is
very difficult. Also difficult is engineering them into an SOA.
Most SOA
architectural layouts I have seen skirt the issue and assume stateless
services.
I haven't used WS-SecureConversation.
REST to me is a completely different approach to architecture. But
again, I've only read about it. I would think it also is not
appropriate
for large data transfer. But I think it is stateless by default,
right?
The unswimmable sea of WS-* specifications helps only to muddy the
waters. If there are no implementations, the specs mean little. I
thought Axis 2 implements only these:
WS-ReliableMessaging - Supported by Apache Sandesha2
WS-Coordination and WS-AtomicTransaction - Supported by Apache
Kandula2
WS-Security - Supported by Apache Rampart
WS-Addressing -Module included as part of Axis2 core
-jeff
-----Original Message-----
From: robert lazarski [mailto:[EMAIL PROTECTED]
Sent: Monday, October 22, 2007 10:59 AM
To: [email protected]
Subject: Re: Best way to realize stateful services architecture
withmassivedata?
On 10/22/07, Walker, Jeff <[EMAIL PROTECTED]> wrote:
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.
Its not that difficult - its actually common and standardized via
WS-SecureConversation. I personally have also used my own UUID scheme
where WS-SecureConversation hasn't been supported on all sides. Coding
up your own scheme takes about 2-3 days depending on the programmer -
I've even seen beginner .net programmers implement UUID token passing
easily.
Calling DB transactions often also requires the right sequence, and
people get by just fine. EJB stateful web services may not be as easy
as a pojo, but people do that often enough too.
In short, anything is easier when its stateless. The whole idea though
behind WS-* is enterprise stuff like asynchronous calls, addressing,
conversations, transactions and reliability. A good case could be made
that its not needed a lot - that's where REST comes in. But if you do
need common usage patterns beyond simple HTTP get and post, there are
seemingly endless WS-* standards that thought of just about everything
- and axis2 implements most of them.
Robert
---------------------------------------------------------------------
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]
