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

[David Booz <booz@us.ibm.com>]

You've mentioned shared context a few times now but that's not what we have today. What we have today is a form of magic that happens underneath the programmer, orchestrated by the middleware that is tightly bound to instance management on the provider side. Transactions are much more like a shared context model IMHO where there are explicit protocol flows (not app flows) to establish the context on all related entities in the system. Yes, there is magic in the shared context model also, but it is divorced from the programming model. This is the shared context model that I greatly prefer, but that which I know we don't have time to spec out because we'd have to solve the cross binding protocol message flow problems. All the proposals I've seen to date which include the runtime magic try to hack around a proper shared context model and end up exposing themselves in subtle ways all over the programming model. A proper shared context model would be much more workable (i.e. conceptually compatible) across disparate middlewares and SCA component types.

My second point is that I think we're losing sight of our primary objectives with SCA Java. SCA Java needs to be a simple PM. There are plenty of more complicated PMs in the world today that do all kinds of gear-head stuff like this. It's fine for them to do that and we have a way to integrate with then...it's called implementation type extensibility together with the recursive composition concept. For example, see SCA JEE, Spring, etc etc, there will be many more. SCA Java doesn't need to be all things to all people. It has no business trying to compete with other whiz bang ideas in the world. It's there to solve simple problems in limited situations.

more comments below

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Jim Marino ---12/22/2008 01:13:12 PM---On Dec 22, 2008, at 1:47 AM, Mike Edwards wrote: >

From:	Jim Marino <jim.marino@gmail.com>
To:	Mike Edwards <mike_edwards@uk.ibm.com>
Cc:	"'OASIS Assembly'" <sca-assembly@lists.oasis-open.org>
Date:	12/22/2008 01:13 PM
Subject:	Re: [sca-assembly] Issue 94: Conversational services

---

On Dec 22, 2008, at 1:47 AM, Mike Edwards wrote:

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 would say conversations are much more restrictive then this. They are a specialization of stateful interactions which involve shared context between a client and a provider. For example, composite-scoped component implementations in Java are stateful but they aren't conversational. I think this is an important distinction as conversations were never meant to boil the "stateful applications" ocean and are instead meant to cater to specific, but common, use cases in application development.

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

This is not any more vague than transaction semantics such as those found in Spring, JEE and JPA. Most developers are fine with those, particularly JPA. Another slightly different example would be various Java web frameworks (and possibly frameworks in other languages) that implicitly create stateful objects such as shopping carts. In other words, there is precedent for this behavior that developers are aware of. 

<dab> It is more vague than transactions.  Transaction semantics are generally used at an interface level (i.e. all methods in the interface use the same transaction semantics), but this conversational stuff we have now is primarily a method specific idea...start, continue, end. There is a huge chasm between what we have today and transactions (or a shared context model).  I still don't and never will buy the shopping cart use case for a SOA service. The shopping cart concept is a tight coupling idea. Before REST, that's what you needed. </dab>

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.

A good idea would be to reinstate @beginsConversation, which caters to this case.

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.

This can be handled through existing mechanisms although in the interest of simplification, I would be willing to eliminate this capability. Handling multiple conversations can get very complex, particularly around handling concurrency properly. Is there a use case you have in mind that you think will be very common? I believe there are ways to address the need for multiple ongoing conversations using existing mechanisms but it would be helpful to work from a concrete case. These mechanisms may involve more work for developers, but that may be acceptable given the complexity involved.

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

There is no reason why the client needs to create the id. It simply needs to provide one during invocations. The id is created by the domain out-of-band or piggy-backed on either the return of a synchronous operation or callback. It is important to note this makes clustered routing and failover much easier to implement and manage. In posts to the Java list a while back I drew up sequence diagrams of how id generation can be done which I could dig up and reproduce here if people are interested.

<dab> In a shared context model, the key to the shared context is generated by a context coordinator, not the client, not the provider, but a protocol level entity.  Then each party that wishes to be a part of the context registers his interest with the coordinator.  The coordinator then owns the lifecycle of the key.  Perhaps this is what you mean by the Domain, I can't tell for sure.  All parties registered in the context get notified when the context lifecycle changes.  The context key is passed around in anyway that the app or middleware wants to do it.  I don't see any of this in your proposals which why I'm confused about how this can be a shared context model. </dab>


