sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Issue 94: Conversational services
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "'OASIS Assembly'" <sca-assembly@lists.oasis-open.org>
- Date: Mon, 22 Dec 2008 09:21:08 +0000
Folks,
I have a strong opinion that SCA should
NOT get into the business of describing the business semantics of
service interfaces - ie describing (in
any form) the valid sequences of operations that a client may call on a
service interface. This would
be way too complex and way too extensive a task.
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:
| Simon Nash <oasis@cjnash.com>
|
To:
| "'OASIS Assembly'" <sca-assembly@lists.oasis-open.org>
|
Date:
| 16/12/2008 23:12
|
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]