[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] What are we managing: an example
Thanks for the example Igor, this is useful to the discussion. It shows
that, if we forget the architecture level for a minute (which is where most
of our discussions have been) and focus on the practical aspects, #1 and #2
are just as simple for the simple case (only one description of the
endpoint). And in the more advanced case (like the additional WSDL Bryan
sent), #2 makes life a lot easier.
So why make life harder in the complex case if doing so doesn't simplify the
simple case?
Especially since at the architecture level the WS-A definition of endpoint
also points us towards #2.
William
> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> Sent: Monday, December 08, 2003 8:42 AM
> To: WSDM TC
> Subject: [wsdm] What are we managing: an example
>
>
> Folks,
>
> For those of you who are struggling though the technical
> details of the proposals and without arguments attached, here
> is how ManageableThingIdentification capability information
> instance would look like in the three cases. Let's try to
> identify some "thing" actually published on the Internet
> (from xmethods.com). Note that only essential (absolutely
> necessary) information is listed.
>
> The "thing" description:
> http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl
>
> #1:
> targetNamespace:
> http://www.themindelectric.com/wsdl/net.xmethods.services.stoc
> kquote.StockQuote/
> serviceName: net.xmethods.services.stockquote.StockQuoteService
> endpointName: net.xmethods.services.stockquote.StockQuotePort
>
> #2:
> bindingTargetNamespace:
> http://www.themindelectric.com/wsdl/net.xmethods.services.stoc
> kquote.StockQuote/
> bindingName: net.xmethods.services.stockquote.StockQuoteBinding
> address: http://66.28.98.121:9090/soap
>
> #3:
> address: http://66.28.98.121:9090/soap
> activities:
> {
> { IN, urn:xmethods-delayed-quotes:getQuote },
> { OUT, urn:xmethods-delayed-quotes:getQuoteResponse } }
>
> Note examples of the messages
> IN
> [
> <?xml version="1.0" encoding="UTF-8"?>
> <soap:Envelope
> xmlns:n="urn:xmethods-delayed-quotes"
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <soap:Body
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
> <n:getQuote>
> <symbol xsi:type="xs:string">CA</symbol>
> </n:getQuote>
> </soap:Body>
> </soap:Envelope>
> ]
> OUT
> [
> <soap:Envelope
> soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";>
> <soap:Body>
> <n:getQuoteResponse xmlns:n="urn:xmethods-delayed-quotes">
> <Result xsi:type="xsd:float">23.41</Result>
> </n:getQuoteResponse>
> </soap:Body>
> </soap:Envelope>
> ]
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: Sedukhin, Igor S
> Sent: Saturday, December 06, 2003 5:55 PM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); WSDM TC
> Subject: RE: [wsdm] What are we managing: analysis and proposals
>
> William,
>
> 1. is managing the thing as IDENTIFIED by the endpoint
> description component according to WSDL 2. is managing the
> thing as IDENTIFIED by the address (URI) and the binding
> description component according to WSDL 3. is managing the
> thing as IDENTIFIED by the address (URI), messages (XML
> payload elements) and exchange patterns (sequences&directionality)
>
> What did I misinterpret/misrepresented? :)
>
> My subjective judjement is that #1 is at least good to cover
> 80% of cases. Take an existing WS development tool or
> toolkit, deploy a WS on an existing WS platform of your
> choice, take a look at the WSDL that it generates and see if
> it is ever different than the case #1. That is my first preference.
>
> If we are to manage Service Access Points and to properly
> answer your question [So my question is, what is the benefit
> or restricting an endpoint to only one description?] then I
> say it must be #3. It is not very complex, in fact the
> identification capability is quite simple.
>
> > The implementation of a binding at an address, as defined by WS-Arch
>
> According to http://www.w3.org/TR/ws-gloss/#endpoint there is
> nothing about implementation as defined by WS-Arch. It is an
> association as defined by a WS-Arch.
>
> > What you are proposing is to add a constraint that an
> endpoint can only have one description.
>
> One description component! Yes, that is my intention and as
> far as I can tell an intention of at least a few other in the
> WSDL WG. We have to fix it and reduce the number of
> variations that people can have using WSDL. It affects
> everyone, WSDM TC is not the only one struggling through
> this. When WSDL group started I remember a discussion when
> all these variations were put on the board and then we
> started to think how to make it better. It didn't get much
> better so far because WSDL 1.1 created enough misuse already.
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com]
> Sent: Saturday, December 06, 2003 4:38 PM
> To: Sedukhin, Igor S; WSDM TC
> Subject: RE: [wsdm] What are we managing: analysis and proposals
>
>
> Hi Igor,
>
> I copy/pasted out of your PDF so it is easier to discuss. The
> first two proposals in your summary are as follow, where (1)
> represents what you proposed at the F2F and (2)
> (mis-)represents what I proposed:
>
> > 1. Use 80%/20% rule and manage endpoints as described by
> WSDL 1.1 port
> > components. This is how WSs published with existing tools and
> > platforms are and this is reinforced by changes in WSDL 2.0.
> >
> > 2. Cover a few more cases (e.g. 10% more) by managing
> > AccessPoint/ProtocolStack/ServiceImplementation <aggregate>s.
> > Define such thing, name it, and identify by address (URI) + WSDL
> > binding component pair. Note that this does NOT cover 100%
> cases and
> > therefore does not solve the problem.
>
> I completely agree with this part of (1), your proposal:
> "endpoints as described by WSDL 1.1 port components". WSDL
> 1.1 port components do indeed describe endpoints. But they do
> not IDENTIFY endpoints. WSDL is a description language. As I
> said in my original proposal, both WS-Arch and WSDL
> consistently define an endpoint as the implementation of a
> binding at an address. A WSDL port is a description of such
> an endpoint. Period. What's not clear here?
>
> What you are proposing is to add a constraint that an
> endpoint can only have one description. Why? What is the
> benefit? Being able to construct the resourceID by using XML
> properties of the port element? You can do this with more
> than one description, just pick one of the ports and do the
> same. Your ID wouldn't be guaranteed to be the same if built
> by two different people anyway because there are different
> ways to build the ID with the XML properties of a port
> element. And in any case we all agreed at the F2F that it is
> bad practice to try to guess how to write the resourceID of
> someone else. It is an opaque ID and they way you get it is
> by it being passed to you through references.
>
> Adding constraints to make things simpler make sense
> sometimes, but there has to be a benefit otherwise why impose
> the constraints. I could say that 80% of portType have less
> than 6 operations but why would I make this a constraint if
> there is no benefit? So my question is, what is the benefit
> or restricting an endpoint to only one description? I asked
> this several times at the F2F and never got an answer.
>
> In your description of (2), you say it is "managing
> AccessPoint/ProtocolStack/ServiceImplementation
> <aggregate>s". Then you challenge us to
> > Define such thing
>
> The implementation of a binding at an address, as defined by WS-Arch
>
> > name it
>
> This is an endpoint but as I said earlier we could name it
> something else if it help.
>
> > and identify by address (URI) + WSDL binding component pair
>
> Actually, identify by an opaque ID like any other resource
> and then provide some description like the address and the
> binding. The opaque ID could of course be constructed by
> using XML properties of a port that describes this endpoint
> (the QName of the service and the local name of the port).
>
> Regards,
>
> William
>
> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> Sent: Saturday, December 06, 2003 12:41 PM
> To: WSDM TC
> Subject: [wsdm] What are we managing: analysis and proposals
>
>
> <<What to manage for MOWS.pdf>>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leav
e_workgroup.php.
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.ph
p.
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.ph
p.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]