OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Raw Chat from March 4 F2F


 

Simon Holdsworth: Hi, for those wishing to dial in we are having some problems with the phone system.

Simon Holdsworth: 09:00 - 09:15 Introductions

 

o Scribe assignment

o Discuss agenda

 

09:15 - 10:30 Open issue discussion

 

o Decide on order to discuss open issues. See below for links to issues.

o Start discussing issues

 

10:30 - 10:45 Break

 

10:45 - 12:00 Open issue discussion

 

12:00 - 13:00 Lunch

 

13:00 - 15:00 JCA Spec walkthrough

 

o Go through JCA spec as submitted

o Identify issues with the spec itself

o Identify consistency issues in other specs (esp. JMS spec)

 

15:00 - 15:15 Break

 

15:15 - 17:00 JCA Spec walkthrough continued if needed

else open issues discussion

 

17:00 Close

anonymous morphed into Khanderao

Khanderao: Simon, I dialed in and waiting for you to start the conf

Khanderao: Thanks, I am in.

Simon Holdsworth: OK, I've dialled in, but the phone we are using is not great.  You may only hear me and people right by the phone

anonymous morphed into Peter Peshev

Khanderao: oh. I will see how long I can manage this way. Otherwise I will drop out.

Eric Johnson: Eric J. chosen as scribe (so blame me for typos)

Eric Johnson: Brief discussion of agenda - no comments on agenda as it stands.

Eric Johnson: Agenda for today is here: http://www.oasis-open.org/apps/org/workgroup/sca-bindings/event.php?event_id=17865

Simon Holdsworth: Open issue 2

http://www.osoa.org/jira/browse/BINDINGS-2

How should SCA callback semantics be carried over Web Services?

 

Open issue 7

http://www.osoa.org/jira/browse/BINDINGS-7

JMS bindingType and ordered intent - clarification needed

 

Open issue 8

http://www.osoa.org/jira/browse/BINDINGS-8

No bindingType for binding.ws

 

Open issue 11

http://www.osoa.org/jira/browse/BINDINGS-11

"Formal" WSDL generation is unclear, ambiguous, and incomplete

 

Open issue 13

http://www.osoa.org/jira/browse/BINDINGS-13

What namespace(s) do we use for each binding?

 

Open issue 14

http://www.osoa.org/jira/browse/BINDINGS-14

Define conformance targets

 

Open issue 17

http://www.osoa.org/jira/browse/BINDINGS-17

Rules for Binding compatibility

 

Open issue 19

http://www.osoa.org/jira/browse/BINDINGS-19

Web Service binding should allow #wsdl.binding with reference targets

 

Open issue 20

http://www.osoa.org/jira/browse/BINDINGS-20

JMS binding URI should follow JMS IRI scheme submitted to IETF

 

Open issue 21

http://www.osoa.org/jira/browse/BINDINGS-21

Support for callback and conversation ID-s in bindings

 

Open issue 22

http://www.osoa.org/jira/browse/BINDINGS-22

Bindings specifications should provide exemplary Implementations for Callbacks and Conversations

Eric Johnson: Simon H. reviewing list of issues above.

Eric Johnson: Michael R. - good to take on #2 early.

Eric Johnson: Bindings 23 raised last week - not on the current list above.

Eric Johnson: 17 & 19 seem to be closely related.

Eric Johnson: 21 seems to be more detailed issue related to #2.

Eric Johnson: Michael R. - starting in the order that the issues are listed kind of works.

Eric Johnson: Michael R. - should we raise the namespace issue with the liasion committee.

Eric Johnson: Simon N. - come up with a proposal... (snicker).

Eric Johnson: Michael R. - move that committee provide guidance.

Eric Johnson: on how frequently new namespaces should be created versus shared.

Eric Johnson: Ashok - "every three months?"

Eric Johnson: Michael R. - granularity, rather than frequency.

Eric Johnson: Sanjay 2nded.

Eric Johnson: Simon N. - it would help that we have a proposal to put forward.

Eric Johnson: Anish - Whatever we come up with won't be unanimous, and then the same discussion will happen there.

Eric Johnson: Simon N. - if we have no opinion, then do what Mike has proposed - otherwise we should put in an effort.

Eric Johnson: Michael R. - should binding.ws have its own namespace, as a good test case?

