[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]