[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] What are we managing: an example
William,
> #1 and #2 are just as simple for the simple case
What is the simplicity criteria? Number of properties?
I believe in simplicity by semantics of the information. Therefore #1 is simple #2 is more complex. #1 says service->endpoint #2 says binding+address+go-figure-what-it-means
> And in the more advanced case (like the additional WSDL Bryan sent), #2 makes life a lot easier.
And I just sent another WSDL which makes #2 not work.
> Especially since at the architecture level the WS-A definition of endpoint also points us towards #2.
I guess I just do no see that. WS-Arch says endpoint is an association. A named instance of association is the WSDL endpoint/port component. Associations have to have instances just like anything else, don't they?
-- 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: Monday, December 08, 2003 6:47 PM
To: Sedukhin, Igor S; WSDM TC
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]