Eric Johnson: Martin Chapman & Anish - making the specs evolve separately.

Eric Johnson: Anish - if we expect SCA to succeed - then we need to get away from lock-step requirement.  Separate namespaces helpful.  If you've accepted XML, you've accepted namespaces.

Eric Johnson: Any reasonably complicated config file - you see many XML ns already.

Eric Johnson: Simon N. - Trying to remember what we said on the phone - Michael B. said - if these are all independently lifecycled - then end user has to figure out how the complexity of different versions adds up.  What could go to the liaison committee - do we want a loose federation - or do we want a centralized model?  Guidance from the liaison committee would be helpful on that point.

Eric Johnson: Michael R. - strongly feel we shouldn't debate our recommendation in this committee.  Cohesive plan for bindings, intents, implementation types - make sense to think of them together.  More important to put them to the committee.

Eric Johnson: Anish - Good point and interesting one.  if they are unique namespaces - it becomes a different question about compatibility.  If we have a single namespace we tie our hands.

Eric Johnson: Simon N. - going with separate allows lock-step or separate.  Single namespace forces lockstep.

Eric Johnson: Michael R. - Calling the question.

Eric Johnson: Simon N. - Objecting to calling the question.

Eric Johnson: All in favor of calling the question.?

Eric Johnson: Four in favor.

Eric Johnson: Seven against calling the question.

Eric Johnson: Debate continues.

anonymous morphed into anish

Eric Johnson: Simon N. - Proposing amendment - go to the liaison committee with a proposal that we should have a number of namespaces - binding namespaces should not be the same as the assembly namespace.  Would like us to be slightly more specific than that.  We could just lay out a principle, or we could lay out a specific proposal.  Proposal for now - set out a principle - there should be multiple namespaces for different bindings.

Eric Johnson: David B. - No - one namespace for everything.

Eric Johnson: Martin C. - 2nd Simon's N. amendment.

Eric Johnson: Tom R. - Multiple per bindings? Or one per binding?

Eric Johnson: Simon N. - No, just that there is more than one NS for all bindings.

Eric Johnson: Martin C. - don't want to have to rev everything just for making one change.

Eric Johnson: ?? on the phone - Is that really true?

Simon Nash: on the phone was Michael Beisiegel

anish that was michael beisiegel

michael beisiegel: thx

Eric Johnson: Mike R. - Same definition can exist in two namespaces - can have a more general namespace.  If you don't want to use the JCA binding that comes with SCA 2.0, instead of using SCA package namespace, or you could use the one that comes at the "bleeding edge."

Eric Johnson: Should push this to the liaison committee rather than doing it here.  Not ready to come up with a solution for bindings alone.  Also object to the notion that we're asking for permission from the committee, because they have no control over what the bindings TC is doing.

Eric Johnson: Ashok - if you have one namespace - then you have to rev the namespace when you make changes.  You can have big chunks, but then smaller parts that you rev independently if you want.

Eric Johnson: [Ed. oops - last sentence was from Mike R.]

Eric Johnson: Martin C. - Can share concepts from JCA into another namespace.

Eric Johnson: Mike R. - Everyone using SCA can choose what came with 2.0, or people can choose different namespaces from different documents.

Eric Johnson: Anish - we could use import and include to our advantage.

Eric Johnson: Simon N. - we could have both a single namespace, and multiple namespaces - as a normal rule - should have things in the same namespace, but free to diverge for "leading edge mode."

Eric Johnson: ... or we could define for our specifications separate ns - but a release of SCA could bring these things into a consolidated SCA namespace.  You can start centralized or decentralized.  This approach better than either extreme.

Eric Johnson: Anish - want to completely understand what Simon N. is saying.  In the schema document.

Eric Johnson: Mike R. - Schema document for SCA, as well as for individual items.

Eric Johnson: Anish - Supposing bindings.ws creates a 1.6 version - it gets a new namespace.  In my composite - if I want to use it - use the two different prefixes.  At some point in the future, when a set have evolved, all pulled together into a new SCA 2.0 version.  That is a much better way of doing things then "always in sync."  Issue - when evolving.  When migrating a 1.2 to a 2.0 - there appears to be a change, but there may not actually be.

Eric Johnson: Mike R. - If what you care about is using the old one, you can point to that one too.

