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