- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Thu, 25 Apr 2002 06:15:08 -0400
- To: <www-ws-desc@w3.org>
Hi Alek! > in the last issue "Services and Service Types" the proposed solution is > creation of serviceType element that i believe is an excellent idea > especially if it would allow to aggregate not only portTypes but also > serviceTypes recursively. This is a possibility, but I'm not sure its needed. Can you provide some use-cases for when it would be useful to recursively build serviceTypes out of serviceTypes? > however requiring for service that implements serviceType > to have exactly one binding for each portType makes it impossible > to provide multiple access mechanism to service (multiprotocol), > for example SOAP/HTTP and EJB/RMI as equivalent protocols > to interact with service. No, I don't think so: it just means that different binding selections is done at a serviceType granularily and not at a portType granularity. That is, right now if you have 3 portTypes (pt1, pt2 and pt3) and 2 bindings (ejb-pt1, soap-pt1, ejb-pt2, soap-pt2, ejb-pt3, soap-pt3) for each one, then its not clear whether you have to use the same binding type for both portTypes or not. So can I choose ejb-pt1/pt1 and soap-pt2/pt2? Not clear, but most probably not. If we group these via serviceType/service, then its clear that binding choices offer different services and that binding choices are offered as different services for the same serviceType. > i think it is important to keep ability of client to introspects WSDL > and employ the best access mechanism to service if choices are available > (for example it may be SOAP but it may be something more optimized ...) I agree. > finally: if service implements serviceType doe sit mean that service ports > are accessing the same logical instance of service? Yes, a given implementation of a serviceType should represent one logical instance of a service. Is that what you're asking; I'm not clear on the question? Sanjiva.
Received on Thursday, 25 April 2002 06:41:45 UTC