Eric Johnson: Anish - what if 1.2 and 2.0 are exactly the same thing.  Two qnames for binding.ws that are actually identical in meaning.  When we go to 2.0 - everything included in assembly namespace.  New qname.  The 2.0 SCA qname and the 1.2 qname are same, but they look different.

Eric Johnson: We have to create a new version - side effect of.

Eric Johnson: Simon N. - new alias, that's all.

Eric Johnson: Ashok - Looking for precedence.  SX TC - all specifications have different namespace.

Eric Johnson: Sanjay - can we end up with too many namespaces.

Eric Johnson: Tom R. - Two issues - easy way to evolve, but also multiple committees.  Other TCs - can make backward changes, have a RDDL file that points to two different versions of schema.  Easiest if the TC controls the evolution of the namespace.  You can come to the new namespace with the new feature.  More than one namespace across the set of bindings is very wise.  If you have seventeen schemas with one namespace, how do decide who controls.

Michael Rowley: http://www.robertsrules.org/motions.htm

Eric Johnson: Eric J - just make sure you share the same underlying XML schema complex type.

TomRutt: To clarify, if there are multiple schemas with different subjects across a single namespace, who will decide if a change to one of those schemas is backwards compatible with the entire set of other schemas in that namespace.

Eric Johnson: Mike R. - move to restrict debate to 10 min.

Eric Johnson: 2nd by Dave B.

Eric Johnson: Nine in favor - nobody opposed.

Eric Johnson: Anish - We should adopt what Tom has suggested - rules for creating a namespace.  Define what backward compatibility means - just copy rules from other TCs.  Like the idea that everything is not lock-step.

Sanjay: Example of rules for namespace lifecycle management - http://docs.oasis-open.org/ws-rx/wsrm/200702

Eric Johnson: Simon N. - go to the committee outlining what we've discussed for the last little bit.

Eric Johnson: Mike R. To craft an amendment - bindings TC suggests investigating different namespaces for each extensibility, but in parallel, a broad SCA namespace, that duplicates the definitions in the fine grained definitions, for all the technologies that go into that.

Eric Johnson: Anish - Why would you want to propose that level of detail?

Eric Johnson: If the BPEL committee wants to use the SCA 1.0 - they really need to wait for assembly.

Eric Johnson: Simon H.  Current amendment - there should be more than one namespace....

Eric Johnson: Martin - we should dispose the amendment.

Eric Johnson: Seven in favor - nobody opposed.

Eric Johnson: Amendment accepted.

Eric Johnson: (Clarification - amendment was a replacement motion).

Eric Johnson: Mike. R. motion - bindings TC suggests investigating different namespaces for each extensibility point, but in parallel, a broad SCA namespace, that duplicates the definitions in the fine grained definitions, for all the technologies that go into a version of SCA.

Eric Johnson: 2nd by Simon N.

Eric Johnson: (Fix to above) --> suggestion that the liaison committee doing the investigation.

Eric Johnson: Sanjay - don't see the point of having the freedom for a short period of time.

Eric Johnson: Tom R. - multiple schemas mapping to the same underlying database element - seems like a nightmare to keep working.  Little confused about mechanics of this working.

Eric Johnson: Maybe this is part of the investigation...?

Eric Johnson: Martin C. Point of order - ten minutes up.

Eric Johnson: Eight in favor - two against.

Eric Johnson: Amendment passes.

TomRutt: The TC wishes the liaison sc to give guidance on the granularity of namespaces across sca.  The TC recommends that more than one namespace be allowd across the SCA TCs. In addition, TC suggests investigating different namespaces for each extensibility, but in parallel, a broad SCA namespace, that duplicates the definitions in the fine grained definitions, for all the technologies that go into that.

Eric Johnson: Simon H. That is the amended motion.

Eric Johnson: Unanimous in the room.  Nobody on the phone objecting (12 votes for).

Eric Johnson: Simon H. - Fifteen minute break.

Simon Holdsworth: Reconvene at 10:45 Eastern to discuss open issues.

Simon Holdsworth: Will redial into improved speakerphone for 10:45

Eric Johnson: Reconvening.

Mike Edwards:

Bryan Aupperle: Simon, you are very faint.

Eric Johnson: Discussed earlier that we'd tackle issue #2 & 21, then 17 & 19

