[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.stockquote.StockQuote/
serviceName: net.xmethods.services.stockquote.StockQuoteService
endpointName: net.xmethods.services.stockquote.StockQuotePort
#2:
bindingTargetNamespace: http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.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/leave_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.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]