[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, 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 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: Simon
Holdsworth1: Recess |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]