Date: December 9, 2008 9:35:13 AM PST
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