[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]