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]
