On Jan 6, 2009, at 9:05 AM, David Booz wrote: As we have them today == "magic" != the kind of shared context approach I'd rather see.
I think of magic as a type of illusion that people don't necessarily understand how it works (otherwise it wouldn't be entertaining). I don't believe conversations fall into that category as most enterprise developers understand the concept of instance routing. As evidence of this, here are a few programming models that require an understanding of instance routing:
1. EJB 2. .NET/WCF 3. JSF Managed Beans 4. Seam 5. Guice 6. Spring 7. Apache Beehive 8. Web Beans 9. JAX-WS
etc.,etc.
Why are conversations "magic" can callbacks or binding.sca not?
And that unfortunately we don't have enough time left to standardize so I'd rather have nothing in the spec and have a go at a proper model during the next version of SCA. I was not differentiating between specs, I was speaking in general because I see the problem as larger and more abstract than a specific tweak here or there in a technical proposal. We don't have to standardize everything we want in the first go, but what we do standardize had better be bedrock/core and solid. It's easier to add to a standard than to have to change it. It's better to standardize in small bits. The fact that standards take time is good thing, not a bad thing.
The compliance point is that an SCA runtime MAY support the conversational intent, the endsConversation marker, conversationViolation fault, and whatever other tweaks we make to the current "magic" in the model. I don't see what testability has to do with it. We aren't going to test everything that's a MUST let alone the MAYs.
Optional compliance is one approach we should consider. However, as Simon points out, this may introduce complexity in some of the other specifications. One other point related to that is the current "tweaks" I proposed greatly simplify callbacks. As I mentioned, I would be open to looking at how we could make conversations an optional compliance point. For these reasons, I think it is worth pursuing this further by continuing to focus on the technical issues.
Jim 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 <graycol.gif>Simon Nash ---01/06/2009 10:09:31 AM---Just one comment on this long and very interesting thread (other text removed for readability). <ecblank.gif> From: | <ecblank.gif> Simon Nash <oasis@cjnash.com> | <ecblank.gif> To: | <ecblank.gif> sca-assembly@lists.oasis-open.org | <ecblank.gif> Date: | <ecblank.gif> 01/06/2009 10:09 AM | <ecblank.gif> Subject: | <ecblank.gif> Re: [sca-assembly] Fwd: Conversational services | Just one comment on this long and very interesting thread (other text removed for readability). Simon David Booz wrote: > Thanks for the reply. > > See inline *<dab> </dab>* > > 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 > > Inactive hide details for Jim Marino ---12/23/2008 01:24:11 PM---Thanks > Dave. I'll try to comment inline inline.Jim Marino ---12/23/2008 > 01:24:11 PM---Thanks Dave. I'll try to comment inline inline. > > > From: > Jim Marino <jim.marino@gmail.com> > > To: > OASIS Assembly <sca-assembly@lists.oasis-open.org> > > Date: > 12/23/2008 01:24 PM > > Subject: > Re: [sca-assembly] Fwd: Conversational services > (cut) > > >> Another way I have seen conversations propagated is how > Microsoft Durable Services work using service-provider > tokens. In this model, they have decoupled the > conversational model from how correlation is transmitted (in > SOAP headers via WsHttpContextBinding, or using cookies via > BasicContextBinding). With this approach, one issue is that > the SCA infrastructure will have to wait for a back channel > message containing the token before a second invocation is > delivered. > Two problems here. 1) This is a new protocol, that is not > standardized, and 2) you will have to define how this works > for each binding spec. > > Aren't we already doing this for callbacks? > *<dab> We don't do protocols in SCA. We aren't standardizing the > callback over WS semantic.We have an example of one way that a stateless > callback could be done over WS. There is no requirement that any vendors > do it this way. </dab>* > *<dab> If you're suggesting that conversations as we have them today > could be an optional compliance point then I would probably agree to > that.... </dab>* > If you mean "as we have them today in all the SCA specs", I would be very concerned about this because of the complexity it would add (e.g., in the SCA Java spec). If you mean "as we have them today in the assembly spec", the complexity isssue is less significant, but what would the compliance point be? The assembly spec defines some syntax for indicating that services are conversational, but it doesn't define any testable semantics for conversational services. Simon --------------------------------------------------------------------- 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
|