Simon Holdsworth: Issue 2 text: The Web Service binding provides no example or suggestion for how SCA callback semantics could be carried over Web services. There is an example in section 2.2.3 for how conversation semantics could be supported. It would be good to give some guidance (somewhere in the range between example and normative) for what could be done for callbacks. One possibility is to make use of the capabilities provided by WS-Addressing.

Michael Rowley: Id like to get this topic started.  Ive narrowed the subject line from the original Issue 22 title, since Id like this particular thread to be on how callbacks could be handled in the WS-* world.  We can handle conversations and other bindings on other threads. 

 

 

 

First, Ill assume that we will try to use WS-Addressing, if possible. 

 

 

 

My first thought is that it would be preferable to be able to leverage the ws-ReplyTo field, since I believe that it should be possible to distinguish replies from callbacks, and I also believe that callbacks should go to the same place that replies would go to.  I have a vague recollection that Anish preferred the use of <wsa:from> rather than <wsa:replyTo> for passing callback ID information.  Unfortunately, I cant find an email to that effect, so Ill ask that he confirm or deny that.

 

 

 

I've been thinking that the client that is going to receive callbacks might want the reference parameters that would be available if the service provider follows the rules from the "Formulating a Reply Message" section of the WS-addressing spec.

 

 

 

One way that a callback could be distinguished from a reply is that the callback could have a <relatesTo> header that uses a relationship type of "oasis.org/isCallbackFor" and a reference to the messageID that the callback is in response to.  I havent seen other uses of the <relatesTo> header, but it seems like this is exactly the sort of thing it is meant for.

Eric Johnson: Mike R. - By narrowing this discussion to binding.ws - looks like issue #2.

Eric Johnson: Mike R. - (reviewing above text above)

Eric Johnson: Anish - can have multiple uses of "relatesTo".

Eric Johnson: Mike R. Is there any problem with using "relatesTo"?

Michael Rowley: WS-Addressing: http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/

Eric Johnson: Simon N. - Reason for "from" - callbacks can go back to someone else other than the sender.  If there is a possibility of callbacks needing to flow to destinations other than replys, that rules out "replyTo"

Eric Johnson: ... discussions around whether callbacks are even allowed to go back to others not the sender, for example.  If we could resolve somehow that callbacks only go back to the sender, then we could use replyTo.

Eric Johnson: Tom R. - What is a response.  In the current WSDL world today, want to be able to map to two underlying SOAP one-ways.  Don't want to do something here that will prevent people from using two underlying SOAP one-ways.

Eric Johnson: Have to be careful about use of replyTo, since we don't want to block alternate transport replies.

Eric Johnson: Mike R. - What is necessary - be able to distinguish between a response and a callback.  Can look at the message - the message will have a "relatesTo" value.

Eric Johnson: Simon N. but that would mean that we're requiring that callbacks and replies go to the same place.

Eric Johnson: Anish - That's why we should use something other than reply to.

Eric Johnson: ... in the request - might want to use the anonymous reply, but then have a callback address that is different.  We could define our own EPR, or we could reuse "From".  Could also say, if you don't specify, then we use "replyTo".

Eric Johnson: Sanjay - Make sure that there is a specific place in the SCDL for putting the binding on the callback.

Eric Johnson: Anish - at the service end, don't want the same callback for all of its callback.  On the reference end, you can specify this, but you cannot specify this on the service side.  How does the service know to correlate?

Eric Johnson: If it is binding.ws - could be listening to the whole world.

Eric Johnson: Simon N. - need runtime information here.

Eric Johnson: Sanjay- different components referencing a service - how does the service know at runtime.

Eric Johnson: Mike R.- don't want to create a new SOAP header, because then it looks like a new protocol (although it looks like that a little bit anyway).  We can use From to direct the callback.  But use the same reference parameters - client doesn't say which WSA headers to use.

Eric Johnson: Anish - SCDL cannot provide the information for binding, because it has to be overridden at deploy time.  Can statically provide reference params, but not the wsa: address where the message will be sent.  Important to distinguish between response and a callback.  Example: primary interface will have a req/resp. - and a separate callback.  Want, for example, anonymous reply, but then a callback.

Eric Johnson: ... argues for using "From".

Eric Johnson: Sanjay- understand that static configuration might not be feasible.  But we still need to provide static configuration.  Also, how do you define which policies are in effect?  Solve the problem separately of which instance of the wire.

