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: Today's notes

Simon Holdsworth: Audio conference: 

Please note that the audio conference provided on a best effort basis depending on the equipment available. You are encouraged to attend in person if possible. 

Meeting Number: * 913929 * (press * before and after the digits) 

Phone numbers: 

Austria = Vienna 026822056419 
Belgium = Brussels 022901709 
China Toll Free = China North 108007121722, China South 108001201722 
Denmark = Copenhagen 32714982 
France = Paris 0170994364, Lyon 0426840196, Marseilles 0488915310 
Germany = Berlin 030726167296, Frankfurt 069710445413, Hamburg 040809020620, Munich 089244432767, Stuttgart 0711490813212, Dusseldorf 021154073845 
India Toll Free = 0008001006703 
Ireland = Dublin 014367612 
Italy = Milan 0230413007, Rome 06452108288, Turin 01121792100 
Japan = Tokyo 0357675037 
Netherlands = Amsterdam 0207965349 
Portugal = Lisbon 211200415 
Russia Toll Free = 81080022074011 
Spain = Barcelona: 934923140, Madrid: 917889793 
Sweden = Stockholm 0850520404 
Switzerland = Geneva 0225927186 
UK Toll Free = 08003581667 
UK Toll = London 02071542988, Manchester 01612500379, Birmingham 01212604587 
USA Toll Free = 18665289390 
USA Toll = 19543344789
Simon Holdsworth: Agenda
Simon Holdsworth: 9:00 - 9:30: Setup 

Roll call 
Assign scribes 
Review agenda 

9:30 - 10:30: TC Schedule, Committee Drafts 

What remains to be done to get specs ready for first CD? 
Target for first CD completion 
Schedule for overall spec completion 

10:30 - 10:45: Break 

10:45 - 12:00: Web Services, WSDL, SOAP issues 

Some underlying agreements needed in this area: 
Conformance statement for support of bare element (logically or physically unadorned?) 
Which instances of does the WSDL generation apply, and MUST or SHOULD; 
Does soap.1_1 mean "only" or "at least"; 

"Formal" WSDL generation is unclear, ambiguous, and incomplete 
Raiser: Eric Johnson, owner: Eric Johnson, Anish Karmarkar 
Status: Updated proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00004.html 

Is it required that every implementation of binding.ws support the soap intent? 
Raiser: Anish Karmarkar 
Status: No current proposal. Latest email: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00006.html 

12:00 - 13:00: Lunch 

13:00 - 15:00: Web Services Issues contd. 

@wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs 
Raiser: Eric Johnson 
Status: Specific resolution text required 

15:00 - 15:30: Break 

15:30 - 17:00: Misc. Issues 

Which wire did a message arrive on? 
Raiser: Sanjay Patil 
Status: No proposed resolution 

Document the attributes inherited from the base definition provided by SCA Assembly specification 
Raiser: Eric Johnson 
Status: Proposed resolution in issue 

Allow topics anywhere that queues can be used 
Raiser: Eric Johnson, owner: Simon Holdsworth 
Status: Specific resolution text required 

