See also: IRC log
<Marsh> Introductions
<Marsh> We go around the room
<plh-wsaddr> Scribe: GlenD
David gets "volunteered" as our first Scribing Victim
(logistics discussion)
Agenda Review
<plh-wsaddr> Absent: Harris
Hugo steps resolutely to the front of the room, pulls out his +5 Vorpal Laptop, and proceeds to give a presentation
<plh-wsaddr> Presentation at http://www.w3.org/2004/Talks/1025-hh-p/
Jonathan: Mark, are you also representing BEA on this group?
Mark: I'd hesitate to represent BEA and would rather stay neutral since we're on a tight schedule. Will make technical commentary at times, but leave representing BEA to David.
Input comes from variety of places (as per presentation)
Jonathan describes WS Coordination Group
Mark: What does it mean to "refine" the spec?
Bob: OED says basically every option short of recreating every
molecule....
Bob: Hope is that we can start with this raw material and shift it into
a direction that works for us. Hopefully we can have a mature attitude
towards how much we can do to it - should be open to good tech
discussion, but in the spirit of getting it done quickly.
Mark: My reading is that it's the starting point. We can't say refine
means you can't change it... we've already got specific issues, so it
seems like we're in agreement there. On the other hand, we're on a
tight schedule so we can't refine forever.
Mark: "comment and review"...how about that in terms of meaning?
Hugo: WS-MD has some different solutions. If there are things that are
in-scope that MD does differently/better than WSA, then we should
address the issue.
Mark: +1. MD is a significant source of use-cases and issues. It
informs us, but we don't simply choose between the two - we start with
WSA.
Discussion of deliverable scoping
Jeff: How abstract is this supposed to be? Has to assume some
addressing model (URLs, TCP/IP...), right?
Mark: This is pretty much a bag for anything above SOAP/WSDL.
Anish: Abstract refers to message properties, not EPR, right? EPR is
syntax...
Mark and Gudge : EPR is abstract
systinet: How do we talk about compliance to abstract spec?
Mark: Good question. We'll talk about this tomorrow when we discuss how
to go from here to there (get the spec to rec).
Anish: separate out SOAP 1.2 and SOAP 1.1 bindings?
Mark: That brings out another issue. It's not common W3C policy to talk
about non-W3C specifications/recs....
Philippe: SOAP 1.1 is already normatively referred to in SKMS. As long
as it's optional, it's OK to have these things in W3C recommendations.
Discussion of what's out of scope, including how to coordinate with
external groups which are working on things like new MEPs, callback, etc
Marc: Are we going to explicitly design extensibility for this stuff, or
just assume it'll work?
Paco: Definitely shouldn't be a closed set of MEPs...
Marc: Typically there are explicit extensibility methods built into a
spec...
Gudge: Addressing has implicit extensibility, since it's build on SOAP
Marc: That only applies to SOAP binding
Jeff: Where are these MEPs defined?
Various: WSDL...
Jeff: OK, if we agree that certain MEPs are out there and reasonable,
and we can't do them, that's the time we need to make changes.
(general nodding of heads)
"The Scary Slide" - Schedule
David: Have seen schedules slip before, but perhaps this time since we
have so much previous interop work, that can help us.
Mark boldly cuts off the schedule discussion, and suggests we simply
suspend disbelief for now and work towards the schedule we have in front
of us.
Jonathan: The editor's copies will be available on the web, right?
(nodding)
Jeff: First public WD is a good thing because of patent policy, in
addition to other reasons. We should do one before LC.
Jonathan: Maybe let's do that immediately? Change namespace, get it in
XML, etc...
(Dave makes fabulous joke)
<scribe> ACTION: Hugo to research patent implications of publishing first WD
Mark: proposed first task is to take WSA and split it into three specs.
Will discuss that in broadest possible terms here, then instruct the
editors to go ahead.
Mark: Editors should do split, then we should publish initial drafts.
OK?
(nodding heads)
(brief discussion on good standing - is it OK to attend f2f's by phone?
consensus is yes)
(discussion of security in the abstract spec)
(discussion of SOAP binding - "how to stick properties into a
SOAP: Envelope" and SOAP faults)
(discussion of WSDL binding)
Mark: Is that enough for now?
Jeff: Is it obvious to everyone which pieces of WSA go where?
Mark: That's something we should let the editors try.
Gudge: Already taken a first stab at which sections go where. Will mail
it out as soon as the network works....
BREAK
See slides.
Marc: What's the relationship between the address, the sub-address, and
the architecture of the WWW?
Gudge: All will be made clear in a few slides...
Discussion of endpoints, ref props
Address URI always gets you to a transport listener somewhere.
Refprops/params always do dispatch within that (and do not relate to the
transport)
Anish: is order of refprops/params significant?
Gudge: nope
Discussion of the fact that wsa:Address URIs don't necessarily map
directly to network addresses
Marc: Can't have this be vague - if I see an EPR with an Address, I
should be able to go to it without knowing anything extra about lookup
repositories, etc.
Glen: This isn't really germaine, since the spec doesn't say anything
about it and it's also true for browsers/etc....
Anish: Relationship between URI in address field and URI in WSDL
port/endpoint?
Gudge: we need to define that. In our experience it's the same.
Marc: are ref props/params relatively static?
Gudge: params are dynamic, props are static... could argue it ether way
though
Anish: Why isn't the To header an EPR?
Gudge: Because we wanted to leverage the SOAP processing model to
process RefProps
Anish: In an EPR you can have service/port qnames. Wouldn't it be
better to have To be an EPR so this stuff can be conveyed to the
listener?
Paco: EPR is a package for runtime info. Different from actual usage...
Gudge: Anish, are you looking for additional headers for service/port?
Anish: We need to decide how that might work, but maybe.
jonathan: Coudn't you use refP's for this?
Anish: Yes, but you're duplicating a separate (in the EPR) concept
Marc: What's the processing model of the To header?
Gudge: Almost like URL's and Host: header in HTTP. Software checks the
To against some concept of "me".
Jonathan: Redundant info for detecting errors
Marc: is this meant for the "next" role, or really at the ultimate
receiver? Should SOAP intermediaries be able to see this?
ISSUE: Marc: It's an issue that wsa:To must be there if it might be
duplicate information....
Anish: You could compose a lot of info into the URI (service/port/etc)
Gudge: Yes, but there's no fixed line which says "this stuff goes in the
To, this stuff is ref props"
Anish: Sender generally decides on mustUnderstand/role/etc for
headers... how does he decide for ref props?
Gudge: He doesn't - if they're there, they must be parroted exactly,
including attributes like MU/role
ISSUE: Glen: RefP's explicitly use the SOAP processing model, and force
senders to send 1st class SOAP headers they don't understand. This
could cause problems - why not solve this by just having <To> be an EPR
which reflects the RefPs, instead of sending RefPs as headers?
Gudge: Because you'd need to reproduce the SOAP processing model incl
role/MU/etc
Glen: I don't see why that would be the case. I'd like to see some
cases that prove that assertion
Anish: +1
(discussion of using ref props which overload WS-Security, etc)
(discussion of sending updated EPRs)
Marc: This seems like it might warrant a standard "continueTo" header,
or "redirectTo"...
Gudge: PortType might change - for instance, transaction might give you
back an EPR to a different PortType with commit/rollback....
Marc: Transaction is only one usage...
Rebecca: How do I know how to construct a message for the new endpoint?
Gudge: If they're the same (differing only in refparams), you send the
same msgs as the original endpoint. Otherwise, it's
application-specific... you get WSDL hints.
(discussion of using WSDL <service> as EPR)
(discussion of using <replyTo> to implement WSDL inout)
Anish: Seems like we should have a constraint that says ReplyTo
shouldn't violate the WSDL binding.... (shouldn't send response over
SMTP for an HTTP request if WSDL says SOAP-over-HTTP)
Gudge: Yes, but I'm not sure what that would look like.
(anonymous address URIs)
Marc: Why not just omit the address instead of using a special anonymous
one?
Gudge: That might work....
END PRESENTATION
LUNCH
Anish will present WS-MD, focussing on some of the differences between WS-MD and WS-A.
<dorchard> I did a comparison at http://www.pacificspirit.com/blog/2004/07/29/ws-addressing%20ws-messagedelivery%20comparison
Anish: Four parts to WS-MD.
- WSRef
- Abstract Message Delivery Properties
- Mapping of abstract properties to WSDL 1.1/2.0 MEPs
- Composite MEPs. Combining WSDL MEPs to build higher-level patterns, including callback pattern (out of scope in the WS-A charter.
scribe: WSRef determines where to send the
message, what messages can be sent, and how to send the message (binding)
... Reuses syntax defined in WSDL 2.0/1.1, backporting WSDL 2.0 service
reference concepts to WSDL 1.1.
... Doesn't invent new stuff, just reuses whats in WSDL.
... Rationale is that written code can be repurposed.
... Abstract Message Delivery Properties enable message to be delivered to
the right place, enabling correlation within an MEP.
... Seven properties: MessageOriginator, MessageDestination,
ReplyDestination, FaultDestination, MessageID, MessageReference,
OperationName
... The mapping of AMDP to SOAP is simple - each property maps to a header
block. Not opaque, you can stick in mustUnderstand, reinsert.
... The mapping of AMDP to WSDL MEPs says what properties must be present for
each message participating in a MEP.
... Callback pattern is an example of a composite MEP. It implements the
WS-I Basic callback scenario, which correlates two 'in-out' MEPs or two 'in'
MEPs.
... You can figure out how two separate WSDL operations are correlated.
... Similarities between WS-MD, WS-A. Intention is very close. Both define
a way to reference an endpoint. Both define Message Information
Headers/Abstract Message Delivery Properties.
... 6 of the 7 properties do essentially the same thing.
... OperationName is sort of similar to wsa:Action.
... you can have the same Action value for two different operations.
OperationName is required to be unique.
... Biggest difference is between EPR and WSRef. They do things in quite a
different way.
... The obvious difference is that EPR has a WS-Policy element. WSRef allows
you to put in whatever WSDL allows you to put in.
... EPR allows you to specify additional information that must be sent with a
message. WS-MD relies on WSDL to provide sufficient information to talk to a
service.
Paco: If you were doing sessions or something
stateful, would you regenerate the WSDL>
... Some stuff that differentiates my interaction from someone elses, I'd add
some more information to the existing WSDL?
Anish: You may, or you might have a spec for contextualization of interactions.
Paco: Would that show in the service reference or not?
Anish: If it's coming back to the same service,
you don't need to generate a new service element.
... You could generate a separate service for each interaction, but that
would be difficult.
... Various use cases - could be completely dynamic, sender doesn't know what
is coming back in the service element, or it may expect something.
... WSRef is the minimal thing you would need to reference a Web service.
Doesn't allow you to package in additional parameters or properties.
... That doesn't keep you from building params/props at the application
layer.
Greg: Now you've pushed that complexity to the application level, and complicated the programming model there.
Anish: That reflects the different points of
view of the two specs.
... You could write another spec (see WS-RF at OASIS) to build a layered
architecture on this.
... Those who don't need more complex stuff can use this.
DaveO: Cookies are a good analogy. Web site
might want cookies, browser might not support them. There is a separation
between URIs and cookies, same in WS-A between Ref Props and URI.
... It is layered in EPR in a similar way as in the Web architecture.
Marc: Is the expectation that if I don't use Ref Props/Params I will get a lower level of service>?
DaveO: You might provide a fallback. I don't think you would. I think you will require Props/Params in order to enable the full quality interaction.
Marc: Is support for Props/Params a conformance requirement?
Anish: Set Cookie and Cookie Header is a separate spec. Can be the same in addressing.
Paco: Many people made an assumption that WS-A is making contextualized URIs, the Cookie analogy shows that this is information you wouldn't provide iin the URI.
DaveO: Many applications take advantage of cookies for good reasons (sometimes bad). Site authors have the choice of using URIs, or URIs + cookies.
Anish: But the specs are independent.
... At one level EPR allows you to do things very simply, only mandatory
thing is the Address.
... The WS-MD approach is that in order to communicate with a Web Service you
need a whole lot more information than just the URL.
... Maybe there's already metadata available through some other means.
... If there's more information you need, the addressing spec should provide
you a way to get it.
... If a service already has the information, great. If not, you should be
able to go get it.
Rebecca: Need to include that information.
Philippe: Or provide a query mechanism.
Jeff: Query is inefficient.
Anish: Several approaches to get metadata -
WS-MD takes one. You can go fetch the data.
... MEX defines some operations. Maybe that's another way.
<RebeccaB> Need to include that information in dynamic EPRs or additional roundtrips required
Anish: Another big difference. Porttype name
is optional in WS-A. You might not be able to do anything with it.
... You might have to query UDDI or something.
Paco: There are two different viewpoints, loosely coupled or allowing tightly coupled. Do we want everyone to pay the price for loose coupling.
Anish: WS-A defines some specific faults (WS-MD
does not), which appears to be a good thing,
... WS-MD specifies MEP mappings.
... WS-MD has callbacks - we should keep in mind that we don't preclude
someone from using WS-A to define composite MEPs.
... Summary:
... Substantial similarities.
... EPRs and WSRefs come from two different places. WSRef is a reference to
a _service_, EPR is a reference to an _enpoint_.
Rebecca: Given thought to other patterns such as high-availability; mulitple services behind a single endpoint?
Anish: Yes, but it's questionable as to whether
this should be exposed to the client.
... A session ID could tell where to go, or a service group could be exposed
to the consumer.
... We should explore whether this mechanism needs to be within Addressing or
built on top of it.
Jonathan: Worried about believing WSDL is sufficient for an interaction. Semantics is missing.
Glen: Might have a prequalified set of WSDLs.
Jeff: You need to distinguish between the
business and trust issues from the infrastructure issues.
... Semantic issue is kind of a red herring to this WG. It's not a solvable
problem today.
... The dynamic case, once you've established the business and legal issues,
is still interesting.
Rebecca: You might get back several choices,
e.g. bindings, which you can choose from. There might be alternatives within
the infrastructure part.
... Some might require multiple ports in a single reference. Talking to MQ
takes multiple URIs.
... You can model it in WSDL but not in WS-A.
Paco: Why not?
Marc: Set your endpoint reference address to "anonymous" and include the portType and service.
[apologizes for not understanding this scenario and botching the minutes on it.]
Marc: Both have the same capabilities but they come from different viewpoints?
Anish: In terms of referencing a service they have the same capabilities.
Paco: In WS-MD you have a WSDL service element you restrict to a single port.
Anish: WSDL 2.0 there is no restriction. In WSDL 1.1 every port in that service must support the same portTYpe.
Paco: So the intention is that WS-MD can support more than one port.
MarkN: We have an issues list, we'll start populating it tomorrow. I'll maintain it for now.
MarkN: Let's continue some of the use cases
we've touched on earlier.
... Paco suggests we have different assumptions about URIs, which we'll talk
about tomorrow.
... Can we talk now about what other people want out of WS-Addressing -
lightweight? full-featured?
... From WS-A, it purports
"to identify Web service endpoints",
Paco: An example which may shed some light.
... BPEL life cycle model - you're going to interact with a long-running
stateful interaction.
... typically you don't have a factory method, you just send a message and a
business process interaction is spawned.
... From the BPEL process perspective, you spawn a process, how are you going
to make sure the messages reach the right places?
... BPEL uses application data (correlation sets) to route messages.
... It would be better to have a solution that could be managed by the
infrastructure, instead of the applciation, but supports the same model.
... For example, you may have a message that returns a customer number or
some other important data. It would be nice to carry this in an EPR.
... Without the ability to qualify your reference you lose the context of the
specific conversation.
... This is a very general, protocol-independent, mechanism that supports
long-running conversations.
Rebecca: Sounds like your sending context information.
Greg: Could be context or something.
Glen: What do you mean by context? Something specific or general?
Paco: The example is that of a long-running conversation, which may have specific transaction contexts within it.
Glen: But the conversation itself has a long-running context.
MarkN: Can you see a service and a service instance having a different address?
Paco: Could be but...
Anish: Are you talking about a factory pattern?
Paco: No, explicitly no factory. There is no explicit instantiation mechanism.
Anish: What is the difference between service and service instance?
Paco: They share the front end. They share a WSDL definition, they may have different cookies.
Anish: If I have a service, I can send messages to that service. One of the fields might be a customer ID, going to the same service.
Paco: Then the application has to take care of it, which is fine, but we also want to allow the infrastructure to deliver the message correctly.
[Some discussion about terminology of "service" and "service instance" as relates to scoping of interactions.]
Paco: This is a use case, this is one pattern of use that we should support.
Anish: As long as you don't call it an instance of the service.
Paco: Use case has the same address, same service, same portType, same port, possibly different endpoint references.
Jeff: Do I have two instances of a service? Or one?
Glen: Mu, grasshopper.
Paco: In BPEL you'd say you have the same service.
Jeff: What's the identity model?
Paco: In BPEL, each instance is identified by a correlation set - a set of properties that are unique to that conversation.
David: You call those BPEL process instance.
... You can define in BPEL a service, you get a process instance when you
get a correlation set.
Marc: Struggling with the difference between
ref props and ref params. Sounds like we're talking sessions here.
... Are different sessions different ref props or ref params.
Gudge: Depends on whether you want to change the metadata or not.
Paco: you have the same address, and
properties, you have the same portType.
... I'd typically use a ref property.
Gudge: Can't draw a line saying precisely which things should be params & props.
Anish: Can you have 2 EPRs with the same wsa:Address, same ref props but different porttype? The spec doesn't seem to restrict this.
Gudge: I'd say yes, but only if that endpoint accepts both sets of messages (portType A union portType B).
Anish: So if address is mapped, could it not be mapped differently depending on portType.
Gudge: You could, though that's a different question.
Anish: For equivalence of 2 EPRs, only address and ref props matter. Service, portType, etc. don't matter.
Gudge: Yes.
Jeff: All these questions about BPEL. This version came out a year after BPEL.
Paco: Yes, this model is a usecase, I already acknowledged that BPEL.
Jeff: There is a question about the identity model is, there's an implicit one in BPEL...
Gudge: There is one in WS-A also.
Jeff: we need to have a general architecture for an identity model for Web services. You see this converstation all over,.
Gudge: We don't need to do that here.
Glen: If we say these are the rules, you don't care about what happens within your machine. That's the magic of interop.
Jeff: You absolutely need to have that
agreement.
... Undocumented assumptions will make your app fall over, even if the
infrastructure doesn't.
DaveO: I'm struck with the similarities with
URIs and Cookies. Tons of flexibility in constructing URIs, e.g the choices
between query params and frag IDs.
... If they want to compare URIs, put identity data before the #.
... There are about four different places you can extend.
... We've got similarities in WS-A.
... You must interpret an address from the context (<a href=""> vs.
xmlns="".)
... Same in WS-A. We don't need to document the model sa long as they follow
the rules of WS-A.
MarkN: Another use case: DNS-EPD.
... DNS Endpoint discovery - a mechanism for using DNS to discover and EPR
for anything.
<hugo> http://ietfreport.isoc.org/ids/draft-snell-dnsepduri-00.txt
MarkN: We can identify specs that need thesse capabilities.
DaveO: And there may be use cases that aren't satisfied by the current raft of specs.
--- break ---
Telcon poll results: Monday UTC 8PM (Noon Pacific)
--- resuming ---
paco just stepped out...
Hang on.
Telcon exception next week Thursday Nov 3rd 12 Pacific. See mail.
After that we'll go with the Monday 12 Pacific slot.
MarkN: Requests for planning for Tech Plenary
Feb 28-March 4
... in Boston.
We have lots of overlap with WSDL, we'll avoid overlap and try for a joint session.
MarkN: We talked about BPEL for a while, and
DNS-EPD about discovery.
... other specs?
DaveO: There are WS-ReliableMessaging, WS-Reliability which we might be able to consider generically without prejudice.
<dims> ws-resource stuff in wsdm?
Paul: EPRs might be reused in other contexts.
Would we consider making EPRs a black-box, so you could replace our EPR
format with another one.
... How loose is our coupling with the EPR format?
Anish: An extensible addressing mechanism? WS-Reliability does that.
Glen: For interop, we should have one true way to do addressing. My company doesn't support having extensibility at this point.
Marc: We already have extensible props and params, the address is a URI. How much more do you need.
DaveO: What would motivate or demotivate it?
Glen: I can give you a demotivator.
... We don't want the outermost syntax for EPRs to be swappable - just as the
SOAP envelope has a single format.
... This allows us to build a system with intermediary forwarding.
DaveO: Glen is focussing on EPRs and routing, previous use cases highlight other areas. A good list of use cases highlights different aspects.
Dims: Management, e.g. monitoring how much time
it takes for a message to go and come back.
... A single way to do things helps with management.
Glen: Products from different vendors will work with a generic manager.
Greg: Don't you want a single standard in all areas?
Glen: No, only for four things: policy, soap, wsdl, addressing.
Marc: Redirect use case.
... I'd like to see redirects at an application level rather than at the
application level.
... e.g. session initiation.
e.g. I can use URI rewriting to encode a session identifier in the URI.
Glen: I may want to send you a redirect with
the "hi" response to the first interaction.
... Or I might want my session manager to dispatch round-robin to a set of
other services.
MarkN: Anyone going to talk about asynchrony?
Glen: Later :-)
Goodner: WS-Eventing, WS-Management, use reference parameters.
<goodner> WS-Management: msdn.microsoft.com/ws/2004/10/ws-management
Goodner: and properties.
Glen: Asynch?
MarkN: We're chartered to make existing MEPs work asynchronously.
Glen: If you're using WSDL SOAP over HTTP binding, you can't really change that to get a response on SMTP.
DaveO: Don't know if that's true.
MarkN: WSDL 2.0 isn't a Rec yet.
DaveO: I asked XMLP, haven't gotten a response yet.
Glen: As it stands, I think the request message maps to the HTTP request, the response maps to the HTTP response.
Anish: You could imagine a binding to SMTP, which points to our WSDL MEP mapping spec.
MarkN: The WSDL bindings are not a close spec, and we need to coordinate with WSDL.
Anish: Asynch scenario: you want to send an EPR as part of the application data. EPRs enabling application-level asynch responses.
Gudge: WS-Eventing works like that.
MarcH: Do we need time-to-live on asynch EPRs?
MarkN: Might have to get into that...
DaveO: Use case session timeout...
Paco: You might want to enable different models to be used with EPRs.
DaveO: Use case: stateless services. One use of cookies is to enable stateless web pages. Use of ref params/props may fill that need as well.
MarkN: Stateless = all information to contextualize a conversation is given in the message.
MarcH: You can also move state around.
DaveO: Difference between stateless and self-describing. I was proposing truly stateless.
Paul: The point of the spec is that SOAP/HTTP
has implicit correlation, other transports like MQ requires a mechanism to
correlate.
... Transport has a state.
MarkN: We've listed use cases that carry EPRs.
... We've talked about carrying metadata.
... talked about async and stateless.
... talked about reply-to
... talked about ref props/ref params some.
Paul: How many EPRs can you have in an
addressing envelope?
... Use email as an example. I can address to multi-cast the message.
... I'd be happy to punt that to higher-level specs.
Gudge: WS-A defines a bunch of headers, doesn't prevent other specs from defining other headers, or sticking EPRs in message bodies. Which are you trying to prevent?
Marc: You don't want to support a list of endpoints?
Paul: There are complexities: what if I fail on the third addressee?
Gudge: A message can only be sent to a single
endpoint. That endpoint could represent a group.
... You don't want multiple endpoints baked into the spec.
Paul: Good. Lists of endpoints gets complex, esp. what happens when things go wrong.
MarcH: Not sure I agree.
Paul: Could use more than address in your EPR.
Gudge: From a security perspective there's no guarantee their sec requirements are the same.
MarcH: No guarantee they won't be.
Paul: Trying to fill in a potential rathole.
... You can use other mechanisms.
Rebecca: You use SMTP as a bad example. We want to support HTTP, SMTP, MQ.
DaveO: If I'm sending an SMTP does the message
as you recieve it have more than one To:?
... You might be able to have a Multi-address To: header that lists everyone
else the message has gone to. Layered on top.
Rebecca: Sounds like your trying to restrict the transports we can use. Why disallow SMTP.
MarkN: You can think of this in several different ways: push it down into the address, or you could expand it at the application layer. Paul says multiple To:s adds complexity.
Anish: Doesn't this also apply to other headers? E.g multiple reply-to, relates-to.
Gudge: Absolutely you can have multiple of those.
Philippe: How does this work with reliability? Reply-to means the response might go somewhere else.
Gudge: Third party scenario. So far this handoff has been modelled at a different layer.
MarkN: Audit scenario. The headers are very useful for audit.
Paul: We've implemented a ReplyTo as part of an
end-to-end structure which logs the message exchange.
... Don't know how deep we should go, there's an endless list of things that
can go in there.
... Beyond some point lie dragons.
Rebecca: Similar to redirection, what about high availability?
Gudge: Like a server farm?
Rebecca: Lots of ways to implement.
Gudge: There's a primary address, and I then acquire a specific address.
Rebecca: Or there is a single EPR that gets routed internally.
Glen: Or, here are five endpoints, try them out.
DaveO: There's two ways to handle: if you send
me two EPRs and I can try them in some order.
... Or you can give me a single EPR which enables you to redirect to another
endpoint.
Rebecca: Or you might have all the information you need to make an informed decision.
MarkN: Common in HTTP to use cookies for this.
... Thoughts on wsa:Action?
DaveO: We've got a straight up
application-level action. We might need a more complicated one.
... In the case of ReliableMessaging, there is a case where the components
may be sent as a header block, or as the body.
... There is not a one-to-one correspondence between the body and the action
(?)
Glen: Use case: use the EPR to talk to a node
that itself doesn't support WS-A.
... Like a SOAP node which doesn't understand WS-A.
MarkN: Backward compatibility with non-WS-A aware nodes.
Greg: Up to us to define the semantics of what
can and cannot be done.
... We need to disambiguate what can and can't be expected.
MarkN: If EPRs are required to be understood, do we need an EPR mustUnderstand capability.
Rebecca: Use case of having multiple transports mapped to a single EPR.
Glen: But you really mean the service
reference.
... Represents multiple WSDL endpoints within a single service reference.
Rebecca: Alternate transports - all are available at the same time.
DaveO: If you offer a transport over multiple endpoints, isn't that for availability?
Glen: Not necessarily, might be for accelleration of a single interaction.
Philippe: There's a slippery slope. What if
those transports don't have the same policy?
... So you should be able to associate different policies with them?
[Yes.}
Glen: Here are your options, use the ones you
want.
... Use case(?) I'm an intermediary, and I'd like to be able to distinguish
what's ref props and what aren't.
... I'm interested in security and semantics of what's going past.
... I may want to remove optional headers. How do I know which are ref
props/params?
Paul: When we started out, we built a security proxy. You need to know what action the message is going to take at the destination.
Glen: Yes. Even if I'm not security, I may want to pick out the reference properties.
Paul: If you have a man-in-the-middle doing access control, you'd want to make sure that there isn't an unknown mechanism that dispatches the message.
Paco: Man-in-the-middle would do that on a per-contract basis.
Dims: ReliableMessaging has a create-sequence. SecureConversation has a create token. I want to send a single message that does both of them.
Glen: Boxcarring scenario.,
Gudge: It hurts. Don't do that.
... I think there is a composition pattern for that particular pattern.
Dims: Other protocols might come up that use actions.
Gudge: We already have that issue: what happens when actions collide.
Bob: Have we explicitly stated that there is a
DoS, firewalling characteristic we'd like to enable.
... Want to enable applicances that permit or deny certain things.
MarkN: Is there a corrollary in the Cookie World?
Bob: The utility would be enhanced to pass/block/route based on characteristics of the WS-A headers.
Paco: How much does that affect interop?
Bob: From a spec point of view if we were to
define something that made the creation of such an appliance impractical,
that would be unfortunate.
... Be mindful we don't prevent that.
Rebecca: Dynamic generation of EPRs brought up
a number of issues.
... Should track that as a use case.
MarkN: Chartered to accommodate different MEPs
with WS-A. Like to get an idea of what we have in mind for that.
... Multicast, async, callback. Any others?
Paco: Multi-protocol requirement: before we get
there it may be useful to cache metadata.
... Enough information to interact with the endpoint.
MarkN: Lifetime model for metadata?
Paco: We may want the EPR more self-contained.
... MetadataExchange use case, where you don't know enough metadata to know
how to interact.
Rebecca: Do you get all the pieces up front or
do you have to go get the metadata and process it.
... Different processing models in these two cases.
... MQ Series introduces a lot of concerns.
Anish: Use case for implementing existing MEPs using EPRs.
MarkN: Explicit in our charter.
... Will write down the list of use cases and make them available to the WG.
We can expand on these and help guide our decisions.
... Trying to develop WG shared understanding.
... Tomorrow, issues!
Philippe: SMTP isn't on the list.
MarkN: Thought that was a corrollary. But I'll add email as a use case.
Reconvene at 9AM.