Eric Johnson: Anish- in runtime messages - for all bindings - need to identify the component from which a message originates.

Eric Johnson: Sanjay- yes.

Eric Johnson: Mike R.- no only when you need callbacks.

Eric Johnson: ... in case of policy, especially for callbacks, you need to know.  Up 'til now, we've worried about what is in the SCDL, but then now we are pushing the question - what goes on the wire.  If there is a static address, then the static address can tell you.

Eric Johnson: Anish- If reply is non-anonymous - which policy do you use on the response message?

Eric Johnson: Mike R.- can put policy assertions on the EPR.

Eric Johnson: Anish- but then you're relying on the incoming message to be truthful.  Seems like a more general problem.

Eric Johnson: Simon N.- If the message says "I'm from ..." - is the same as having the message carry the policies.

Eric Johnson: Mike R.- Service side has to have the compatible policy with the reference.  So is this really a problem.

Eric Johnson: Anish- if you have multiple ways to do "strong authentication", then the service may still need to choose the right one.

Eric Johnson: Simon N.- don't really require caller identity.  Could use some other means.

Eric Johnson: Sanjay- otherwise repeating everything that occurs in the SCDL, seems burdensome.

Eric Johnson: Anish- on the server side - if a policy is optional - you don't know if the client supports it.  MTOM, for example, service doesn't know if it can respond with MTOM, if the message it gets doesn't have MTOM.

Eric Johnson: Ashok- our policy model means that client and server need to agree up front.

Eric Johnson: Mike R.- we do know this ahead of time, A1 --> B vs. A2 --> B  - using different policies.  Need to know who sent you.

Eric Johnson: Tom R.- WS-Addressing - concept of a response in the non-anon case - no way to distinguish a callback from a response.  Using relatesTo could solve the problem.

Eric Johnson: Mike R.- just talking about responses here.

Eric Johnson: Tom. R- use of from not talked about in WSA.  Should be solved in a more generic manner.  Really should have been something that they did.

Eric Johnson: Anish- Don't think WSA could have solved this.  At message level, defined how to correlate two things.  Also how you do things in WSDL.  There was a member submission that had two different .  If we use "From", then we'd need a different header for callbacks.  Concrete ex.  No "from" EPR - reference params in the URI.  If the same component is making multiple calls to different services - use different query params on the URI - different WSA:Address.  Need to separate the identity of a component, and where you can send a callback.

Eric Johnson: ... need to figure out how to communicate that identity.  WSA:address not necessarily a dereferencable place.

Eric Johnson: Martin C.- why not have a callback header anyway.

Eric Johnson: Simon N.- Same point.  Use "From" to identify component.  Limits how we can use "from" for callback.

Eric Johnson: Anish- Not logged as an issue - identifying of the component name in a message.

Eric Johnson: ACTION Sanjay to raise a new issue.

Eric Johnson: Sanjay- need to point in the SCDL, but also need to identify information at runtime.

Eric Johnson: Anish- could have a separate parameter that identifies the caller.

anish: Eric: let me play the devil's advocate, we are talking about runtime message. You could leave it out of scope. You could use JMS-specific technique to do something about it. In the HTTPS case, there could be a way to ask for authentication

Eric Johnson: Sanjay- doesn't WSA specifies semantics.

Eric Johnson: Eric J. - ought to think about what we shouldn't do - so that we can make sure that we don't generate conflicts.  Transports might carry this information.

Eric Johnson: Mike R. - enabling cross domain collaboration.  SCA doesn't need to step in and specify how it is working within a domain.  However, crossing domains, how do we make this work.  There is no wire. Yet you somehow need to know what to do.  You might have policy.

Eric Johnson: Dave B. - no way to do callbacks across domains with bidi interfaces.  Always do services and references.

Eric Johnson: Simon N.- Isn't this discussion about crossing boundaries.

Eric Johnson: Mike R.- How do you know who to respond to?

Eric Johnson: Simon N.- How do I model this.  How do I pass the reference so that the service knows how to call back.

Eric Johnson: Dave B.- When we lost "locate service" we lost the ability to do this.

Eric Johnson: Simon N.- which case: within the domain case, across the domain?  Some of these issues call for exemplary ways, not standards.  We need to decide which of these cases do we need to specify.

Eric Johnson: Simon H.- We're talking about issue #2.

