Re: [sca-assembly] Fwd: Conversational services

[David Booz <booz@us.ibm.com>]

Hi Jim,
Thanks for the offer, I'll take you up on it. Interoperability (SCA binding aside) is quite key to the overall SCA story because the world is full of non-SCA services, so I don't think we can just cast interop aside. I think vendor extensions are perfectly acceptable. Portability is less important than interop at this point in time (I didn't say unimportant). Perhaps you disagree. I would much rather see vendors experiment with extensions that can be standardized at a later point in time. Conversations seems like a very good candidate for such a thing given all the churn we've had.

Can you explain how you implemented conversations over web services, and the tradeoffs for the design decisions you made? Which pieces of WS-Addressing did you use, etc....

Do you have a need to expose conversations on the "edges" of the Domain...i.e. services and references that reach outside the domain?

Do you support conversations in bidirectional cases? If so, how did you deal with the remote garbage collection problems?

Are your service proxies stateful? Do you have threading restrictions on how/when they can be de-serialized? Can the same serialized proxy be de-serialized concurrently onto two different threads? Can a composite scoped runtime instance be part of more than one conversation at a time?

With regard to n-party conversations, what is the model you're using? How are the parties notified of conversation lifecycle changes? How do they get handles to existing conversations? How do you know when a conversation is no longer valid? Does any one conversation instance have the ability to affect any other conversation?

There may be simple answers to the above that we've overlooked.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Jim Marino ---12/09/2008 12:55:47 PM---Hi, I also should have mentioned that I am willing to share our

From:	Jim Marino <jim.marino@gmail.com>
To:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	12/09/2008 12:55 PM
Subject:	[sca-assembly] Fwd: Conversational services

---

Hi,

I also should have mentioned that I am willing to share our experiences implementing and using conversational services in more detail if people are interested. This is an extremely important feature to us and I hope SCA continues to provide conversational capabilities.

Jim

Begin forwarded message:

From: Jim Marino <jim.marino@gmail.com>
Date: December 9, 2008 9:35:13 AM PST
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Subject: Conversational services

Hi,

Martin mentioned Oracle's experience with conversational services led them to the conclusion that they were "half-baked" and too complex on the Assembly call today. Unfortunately, time ran out before I could ask him to elaborate. From an end-user perspective, conversations are a critical part of our applications. Without them, we will likely be forced to adopt a proprietary approach (or potentially look to another technology), which for obvious reasons we don't want to do. Based on my discussions in the past with other end-users, I don't think I am alone in my views.

As some background, we are currently building several European inter-bank payment and ATM processing systems which are in various stages of production use. The size of these applications are quite large (over 150 composites each) and the requirements challenging, but due to SCA's ease-of-use, we were able to implement them successfully with developers who had no prior SCA exposure and relatively limited experience with service-based architectures. In building these applications, conversational services allowed us to greatly simplify many previously complex tasks, such as large document processing and managing JPA persistence contexts. From a cost and ongoing maintenance standpoint, conversational service support has allowed us to remove an enormous amount of "boilerplate" code that existed in our legacy systems.

We were able to support conversational services in our SCA infrastructure in a relatively straightforward way. So far, based on our application throughput requirements (processing 100 million transactions in a three hour period), we have not encountered any performance issues related to conversations.

I'm sure there are areas where they can be improved. For example, multi-party conversations is one, which we have implemented as a proprietary extension in our infrastructure. There is also the question of inter-operability, although I don't view that as necessarily important at this stage given SCA runtimes from different vendors are not likely to interoperate (e.g. different vendor runtimes participating in the same domain) any time in the near future. However, before we remove such an important feature, I would like to understand the specifics of why conversations are too complex both to use and implement. Granted, there are areas in need of further specification and refinement, but I think that can be said of many SCA features.

Not to single people out, but Martin and Mike, you both made these claims on the call. Could you please elaborate with technical details?

Thanks,
Jim