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

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

The add and remove can be parameterised, but since I do not disagree with
your conclusion this is academic :-)

> -----Original Message-----
> From: Simon Nash [mailto:oasis@cjnash.com]
> Sent: 16 December 2008 23:10
> To: 'OASIS Assembly'
> Subject: Re: [sca-assembly] Issue 94: Conversational services
> 
> As Jim has mentioned, I believe it is better to take the operation
> ordering choreography out of the interface definition and make it
> the responsibility of the provider implementation to enforce.
> 
> The reason for this is that there are some common cases that can't
> be enforced declaratively.  For example, consider a "shopping cart"
> scenario with the following operations:
>    create()    create a new empty shopping cart
>    add()       add an item to the cart
>    remove()    remove an item currently in the cart
>    checkout()  purchase the items currently in the cart
> 
> We can declaratively assert that create() must be called first,
> followed by add(), optionally followed by some combination of
> add() and remove() calls, followed by checkout().  We can't say
> declaratively that when calling remove(), the item being removed
> must already be in the cart.  We can require an add() call before
> a remove() call, but this add() call could have added a different
> item from that being removed.
> 
> There are many similar cases where declarative annotations are not
> sufficient for fully defining operation ordering constraints.  If we
> are going to include a "conversation" or "stateful correlation"
> mechanism in SCA, with begin/continue/end operation semantics that
> control the creation/retention/removal of implementation instances,
> I think these are best treated as part of the service implementation
> because they are closely coupled to the design of its business logic.
> 
> The interface needs to fully describe the semantics that the client
> must observe when using it, including not only the ordering of calls
> but also the parameters that may validly be passed on those calls
> (as in the add/remove case described above).  However, the management
> of implementation state by the service provider should not be visible
> to the client and therefore should not be part of the interface.
> 
>    Simon
> 
> Martin Chapman wrote:
> > 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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