Eric Johnson: Simon N.- Thinking about cross domain callbacks.  We are now blocked on making further progress unless we decide on in-domain or cross-domain.

Eric Johnson: Mike R.- Within domain - what you want to know at runtime - what wire did the message come in on - so that you can look at requirements on the outgoing.  If it is cross domain, you don't have a pointer to a wire.  Either, need to know in advance about all of your clients, or what constraints.  If we solve the cross domain problem, then we can use it within the domain.

Eric Johnson: Simon H- Looking at the value of the two cases - more value for the cross domain cases.  Runtime can solve it however it wants.  Less value to describing how it works within a domain.

Eric Johnson: Anish- Identifying the wire - only within domain - if we let every SCA runtime define this - then we lose portability.

Eric Johnson: Mike R. & Simon H- no.  Developers don't see this.

Eric Johnson: Mike R.- What standards do we have for specifying constraints on sending responses.

Eric Johnson: Anish- there is a one page spec for specifying policy within an EPR.

anish: http://www.w3.org/Submission/WS-MTOMPolicy/

anish: oops wrong URL

anish: http://www.w3.org/Submission/WS-PAEPR/

Eric Johnson: Mike R.- Isn't that the answer - any policy requirements on responses show up as policy on the replyTo EPR.  And any policy on callback shows up in the "from" EPR.  And also echo back the reference parameters

Eric Johnson: Eric J. - example - req/repl., with callback on email address.  Use "from" EPR. but specify policy in the header.

Eric Johnson: Mike R.- Use a policy reference (WS-Policy reference, not SCA policy set reference).

Eric Johnson: Martin C. - Reply and callback are different.

Eric Johnson: Anish- Where does the callback interface get declared?

Eric Johnson: Martin C.- extending the domain of what clients must understand, in order to understand callbacks.  Effectively extending WSDL.

Eric Johnson: Simon N.- only need interface in the WSDL.  Why does it matter that there is no correlation between the callback interface and the service interface in WSDL?

Eric Johnson: Anish- either you "know somehow", or there is something in the WSDL..

Eric Johnson: Simon N- may need to require picking up the phone in order to make this work.

Eric Johnson: Simon H- doesn't the client know it needs to know that it is talking to SCA.

Eric Johnson: Simon N- there is a pattern here - my "SCA product" supports this pattern.

Eric Johnson: Martin C- Thinking of use cases - as server - migrating everything to SCA.  During redeployment so that we start using callbacks, old client is screwed.  Client needs to know that it using clients.  Will need to change the client.

anish: For laughs, here is a pointer to a spec that says how to specify callbacks in WSDL: http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/#declaring-callbacks

Eric Johnson: Mike R.- in order to introduce callbacks to the outside world.... we need to solve both design-time and runtime issues.  Bidirectional interfaces is an SCA thing.  You could advertise this as a BPEL partnerlink.

Eric Johnson: Martin C- but the partnerbinding is going to become an SCA specific thing.

Eric Johnson: Mike R.- just switching BPEL with SCA.

Eric Johnson: Eric J- can we model the req/resp, plus email updates, and model this as a req/resp + callbacks.

Eric Johnson: Mike R.- If this starts out as an application level data, then we probably don't want to extend SCA to deal with application level problems.

Eric Johnson: meeting resumes...

Eric Johnson: Simon N.- Responding to use-case an existing environment that uses "callbacks" with lowercase.  It could be that you could get incredibly lucky, and a client already follows what SCA happens to end up defining.  "If you build it, they will come" - as long as we build a reasonable pattern.  Maybe a small modification to existing patterns that could mate with SCA components.

Eric Johnson: Simon H- like SCA components in other domains.

Eric Johnson: Simon N- yes, should work for both SCA and non-SCA items.

Eric Johnson: Martin C- very much an assembly level discussion.  Notion of partnerlink for this is certainly an assembly level discussion.  Should we replace bidi interfaces with BPEL partnerlink, or also allow?  Then we can return to bindings group to figure out what to do.

Eric Johnson: Mike R.- BPEL spec already says that you can do this with partnerlinks.

Eric Johnson: Martin C- Might be more compelling if it comes from individual from more than one committee.

Eric Johnson: Anish- interface extensibility is specific interface type.  However, assembly changes are for all interfaces.

