Thilina Gunarathne wrote:
> easy enough to do this as an interface, though. So the message
receiver
> could check if the service class implements the pingable interface,
and
> if so it calls the method defined by that interface. Otherwise, it
just
> checks that it can create an instance of the service class.
Seems like we are agreeing on having service classes implement the
pingable interface.But in order to do that we need to add a (ping)
method to the message receiver interface, since message receiver needs
to have some method to check the service class (if the message
receiver has a associated service class)..
Yes, the discussions convinced at least me that having this go through
to the message receiver made sense, and that while the handler-based
approach could always be used it wouldn't necessarily be be as useful. I
think there are still some details to be worked out, though.
I'm especially unclear about how this would work at the individual
operation level, which was also part of what was discussed. My memory is
that there's (normally?) just one message receiver per MEP. So if the
intent is to offer a per-operation ping, I suppose you could pass the
operation name to the ping method. That seems somewhat ugly to me in
that the user code now has to be able to identify operations. Perhaps
it's better to instead have the ping only at the service level, where it
can be more clearly defined.
If the ping is limited to the service level, then it becomes an
arbitrary decision as to which message receiver should be used to
respond to the request (assuming there's more than one). Or do people
want to have all the message receivers polled?
Finally, if we're going to implement this (in whichever variation) I
suggest making the ping response extensible with added user data. So
perhaps it's of the form:
<xs:element name="pingResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="status" type="xs:boolean"/>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"
processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
This does mean that the ping() method would need to pass some form of
structured response back to the message receiver, rather than just a
boolean. Perhaps we could define a PingResponse class along these lines
to make it easy:
public class PingResponse {
private boolean up;
public PingResponse(boolean up) {
this.up = up;
}
public isUp() {
return up;
}
public List getAddedElements() {
// user classes can override to return a list of OMElement
return Collections.EMPTY_LIST;
}
}
I don't think the ping request really needs to be extensible, but
passing a String parameter is easy. That would allow the operation name
to be passed as previously proposed by Sameera, if someone does want an
operation-specific ping. So perhaps the ping logic calls each message
receiver ping() implementation in turn until it gets a non-null
PingResponse result?
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
