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

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

I think Simon's use case is a common one, where you shouldn't remove an item
from a cart that hasn't been previously added. I thought we had got to the
point of not conflating a service contract (permissible ordering of
invocations) with the ability to get back to the "same" instance or state,
which do seem to be orthogonal to each other.

Martin.

> -----Original Message-----
> From: Jim Marino [mailto:jim.marino@gmail.com]
> Sent: 17 December 2008 20:08
> To: Martin Chapman
> Cc: 'Simon Nash'; 'OASIS Assembly'
> Subject: Re: [sca-assembly] Issue 94: Conversational services
> 
> 
> On Dec 17, 2008, at 11:11 AM, Martin Chapman wrote:
> 
> > a) because in all but simple cases it's a notational challenge.
> > I thought Simon was arguing for a) but I'll let him respond.
> >
> Could you list the common use cases that you believe can't be
> addressed by the given semantics? My argument would be that unless
> they fall into the "80 %" rule, then having basic functionality, even
> if it does not address complex scenarios, is a good thing as it will
> meet most people's needs. Having a clear set of use cases will help us
> decide if those cases are very common or not. Also, I would point out
> that the existing semantics to my knowledge don't preclude more
> complex semantics from being implemented either via an implementation
> type or application code.
> 
> Another way of looking at this is to ask, do you think the existing
> semantics are not useful in common cases or inhibit the complex ones
> from being realized using additional mechanisms?
> 
> FWIW, the applications I have been involved in have some fairly
> complex conversational services and the existing SCA mechanisms have
> held up well in practice.
> 
> Jim
> 
> 
> 
> > Martin.
> >
> >> -----Original Message-----
> >> From: Jim Marino [mailto:jim.marino@gmail.com]
> >> Sent: 17 December 2008 17:59
> >> To: Martin Chapman
> >> Cc: 'Simon Nash'; 'OASIS Assembly'
> >> Subject: Re: [sca-assembly] Issue 94: Conversational services
> >>
> >> Hi Martin,
> >>
> >> I'm a bit confused :-) One of the objections you raised with respect
> >> to conversational services seemed to be that service lifecycle
> >> semantics could not be imputed from the service definition. But
> here,
> >> you state that you agree with Simon's conclusions. Is it:
> >>
> >> a) You don't believe start/continue/end are semantics that should be
> >> exposed to clients
> >> b) You think that implementation state management semantics should
> >> not
> >> be exposed to clients but start/continue/end as service lifecycle
> >> semantics should be made explicit to clients
> >> c) Something else
> >>
> >> FWIW, my position is b.
> >>
> >> Jim
> >>
> >> (I plan on responding to Simon's post separately so as not to
> confuse
> >> the discussion)
> >>
> >> On Dec 17, 2008, at 9:39 AM, Martin Chapman wrote:
> >>
> >>> 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
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> 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
> >
> >