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

[Mike Edwards <mike_edwards@uk.ibm.com>]

Folks,

Let's get to the heart of the issues
with conversational services.

SCA Conversational services aim to deal
with services which have state - and where that state matters
in the processing of successive operations
against a given service.

I believe that the basic sequence of
operations involved in conversational services is:

create a conversation
continue a conversation
end a conversation

The question is how are these basic
parts of the conversation identified and who is in control of them -
particularly when dealing with problems
like a client going away mid-conversation.

In SCA at present, the "create
a conversation" step is vague.  The basic rule seems to be:
"if the client invokes any operation
on a conversational service and there is no conversation already
in flight, create a new conversation".
 

The problem I've always had with this
rather vague approach is that it is clear from many examples that
you can't use any old operation to start
a conversation.  Either one or one from a specific group of operations
must be used to start the conversation.
 SCA provides no marking for this.

I note that this also gives some problems
if ever there is a need for the client to create multiple conversations

with the same service.

"continue a conversation"
seems to be "invoke any operation that is not explicitly marked as
end conversation"

End conversation is defined through
operations that are explicitly marked with an annotation.  Except
that we
also define capability by which the
service can programmatically end the conversation.

The client seems to have a large part
in controlling the lifecycle of a conversation, but this is paradoxical
- since
the state of the conversation lives
on the server side.  If I modelled a conversational service in business
data
alone, there would inevitably be a "create"
operation which the service would use to create the state and which
would return some ID which represents
the conversation ("OrderID" etc).  With SCA conversations,
it is the client
that creates an ID representing the
conversation.

If a conversation always ended when
the client called a specific operation on the service, this would be clear
but
gives rise to the problem of what to
do where the client goes away mid-conversation without ending it.  However,
SCA conversations can be ended programatically
- so the service can end the conversation without there being
a mechanism by which the client gets
to find out about it.  Presumably also in the case of the client going
away,
in practice some kind of timeout is
implied for the conversation, allowing the service to clean up its state?
 This is
not stated anywhere in the model.

These vaguenesses trouble me - and they
will trouble programmers using SCA.  I feel the need for a better
model
that has clear cut boundaries and crisp
semantics - something that is not there at the moment.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Jim Marino <jim.marino@gmail.com>
To:	Simon Nash <oasis@cjnash.com>
Cc:	"'OASIS Assembly'" <sca-assembly@lists.oasis-open.org>
Date:	18/12/2008 07:24
Subject:	Re: [sca-assembly] Issue 94: Conversational services

---

Comments inline...

Jim

On Dec 16, 2008, at 3:09 PM, Simon Nash wrote:

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

I disagree. In most cases, the semantics of a service contract can be  
specified declaratively. In the examples above, the cart could be  
defined as:

@Conversational
public interface Cart {

                
void add(Item item);

                
void remove(String itemId) throws ItemNotFoundException;

                
@EndsConversation
                
void checkout() throws EmptyCartException;

}

Note I have removed the create() operation as it is unnecessary and  
most shopping carts I have seen use implicit instantiation (e.g. as  
provided by HTTP session objects in the Servlet Specification).

I would generally model ItemNotFoundException and EmptyCartException  
as unchecked exceptions as they are programming errors and not user  
errors that are recoverable. For example, a UI should never allow a  
user to remove a non-existent item in their cart or checkout an empty  
cart.

Java 7 is taking this further by expanding the attach points for  
annotations to guarantee such things as values are not null. This  
mechanism is extensible so I imagine all sorts of semantics can be  
enforced declaratively.


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

I think a number of issues are being conflated here:

1. Begin, continue, and end control the conversation lifecycle, not  
the implementation lifecycle. In other words, conversation lifecycle  
is not coupled to application logic but application logic is coupled  
to conversation lifecycle (and the service contract). This is an  
important distinction. In the SCA Java programming model, conversation
 
lifecycle happens to affect the lifecycle of implementation instances  
only because conversational services must be implemented with  
conversation-scoped implementations. This may not be the case for  
other programming models. For example, it would be valid for a  
programming model to allow a conversational service to be implemented  
by a singleton. In that case, multiple conversations may be handled by
 
the same instance and calling begin, continue, or end has no bearing  
on the instance lifecycle.

2. How ordering constraints are enforced is a separate issue from  
describing those constraints. Ordering constraints exist even if the  
implementation changes. For example, a BPEL component may be  
substituted for one written in Java. If the service contract does not  
change, the ordering constraints should not either. However, what can  
change is the mechanisms for enforcing those constraints. In Java,  
those constraints are mostly left to application code, while in BPEL,  
the engine may provide many of these features.

3. Begin/continue/end may not affect retention of implementation  
instances at all. For example, implementation instances may be removed
 
from memory through passivation even though a conversation has not  
ended. Or, an @EndsConversation may not remove any instance as it  
could have been passivated prior to the invocation.

I believe conversation lifecycle is part of the service contract  
because clients need to know about it. If the semantics of  
conversation lifecycle changes, clients will break. For example,  
@EndsConversation doesn't mean "remove the implementation instance
 
from memory" but rather "I'm finished with the conversation so
you can  
release any resources associated with it". Part of a service semantic
 
may be that clients must signal when they are done with a  
conversation. If the service is refactored such that the provider  
takes care of it in some other way (for example by placing  
@EndsConversation on a callback operation), then the service contract  
needs to change.

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

I don't think implementation state is visible to the client with the  
current conversational model. Only conversational state is by virtue  
of the definition of a conversation (shared context between two  
parties). For example, a client does not "know" a service is
backed by  
a conversation-scoped Java implementation. The service provider could  
be a BPEL process, C++ component or something else. Even in Java,  
multiple instances may service the same conversation, for example, if  
a conversation is passivated for long-running interactions. Therefore  
the client should not assume that it is invoking the same  
implementation instance on successive operations. The only thing it  
should assume is that the conversation context (state) will be  
available for all invocations in a conversation.


>  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

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU