Re: [sca-assembly] Conversational services

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

Hi Martin,

Comments inline as usual...

Jim

On Dec 11, 2008, at 6:07 AM, Martin Chapman wrote:

> 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.
>
It looks as if we agree that "conversations," "stateful interactions,"  
or whatever they are called are important for SCA (I will use  
"conversations" to describe them). That's good. Also, I think we can  
accommodate your concerns with some very minor additions to the  
current conversational model. This is also good given the time  
constraints we are under and the risks associated with developing a  
completely new model for these types of interactions. It also sounds  
as if you agree with me that conversational lifecycle should be  
reflected in the service contract.  Others may have a different  
opinion. For example, Simon has proposed in the context of the Java  
work group that conversational lifecycle may be an implementation  
detail. I think conversational lifecycle is part of the service  
contract for the reasons you state above. Taking that position as a  
starting point, I wanted to go into more detail about how I think we  
can accommodate your concerns.

At this point it would be good to outline the semantics of the  
conversational lifecycle as it is currently laid out in the specs:

1. All operations begin a conversation if none exits.
2. If a conversation already exists, all operations continue it.
3. If an operation is marked with endsConversation, the conversation  
will be ended after the operation completes.
4. If an operation is called after an endsConversation operation  
completes, a new conversation begins
5. It is not possible for a conversational service to have a non- 
conversational operation.

 From this, I believe it is always possible to determine the precise  
conversational semantics of an operation on a conversational service.  
As you mentioned above, in some scenarios it is useful to demarcate an  
operation that starts a conversation from one that continues it. A  
while back, we did have a for beginsConversation annotation. Perhaps  
we could reinstate it with the following broadly sketched semantics:

1. Conversational services have three states: begin, continue, and end
2. If a service contract has an operation marked with  
beginsConversation, invocations of that method begin the conversation  
lifecycle. Clients must invoke an operation marked with  
beginsConversation prior to other operations not marked with  
beginsConversation.
3. Multiple operations on a service contract may be marked with  
beginsConversation.
4. Methods not marked with beginsConversation or endsConversation  
continue the conversation lifecycle.
5. It is an error to invoke the same beginsConversation method twice  
or multiple methods marked with beginsConversation without invoking an  
operation marked with endsConversation
6. If no operations are marked with beginsConversation, then  
invocations on all operations will begin a conversation if one is not  
started or continue an existing conversation

One thing I don't quite understand is your statement that " 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."  Couldn't this be handled by  
existing mechanisms where an operation is not marked with  
@EndsConversation but the service provider (if written in Java)  
invokes Conversation.end()? Given this, I think for clarity it is best  
to require a conversation to be ended if marked with @EndsConversation  
so the semantics are unambiguous. Is there a use case where this would  
not be appropriate?


> 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.
>
Thanks for the link but I think this type of approach is probably more  
complex than is warranted and, as you mention below, is best handled  
by specialized implementation types.


> 	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.
>
I think the dichotomy between declarative and programmatic is often a  
false one. For example, activity-based approaches are often considered  
programmatic and an analogy is drawn to transactional behavior.  
However, starting with JEE and arguably before that, declarative  
approaches to transaction management have largely supplanted  
programmatic ones for most application use cases. Arguably the idea of  
declarative transactions was one of the things EJB got right, even if  
it got the specific semantics wrong.

The current conversational model is declarative and we would do well  
to keep it that way for a number of reasons. One is to make wiring  
more fail-safe. For example, if conversation propagation were  
programmatic, how could a wiring algorithm determine a binding can be  
safely applied (i.e. it supports  conversation propagation) without  
introspection of the implementation "code" (bytecode in the case of  
JVM-based implementations)?


> 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.
>
Could you elaborate what you are thinking and the use cases not  
covered by existing mechanisms?

> 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.
>

I'd be interested to see if your concerns with the existing mechanisms  
are addressed by the above. If not, can you outline some specific  
application uses cases we could work through? Having some actual  
examples (potentially composites) would help us bring these issues to  
the fore.

Thanks,
Jim

> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>