Eric Johnson: Mike R.- looking at SCA BPEL spec - specifying BPEL partner link, works for specifying an interface.

Eric Johnson: Anish, Martin - Needs to be blessed by assembly, or nobody is going to use it - just a hidden part of BPEL spec.

Eric Johnson: ACTION: Martin to raise an issue with assembly spec - SCA BPEL allows partnerlink types with interfaces.  Need a discussion in the assembly TC.  Should BPEL partnerlinks be first class citizens in assembly.

Eric Johnson: Simon N- Are we looking to defer this pending resolution in assembly?  We can still do binding and Web service resolution here...

Eric Johnson: ... we can resolve what goes on the wire without resolving what goes in the WSDL.

Eric Johnson: Mike R.- supporting callbacks for interdomain use-case. requires runtime and design-time characteristics.  Runtime char.  Incoming request will have a "from" that includes any policy restrictions as part of the EPR, preferrably as part of the advertised capabilities of the service. Reference parameters may also exist on the request.  For callbacks, send the EPR from the from, and also the reference parameters, and follow the policy restrictions in the EPR.

Eric Johnson: Tom R.- is there a way to include policies in the EPR.

Eric Johnson: Anish - yes, but you can put a policy reference.

Eric Johnson: Tom R- but neither wspolicy or wsa has a standard way to do this of including policies in EPR.

Eric Johnson: Ashok- Used two words that we don't formally speak about - advertised policies and capabilities.  Capability is stuff that I can do but not required.

Eric Johnson: Anish- optional and ignorable?

Eric Johnson: Anish- optional is just a short cut for specifying policy alternatives.

Eric Johnson: Mike R.- wspolicy reference would need to refer to a particular alternative

Eric Johnson: Ashok- cannot do this

Eric Johnson: Tom R. No standard way to do this.

Eric Johnson: Mike R.- Advertised - policies attached to WSDL.  In order for this to work, we need to be able to refer to policy alternatives, but if there is no standard way to do this, does this mean that we cannot do this?

Eric Johnson: Anish- or we can include the policy in the message.

Eric Johnson: Mike R- don't want to have to figure out, on a per-message basis, how to resolve among a set of options.  Too complicated requirement.

Eric Johnson: Anish- If you've already pre-fetched the policy, you already know the policy.  Other alternative is to inline.  No standard way to do this, but might be able to do this.

Eric Johnson: ... are we defining a way to do this, and just making it exemplary.

Eric Johnson: ... don't see a lot of value in making it exemplary.

Eric Johnson: Dave B.- we're the wrong body for doing anything other than exemplary.

Eric Johnson: Anish- no chance that WS-Policy would ever take this on.

Eric Johnson: Ashok - tried not to take it on.

Eric Johnson: Simon H- new topic at 1PM.

Eric Johnson: ACTION: Ashok to try to write up a proposal based on discussion and Mike's statement.

Eric Johnson: Anish- what I think of this proposal is related to what we do for identifying the wire in the message.  Want to make this work for both inter and intra domain.

Eric Johnson: Simon N- backwards - focus on inter-domain first, and then figure out what to do.  Could have exemplary suggestions for doing that.  Much less flexibility in the inter-domain case.

Eric Johnson: ... could identify the wire by putting in a reference header in the "from" header.

Eric Johnson: ... we've talked about policy and specification of callback information.  We might make more headway from separating issues, by separating out the policy restrictions.  We'd need a new issue to address the policy questions.

Eric Johnson: ... Motion: "from" reference specifies the callback reference. (exemplary or normative)  Reference parameters in the from header must be returned in any callback.

Eric Johnson: Anish- WSA already says that you have to use the reference parameters.

Eric Johnson: Mike R. seconds the motion.

Eric Johnson: Anish- did you intend to default to replyTo?

Eric Johnson: Simon N. Propose that the sender must specify "from" - receiver must use the "from" information if present.  But use the "replyTo" information if present.

