RE: [sca-assembly] Conversational services

["Martin Chapman" <martin.chapman@oracle.com>]

Jim, 

My main concern lies with the simplistic concepts we have, and in the
annotations we have done for wsdl. 
We only have the "endsConversation" annotation, and I cannot tell by looking
at the wsdl what operation starts a conversation, or even if an operation is
required to be in a conversation. In addition, I cannot call an operation
with an "endsConversation" and allow the option of continuing the
conversation, so we force an end/terminate/cancel operation to be explicitly
defined. Only having the "endsConverstaion" annotation, and having
assumptions about the other operations in the same interface is why I say
its half-baked. I'm sure it suits some simple use cases, but it doesn't
solve the general case, and doesn't address the multi-party case.

There are two ways to do this properly IMHO:

	1. extend the declarative style with begin, continue etc. One can
even envisage specifying the valid sequences of operation calls. Work was
done in the 80's on extended open predicate path expressions which is one
example of this approach:
http://www.ansa.co.uk/ANSATech/93/Primary/10100002.pdf. 

	2. The other way is the programmatic approach (not sure this is the
right word). This is where there are no annotations on operations per say,
but rather invocations are scoped on the client side with begin/end markers,
much like one would do when writing transactions - though of course the
server has to be suitable enabled. 

Approach 1 doesn't solve the multi-party case though and one could argue
that you are getting into choreography territory.
Approach 2 requires activity/coordination services and is probably a more
general solution to the problem.

So this is what leads me to the conclusion that either we do the job fully
and properly,  or we remove the feature for this round of SCA.

Martin.




> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 09 December 2008 17:35
> To: OASIS Assembly
> Subject: [sca-assembly] 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php