17:00 - 17:15: Summary
anonymous morphed into anish
Martin C: Topic: Agenda
Martin C: thursday lunch 12-1
Martin C: Friday start: 8:30
Martin C: Friday lunch: 11:45 - 12:30
Martin C: Agenda approved with addition of minutes approval of last meeting
Martin C: Topic: Roll
Martin C: Meeting is quorate
Martin C: Topic: approval of minutes
Martin C: Minutes 10 July.
Martin C: Minutes approved w/o
Martin C: Topic: TC Schedule, Committee Drafts
Martin C: Simon: assesment so far, can get WS issues resolved by september
Martin C: Simon: callback may take some time
Martin C: Martin: looks like its possible to do a public review
Martin C: Simon: do a cd asap not subject to all resolutions, to get wider visibility
Martin C: (above Simon means Simon H)
Martin C: Mike E: in preparing CD should set some specific wording
Martin C: Mike E: RFC2119 wording would be a good goal for a cd
Martin C: Anish: BPEL TC given a section to an editor to propose a portion, then get TC approval to move forward
Martin C: Eric: release early and release often
Martin C: Eric: do a snapshot now
Martin C: Martin: agree to eric, and notes that we don't have to publish to docs
Martin C: Simon: what about namespaces?
Martin C: Anish: a cd can update them
Martin C: Anish: at end of meeting, ask editors when they can excute a new draft based on meeting resolutions
Martin C: and existing resolutions
Martin C: Anish: cd ready for approval at the meeting on 14th August, draft available on 7th August
Martin C: Eric: is this for all three specs?
Martin C: Anish: Yes
Martin C: Anish Motions: Instruct the editors to produce CD Drafts of WS, JMS and JCA, folding in as many resolutions as possible. Drafts to be available by COB 7th August for a potential vote on 14th August.
Martin C: Martin 2nds
Martin C: Note: we have already agreed, via the Liaison TC is the PDF is authortativ
Martin C: s/tiv/tive
Martin C: Motion passes w/o
Martin C: All change bars should remain inforce until a CD is agreed
Martin C: Anish: editors should produce both change bar and no change bar versions
Martin C: Martin: dissagree as too much work, just produce change bar versions in word/pdf and when accepted as cd they are removed
Martin C: Simon H: Just prodcude change bar versions, and switch off when approved
Martin C: Anish: SCA J TC agreed that after 15th september, new issues after that require a 2/3 majority
Martin C: Anish: the same rule as re-openning an issue
Martin C: Anish: raises the bar to try and stop feature creep
Martin C: Eric: won't RFC2219 re-write create new issues
Martin C: So 15th sept might be premature
Martin C: Eric: prioritoze the RFC 2129 re-wording after first CD
Martin C: Eric: with a deadline of 15th September
Martin C: ACTION: Editors produce a revision of the forthcoming CD to include RFC2219 re-writting by Sept 15th 08
Martin C: s/2219/2119/
Martin C: default assumtion is for all three specs
Martin C: s/assum/assump/
Martin C: Simon: do we want to formalize a date for a higher bar for issues
Martin C: Martin Motions: New issues received on the mailingg list after noon GMT 18th Ocotober can only be openned using the same voting rules as re-opening a closed issue (2/3 majority of a full TC vote)
Martin C: Mike E nds
Martin C: s/nds/2nds/
Martin C: Eric: move to ammend to make it explicit it is a proposed standing rule
Martin C: anish 2nds ammendment
Martin C: ammendment passes w/o
Martin C: Motion: add a new standing rule to the TC that states New issues received on the mailingg list after noon GMT 18th Ocotober can only be openned using the same voting rules as re-opening a closed issue (2/3 majority of a full TC vote)
Martin C: Full Mojority vote for a standing rule, no objections or abstains, there motion passes w/0
Martin C: s/0/o/
Martin C: General greement that we should aim for 1st public review by end of year 2008
Martin C: s/gree/agree/
Martin C: Topic: WS bindings issues
Martin C: Bindings-11 and Bindings-25
Martin C: during discussion some underlying issues surfaced
Martin C: debate about wsdl generation rules and how affects interop and conformance
Martin C: is there a default without expressing any intents?
Martin C: the problem is even with soap it may be over many transports, so why mandate a particular one
Martin C: what is the differnce between a profile of a ws binding and a specfic binding
Martin C: current bindings.ws is maybe far too configurable
Martin C: do we need a subset that is less configurable, and what goal would this be addressing (e.g. interop)
Martin C: discussion on whether a subset would aim at interop or portability
Martin C: portability would imply sca runtimes support the "same" stack
Simon Holdsworth: ----------------------------------
Simon Holdsworth: Break for lunch
Simon Holdsworth: ----------------------------------
Bryan Aupperle: Are you back yet?
Eric Johnson: Not quite yet...
Eric Johnson: Resuming....
Eric Johnson: (I'm scribe now)
Eric Johnson: Simon put the use cases on the white board to discuss.
Eric Johnson: #1) reference + WSDL for existing service
 a) resolve to specific binding
 b) generic binding