Eric Johnson: [Ed. Ashok's action previously is about policy.]

Eric Johnson: Simon H. - do we have any objection to killing the motion?

Eric Johnson: No objections to killing the motion.

Eric Johnson: ACTION: Simon N. - differently worded proposal for tomorrow.

Michael Rowley: Scribe switch to Michael Rowley

Michael Rowley: TOPIC: JCA Specification Walkthrough

Michael Rowley: Piotr is giving a presentation on the JCA spec, which he will send out later.

Michael Rowley: (The SCA JCA spec that is)

Michael Rowley: NEW ISSUE: When <binding.jca uri="..."> to refer to an existing resource adapter, should we allow an naming context URI to also be specified to identify the JNDI naming context?

Michael Rowley: Michael R: JCA punts on how to specify the Java Objects are mapped to/from bits on the wire, which seems to leave out important use cases.

Michael Rowley: Dave B: The issue is larger than that, as every binding actually needs to have some way to specify these bindings.  Binding.ws specifies JAXB, but JAXB isn't always the right choice.

Michael Rowley: Simon H: Yes, we punted on this in JMS as well.

Michael Rowley: ...except that we have a fairly simplistic default approach.

Michael Rowley: Eric: Why not represent the resource adapter as a component, instead of as a binding?

Michael Rowley: Answer: we have investigated that before, and it is certainly one way of doing it.

Michael Rowley: Should data binding be represented as a component that has business data as input, and some more general data representation (bits or XML) as output?

Michael Rowley: Simon H: We have an agenda item for talking about data bindings tomorrow, so perhaps we can continue this discussion as part of that agenda item.

Michael Rowley: NEW ISSUE: Properties on Bindings

Michael Rowley: ...JCA's concept of creating reusable binding definitions, which define properties that can be given values when the binding definition is reused, should possibly be adopted by other bindings as well (JMS & WS).

Michael Rowley: NEW ISSUE: Data Binding and Operation Selection

Michael Rowley: ...We need a way to identify how the business data is translated into the wire representation of each of the binding types.  We also need to have a way to identify how incoming data is inspected and the operation that is desired is deduced from the incoming request.

Simon Holdsworth: 15 minute break, reconvene at 15:10 Eastern

Simon Holdsworth: reconvening...

michael beisiegel: Simon did I get a checkmark, being present

Michael Rowley: TOPIC: Issue 8

Michael Rowley: TOPIC: Issue 8

Michael Rowley: Michael R: We should make it clear that we are purposely not specifying what the <bindingType> for binding.ws.

Simon Holdsworth: Michael B - yes

Michael Rowley: Rowley motion: The specification should include a statement like the following: "This specification places no requirements on the intents that must be listed as either @alwaysProvides or @mayProvides in the bindingType for binding.ws."

Michael Rowley: Dave B seconds.

anish1: so we have: SOAP over JMS. It is conceivable that someone may do JMS over SOAP (interoperable protocol for JMS). We have SOAP over HTTP. We have HTTP over SOAP (ws-transfer). And then any combination of the above. For example, HTTP over SOAP over HTTP

Michael Rowley: ACTION: Ashok will raise an issue with the Assembly TC that describes the BindingType as something that can be defined by vendors or even by users.

Michael Rowley: NEW ISSUE: What are the requirements for the bindingType for JMS?

Michael Rowley: Motion to replace (Mike R): The specification should require any binding.ws to include the "SOAP" intent either in its @mayProvide or @alwaysProvide list of intents on the bindingType.

Michael Rowley: Dave B seconds.

Michael Rowley: Argument against: the deployer should be able to chose to define the bindingType however they want, possibly even disallowing the use of SOAP with binding.ws (perhaps they really like REST).

Michael Rowley: s/deployer/administrator

Michael Rowley: Vote on the motion to replace: 3 in favor, 6 against

Michael Rowley: Motion to replace fails.

Michael Rowley: Vote on the main motion: The specification should include a statement like the following: "This specification places no requirements on the intents that must be listed as either @alwaysProvides or @mayProvides in the bindingType for binding.ws."

Michael Rowley: Vote on the main motion: Resolve issue 8 where the specification should include a statement like the following: "This specification places no requirements on the intents that must be listed as either @alwaysProvides or @mayProvides in the bindingType for binding.ws."

Michael Rowley: Motion passes without objection.

Michael Rowley: Dinner:

Michael Rowley: http://maps.google.com/maps?f=l&hl=en&geocode=&q=macaroni+grill&near=90+North+St,+Lexington,+MA+02420&sll=42.466605,-71.215004&sspn=1.410155,2.268677&ie=UTF8&cd=1&ll=42.486023,-71.200333&spn=0.176214,0.283585&z=12&iwloc=A

Simon Holdsworth1: Recess

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]