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

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

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.

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