[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Issue 94: Conversational services
On Dec 16, 2008, at 3:50 AM, 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. > +1 I'm going to make a few proposals for simplifying conversations and callbacks further than what they are. Some of these items are currently being discussed in the context of the Java TC, so I will start there. Jim > 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]