RE: [sca-assembly] Issue 94: Conversational services

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

Probably getting a bit too indepth for an email discussion but I'll add a
couple of more comments.

I think we both agree that when  we annotate an interface we are further
defining the contract that interface offers. For a simple non-bidirectional
interface, the annotations can work, but as soon as we add in bi-directional
and multi-party we need more. In the bi-directional case, we may need
annotations to say "if you invoke X, I will invoke y back", and a
multi-party case something like "when x is invoked, I will invoke Z on
another party (as well as call you back with y!)". This becomes a notational
mess and IMHO is best left to other languages (which I believe we already
resolved).

I think the prime use case is really in being able to make sure you get back
to the same instance, and this I see is orthogonal to the contract approach
that details partial ordering of operations. Maybe we could explore this
approach instead.

Martin.


> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 12 December 2008 19:54
> To: Martin Chapman
> Cc: 'OASIS Assembly'
> Subject: Re: [sca-assembly] Conversational services
> 
> 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
> >