- From: Steve Graham <sggraham@us.ibm.com>
- Date: Thu, 25 Apr 2002 14:49:50 -0400
- To: www-ws-desc@w3.org
The Grid Service spec [1] offers several instances where it would have been
very handy to have inheritance at the portType level or serviceType level.
First, let me explain that for the Grid services work, we needed to
introduce serviceTypes to work around the lack of inheritance or
extensibility of portType.
We introduced serviceType element, using extensibility off of the
definitions element to allow for aggregation of common portTypes.
The Grid Services spec defines a handful of base portTypes (Grid Services
(think base class like object), a Registry portType, NotificationSource and
NotificationSink, portTypes, Factory portType etc.). Since our lifecycle
requirements dictated that all Grid Service instances support both
soft-state and explicit destruction, all Grid Services must support the
GridService portType. This includes for example a Factory object for
creating new Grid service instances. So we could create a service type
like: JobManagerFactory that aggregated GridService, and Factory and
perhaps a portType that contained generic JobManagerFactory operations.
All well and good, we can do JobManagerFactory with serviceType without any
notion of inheritance.
However, if there was a need to define "GaussianJobManagerFactory", that
includes specific additional or constrained behavior on JobManager
particular to the "Gaussian" program, then we are in for a bit more
difficulty. The GaussianJobManager serviceType has to repeat the
aggregation of GridService, Factory and JobManager, and then add the
additional "GaussianJobManagerFactory" portType behavior. This begins to
become a maintenance nightmare as well as an impediment to effective "find"
operations against a registry.
The solution we proposed in the GS Spec was to introduce
compatibilityAssertion elements, that allowed the designer to declare that
GaussianJobManagerFactory was "equivalent" to JobManagerFactory. The
interesting bit is what it means to be equivalent.
Net/Net: If we had serviceType inheritance, it would make this sort of
layering of behavior much easier to model in WSDL.
I hope this helps
sgg
[1]http://www.globus.org/ogsa
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Emerging Technologies
++++++++
"Sanjiva
Weerawarana" To: <www-ws-desc@w3.org>
<sanjiva@watson.i cc:
bm.com> Subject: Re: multipe protocols/bindings that implements serviceType [Re: slides from
Sent by: my presentation on issues with the core spec]
www-ws-desc-reque
st@w3.org
04/25/2002 06:15
AM
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 14:50:06 UTC