OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] What are we managing: an example


Bryan,

And I have just rewritten your WSDL example to show that #2 will not work eaither. It was very easy to rewrite it that way :). Attached.

You said [The key is that this proposal is not based on a description, but where the messages are processed]

Really? Then how come by rewritting the WSDL your proposal does not work anymore? Proposal #2 is depends on description in exactly the same way as #1 does.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: MURRAY,BRYAN (HP-Seattle,ex1) [mailto:bryan.murray@hp.com] 
Sent: Monday, December 08, 2003 6:38 PM
To: Sedukhin, Igor S; WSDM TC
Subject: RE: [wsdm] What are we managing: an example

Igor,

I have included a WSDL for a full-service stock information service which offers a stock quote interface as well as a stock rating interface. The WSDL located at http://trustUs.com/wsdl/StockInformation.wsdl is included in this note. The same port offered in the previous service for stock quotes is also used here. However, the service name is different, and the port name is different. By proposal #1, this implies there are 2 distinct message sinks, each with its own manageability endpoint. It is not possible to provide a manageability endpoint to collect information about only one of the ports.
The reason is that we have 2 descriptions for the same port. A WSDL document can only describe a port, it cannot identify the port. More than one WSDL document can describe the same port.

Proposal #2 suggests that both ports describe the same endpoint as defined by WS-Arch. The binding and address are the same, hence there is only one message sink. The set of messages and their format received at the address are fixed by the binding. This proposal allows more than one manageability endpoint for this one message sink, but does not require it. The key is that this proposal is not based on a description, but where the messages are processed.

Bryan



-----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.stockquote.StockQu
ote/
serviceName: net.xmethods.services.stockquote.StockQuoteService
endpointName: net.xmethods.services.stockquote.StockQuotePort

#2:
bindingTargetNamespace:
http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.StockQu
ote/
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.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.



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.

stockInfo2.wsdl



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]