It may also be worth noting that most conversational services I have seen don't return the ID as part of the application signature. For example, shopping carts generally don't have create methods or methods that pass cart ids as parameters or return values.
<dab> That's right.  That's what I am calling magic. </dab>

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.

IMO that would be a poorly designed service. If the service provider ends the conversation, the client should be made aware of it either implicitly as part of the application semantics or explicitly through notification (e.g. a return value or callback).

<dab> This kind of lifecycle change would be noticed by a shared context coordinator and sent to all interested parties.  Piggybacking return flows or callbacks is more magic.  Service providers need to own their own lifecycle and therefore need to be able to be independent from any consumers who use them and any providers they use. </dab>

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.

The @ConversationalAttributes can be used to explicitly declare timeouts. One issue I have seen come up in practice is people forgetting to set conversation timeouts. This could be fixed by allowing vendors to implement default timeout values in the same way transactions are handled.
<dab> ok, we agree on something </dab>

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.

We have had several large teams of engineers building applications for about a year-and-a-half using conversations extensively. We have found they have simplified handling some very complex use cases (e.g. large document processing) and are a natural fit for integrating SCA with key technologies such as JPA. Although the engineers working on these projects do not participate in the OASIS TCs, they have been some of the most vocal advocates of the importance of retaining the current conversational model. Some have said they would be willing to share their experience with the appropriate TCs. 

It may also be worth pointing out that the state-of-the-art in Java and elsewhere is focusing on adding similar conversational semantics. For example, Seam, .NET, and the JAX-WS RI all support analogous conversational features.   

<dab> That old addage about following your friends off the bridge comes to mind.  I don't see any of the technologies you mention playing in the SOA game.  They are lower level implementation technologies, and they are good in that space. That's not where SCA should be. </dab>


There is definitely room for improvement in the current model. However, based on my and other's experience implementing applications with it, I don't believe it is broken. If there is a better approach, I am also more than willing to listen and work on an alternative. I have proposed some changes to the existing model to the Java TC that attempt to address issues brought up by various people. These changes also aim to greatly simplify callbacks. Parts of the proposal have import to the Assembly TC but I wanted to start with the Java TC since most of the changes impact the Java programming model. In the interests of moving discussions forward would it be useful to:

1. Have me write up a short proposal for the changes relevant to the Assembly TC. 
2. Ask some of the engineers that have used the existing model extensively if they would be interested in sharing their experiences with the TC. I can help with this.
3. Have someone volunteer to draft specific application use cases that highlight deficiencies in the current model. We could use these to decide if the model needs to be changed or the use cases could be accommodated by other mechanisms.
4. Have someone volunteer to draft a proposal for an alternative that preserves the important functionality provided by conversations. At various times, activity sets have been proposed as a replacement. This is interesting, however, one of my concerns is that it will either wind up being too complicated (e.g. like the manifestation in CORBA) or not much different than the existing model.

IMO, it will be very counterproductive for SCA if we simply remove the existing model which people are using to build applications today without first looking at why it is deficient in practice or understanding an alternative.

<dab> I have no doubt what-so-ever that there are developers who find what you've built to be useful.  We also have a large base of developers that has never found a need for it while implementing services for banks, insurance companies, brokerages etc.  What they used was something like the shared context model I alluded to above, and it's quite powerful. Comparing developer bases and customer experience is not going to get us anywhere on the technical issues. I see this breaking down in four ways, either we:
1) want some "magic" and we want to do it right - shared context model like transactions, OR we
2) want a purely application centric correlation capability, OR we
3) try to fix up what we have today, which is a hybrid of 1 and 2 and which is where I see your proposals fitting in, OR we
4) standardize nothing this time around and try again in the next version.

Until we get some kind of agreement on one of those 4 very basic directions, we'll just be spinning our wheels.
</dab>


Jim

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 & nbsp;
>>>>> 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