[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Issue 94: Conversational services
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]