Eric Johnson: #2) service, expose aas web service, no specific requirements (assuming acceptable defaults)
Eric Johnson: #3) service, expose as a web service with specific requirements expressed as WSDL binding
Eric Johnson: #4) reference wired to service, specific requirements expressed as WSDL binding.
Eric Johnson: (white board edit #1) reference + WSDL for existing service
 a) resolve to specific SCA binding
 b) generic SCA binding - point at the WSDL.
Eric Johnson: Discussing #1...
Eric Johnson: Does the WSDL completely describe the service?  Could intents influence choice of port in the WSDL?
Eric Johnson: Anish: yes & yes.
Eric Johnson: Anish: If the WSDL doesn't completely describe the service, then we add details on the reference side....
Eric Johnson: Nimish: WS-Policy - I might need to apply at the reference - but we should be able to fit this into the WSDL?
Eric Johnson: Mike E.: Might not be in the WSDL, because it is policy dictated externally.
Eric Johnson: Eric/Simon - #1a addressing the notion that to satisfy the need to invoke the service described by WSDL, but map to a specific SCA binding that corresponds to the WSDL binding.
Eric Johnson: (Simon H. in the last one)
Eric Johnson: Now discussing #2 - we define the defaults...
Eric Johnson: Vladimir - note that JAX-WS annotations dictate rules to generate WSDL portType.  JAX-WS annotations may influence binding generation.
Eric Johnson: Martin: Maybe we should do the same thing as JAX-WS.
Eric Johnson: Vladimir: can dictate use of things like MTOM which affect the binding.
Eric Johnson: Mike: Not desirable for those annotations to force the use of web services.
Eric Johnson: Vladimir: perhaps we need to revisit WSDL to Java, Java to WSDL...
Eric Johnson: Mike: agree it sweeps too much under the carpet.
Eric Johnson: Discussing #3
Eric Johnson: Vladimir: This use case is the "top-down" case.
Eric Johnson: Mike: The trouble with this approach is that it might burn policy decisions in too early.
Eric Johnson: Anish: WS-Policy defines policy "subjects". They can act like abstract policies like SCA's policy intent.
Eric Johnson: Vladimir: For example, "reliable messaging"
Eric Johnson: Nimish: Reliable messaging is a function of the endpoint.
Eric Johnson: Discussing #4
Eric Johnson: Simon H: Have specific requirements about the interaction....
Eric Johnson: Vladimir: I have a reference, and it needs to use https & certificate - know I'm a client...
Eric Johnson: Simon H: those sort of requirements would be better expressed as policy.
Eric Johnson: Simon H: (WSDL binding is associated with the service binding)
Eric Johnson: Anish, Eric, Simon H: We need to resolve whether the implementation of use cases #3 & #4 are different.
Eric Johnson: Simon H: Is this the complete set?  How do these get expressed as bindings?
Eric Johnson: Anish: The difference between #2 & #3 is just whether you point at WSDL? (Yes).
Eric Johnson: Anish: First thing we should resolve - one binding or two bindings - conformance points.  Focus on the defaults later.
Eric Johnson: ... what do we want to see here?  Are intents enough?  All sorts of questions here....
Eric Johnson: Simon H: We haven't discussed how intents might affect cases other than #1.
Eric Johnson: Simon N: It is bizarre that JAX-WS includes annotations that affect binding that aren't supported by other languages.
Eric Johnson: Anish: An unfortunate part of WSDL 1.1 is that your portType can define input and output messages, and when you bind it, there are no constraints about which parts get serialized.
anonymous morphed into anish
Eric Johnson: Nimish: We can preserve the purity of SCA, and keep the interfaces separate from the bindings.  JAX-WS annotations about bindings are pollution.
Eric Johnson: Simon N: The Java spec should say that.
Eric Johnson: Vladimir: Does this mean that you revert to the JAX-WS defaults.  That might not work.
Eric Johnson: ... With JAX-WS, generating a WSDL will create both a portType and a binding.
Eric Johnson: ... Without the binding part, you cannot keep these two pieces together.
Eric Johnson: Simon N: When you're thinking about a Java interface.  Can you wire two interfaces that declare different JAX-WS bindings like doc lit & rpc. lit.  This ought to work in Java, but it does mean that we need to override the binding information from the annotations.
Eric Johnson: Simon N: Mapping from Java interface to portType and Java interface to binding should be considered separately.
Eric Johnson: Vladimir: I cannot image how it can be defined.
Eric Johnson: Case #1) binding refers to a WSDL port or service.
Eric Johnson: Case #2) Does not refer to WSDL
Eric Johnson: Case #3) binding refers to WSDL binding.
Eric Johnson: Case #4) binding refers to WSDL binding.
Eric Johnson: (For #4 - sca binding on the service)
Eric Johnson: Eric: Adding a use case #5 - reference wired to a service with a web service binding, but no specific WSDL binding requirement.
Eric Johnson: Simon H: (writing on whiteboard)
Eric Johnson: Syntax for #1) <binding.1 wsdl="(port|service)" requires="  "? ...>
Eric Johnson: #2) <binding.2 requires="  "? ...>
Eric Johnson: #3) <binding.3 wsdl="(binding|service)" requires="  "? ...>
Eric Johnson: #4) <binding.4 wsdl="(binding|service)" requires="  "? ...>
Eric Johnson: #5) <binding.5 requires="..."? />
Eric Johnson: Simon N: Policy constraints could narrow the choices.
Eric Johnson: Martin: No, this is really "override."
Eric Johnson: Martin: If you're not allowing anything other than soap for binding.2, then it is really just "binding.soap"
Eric Johnson: Nimish: Is there any case where we're using policies for override instead of constraint?
Eric Johnson: Simon H: Do we want a complete set of defaults?
Eric Johnson: Anish: World divides into SOAP/HTTP, SOAP/everything else, WSDL for everything else.
Eric Johnson: Mike & Anish: Anyone wanting to use REST would not want to use WSDL.
Eric Johnson: Anish: Eric's opinion is that lets address SOAP/HTTP - and nothing else.
Eric Johnson: Eric: For the case of non SOAP referring to WSDL, this is a useful syntactic standard for portability among vendors.
Eric Johnson: Anish: WSDL has capability to express a lot of options.
Eric Johnson: ... which are we focusing on>
Eric Johnson: ?
Eric Johnson: Simon H: Can we define one binding that deals with entire realm of WSDL.
Eric Johnson: Simon H: If we have separate binding elements for SOAP/HTTP with WSDL and one without WSDL, what problems do we run into?
Eric Johnson: <<too much discussion that I didn't keep up with>>
Eric Johnson: Five options for ranges of bindings on the whiteboard:
binding.soaphttp + binding.wsdl
Eric Johnson: binding.soaphttp + binding.wsdlnotsoaphttp
binding.soap + binding.notsoap
binding.wsdl + binding.soaphttp (no wsdl element)
Eric Johnson: Straw poll - which of the above.
Eric Johnson: Simon H: describing each:
Eric Johnson: soap/http binding specific to that, and a binding.wsdl that allows us to do anything WSDL.
Eric Johnson: 2 - binding.soaphttp + binding.wsdlnotsoaphttp - same as above, but not overlapping.
Eric Johnson: Straw poll results:  2 votes for binding.soaphttp + binding.wsdl
2 votes for binding.soaphttp + binding.wsdlnotsoaphttp
5 votes for binding.ws
Eric Johnson: Martin: who objects to separating out SOAP/HTTP binding?
Eric Johnson: OK: 8
Object: 2
Eric Johnson: Anish: All in one binding - who's OK & objects?
Eric Johnson: OK: 6
Object: 4
Eric Johnson: Mike E: Observe that we are not expecting that people will using binding.ws to subsume or eliminate the need for binding.jms.
anish: Motion: we have binding.ws that has a wsdlElement attribute that allows one to point to any wsdl port/service/binding. We allow binding.ws to not have the wsdlElement attribute. For that case we define default for when soap 1.1 intent is specified. We also define default for when soap 1.2 intent is specified. And we also define defaults for when none of those 2 intents are defined.
Eric Johnson: Seconded by Simon N.
Eric Johnson: Martin: Defaults for what?
Eric Johnson: Anish: This does not resolve the conformance requirements.
Eric Johnson: Simon N. this effectively resolves issue 25....
Eric Johnson: Martin: Motion does not suggest resolving issue.
anish: amendment: to add: this resolves issue 25. the defaults for soap 1.1 intent is soap 1.1 over http doc/lit, ws_i bp 1.1 compliant. The default for soap 1.2 intent is soap 1.2 over http doc/lit, ws-i bp 2.0 complaint. The default when neither soap 1.1 or soap 1.2 intent is specified is soap .1.1 over http doc/lit, ws-i bp 1.1 compliant.
Eric Johnson: Simon N seconds
Eric Johnson: Vladimir: If you're using JAX-WS with interface.java - this will conflict.
Eric Johnson: Anish: The way he reads it, depending on which style you choose, it will dictate the binding.
Eric Johnson: Eric: Move to limit the discussion to ten minutes
Eric Johnson: Martin: seconded.
Eric Johnson: Nimish: This proposal doesn't take into account the issues from Eric's proposal for default binding/ WSDL generation.
With JAX-WS in the picture, some of this information might be derived.
Eric Johnson: Anish: Criticism is valid.  What he's trying to do is have a motion to have an SCA binding for a WSDL that do whatever it wants.  Don't think this is fully spec'd out.
Eric Johnson: Simon N: Responding to Eric - yes it resolves issue 25, but goes further.
Eric Johnson: Eric: No it doesn't resolve the issue 25, the wording is different than the issue.
Eric Johnson: Mike E: Call the question
Eric Johnson: No objections
Eric Johnson: Vote on amendment:
Eric Johnson: Only one objection, amendment voted down.
Eric Johnson: Anish: Wanting to keep binding.ws the way it is.  Motion will effect that binding.ws is not about soap.
Eric Johnson: Martin: Call the question.
Eric Johnson: Objections to unanimous consent.
Eric Johnson: Vote: in favor 5, 3 against.
Eric Johnson: Motion is passed.
Eric Johnson: Action to Anish - revise proposal from Eric.
Eric Johnson: Pointer to WSDL generation proposal last submitted by Eric: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00004.html
Eric Johnson: Discussion on issue 24
Eric Johnson: Simon N: Binding needs to carry information about this information for Java services to get the information they need.
Eric Johnson: Anish: WS-ReliableMessaging.  Service that says it supports "reliable messaging".  Now suppose A & B want to talk to this service, and A requires reliable messaging, does B need to use it?
Eric Johnson: ... How can a service know which privacy policy actually gets chosen?
Eric Johnson: Simon H: How does the runtime know which wire the message came on, in order to know how to respond?
Eric Johnson: Nimish: Two cases - addressing defines cases.  Attribute is dictating the alternatives....
Eric Johnson: Anish: If it is clear from the message which alternative has been picked by the client, then it is an open problem.
Eric Johnson: Ashok: You're looking from the policy point of view.
Eric Johnson: Simon H: No point to discuss this further here.  Need to go back to Sanjay.
Eric Johnson: ... we need an example that shows this problem.
Eric Johnson: Mike: If it is the infrastructure, then it has enough information, but if the infrastructure doesn't know, how can it know?
Eric Johnson: Simon H: But if there is information that we could stuff into the message to disambiguate, maybe we do that?
Eric Johnson: Action: Sanjay needs to provide examples for issue 24.
Eric Johnson: Discussion: Issue 32
Eric Johnson: Action item: Eric to come up with a precise proposal for resolving this issue.
Eric Johnson: Discussion issue 35
Eric Johnson: Revised Proposal: Allow topics to be used with request/response destinations.  Note that in a request/response exchange, the binding must only deliver one response.  Rename scaCallbackQueue to scaCallbackDestination.
Eric Johnson: Mike E: Move to resolve issue 35 with the text in the chat room.
Eric Johnson: Martin: seconds.
Eric Johnson: No objections to unanimous consent.  Motion passed.

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