Conversational services

[Jim Marino <jim.marino@gmail.com>]

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