Re: [wsrfdiscussion] ServiceGroups

[Tom Maguire <tmaguire@us.ibm.com>]

Sorry for the delay in responding....


Norman Francis Beekwilder <nfb5z@cs.virginia.edu> wrote on 04/29/2004
12:01:44 PM:

> Hi,
> I have been looking at the description of the
> wssg:membershipContentRule/@MemberInterface in section 5.1.1. it says
that a
> membershipContentRule applies if the @MemberInterface matches the qname
of the
> member's interface/portType. However, section 4.4 of the
WS-ResourceProperties
> spec mandates that a service only expose one portType that is created
through
> aggregation of the portTypes/interfaces that it implements.

You are correct there is no mechanism for inherited interfaces that we can
use
in WSDL1.1.  Additionally, the mechanism that was used in OGSI v1.0 to
annotate
the WSDL portType with this information is not in WSRF.

> This means two things, first no more that two membershipContentRules will
ever
> apply (one for the aggregated portType and the default rule)

Certainly the constraints on @memberInterface will only ever match the
"most
derived portType".  With regard to the default rule; I assume you mean a
membershipContentRule with no @memberInterface specified? If so, then you
could
have multiples of those although I'm not sure why you would.  So the spirit
of your
assertion is correct.

> and second that it
> is impossible to create a service group that will consist solely of any
> services that derive from a given portType.

Yes it is impossible since there is no mechanism defined in WSDL1.1 or WSRF
for derivation of a portType.

> For example lets say that I wanted
> to create a service group that could contain any service that implements
the
> wsrp:GetResourceProperty portType. Most (all?) services will not have
this
> portType as their most derived portType so I can't use that as the
> @MemberInterface. I would instead have to have one membershipContentRule
> for each derived service and this set would have to be updated everytime
a new
> service was derived from the wsrp:GetResourceProperty portType. This is
not
> how service group membershipContentRules worked in OGSI.

The distinction between OGSI and WSRF is the annotation of inherited
interfaces;
since we do not have that at our disposal we obviously cannot use that
mechanism.
That being said, as the TC goes forward we certainly can look at expanded
semantics
of ServiceGroup membershipContentRules.

> Was this change in the way service groups work intentional?

Yes

> Reading the example in section 2, I get the feeling that the answer is
no.

The example in section 2 abides by the rules normatively expressed in
section 5.

> However, I realize that it is a lot
> harder to detect the interfaces that went into a derived portType than
was the
> case in OGSI so maybe it was intentional.

Agreed, normatively describing a mechanism for discovery and classification
of
a derived portType into it's potential constituent parts would be extremely
difficult.

> Is there any consensus on how a service implementing
ServiceGroupRegistration
> might determine if an EPR being Added conforms to the MemberInterface?

Not yet, but that would be a great conversation to start.

> Should a service assume it can get the WSDL using that EPR?

I do not think that presently you can make the assumption that a service,
never mind an EPR, can give you it's WSDL.

> Should that EPR contain the various port types that the service
implements?

WS-Addressing has an optional element for a portType QName.  However, I do
not
think this will address your needs.

I have been thinking about how to create membershipContentRules that would
constrain
the members based on the resource properties values of the member.  This
would allow
many interesting collections of the kind you are describing....


Tom

T o m   M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY  12601

internet:                 tmaguire@us.ibm.com
phone:                     845.433.9401 (t/l 293-9401)