In my experience the individual operations of a service generally use
the same backend functions. This generally means that either all
operations are working properly, or nothing of any significance is
working properly. It's possible to do things differently, grouping a
bunch of unrelated functionality into a single service, but I have a
hard time understanding the benefit of doing this.
If there *are* different groups of operations within the service, I'd
think it would make more sense to allow the user to define names for the
groups and pass that group name. So for instance, if someone combined
air, car, and hotel reservations in a single service while using
separate backend systems to process each type of reservation, they could
support ping("air"), ping("car"), and ping("hotel") for clients that
only needed one particular function.
So I just don't see the point in taking this down to the operation
level. It seems to me that doing so adds a lot of complexity to the
handling of the ping without much added value.
- Dennis
Thilina Gunarathne wrote:
Hi all,
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.
We can introduce "ping" in two levels.. The service level ping would
ping message receivers belonging to each and every operation listed
under that service. The operation level ping would ping just the given
operation.. We assume a certain "ping" request as a service level ping
whenever the operation name is missing in the body.. In this case we
might need to think bit more about the response message structure..
<complexType name="operationStatus">
<complexContent>
<restriction base="anyType">
<xs:sequence>
<xs:element name="status" type="xs:boolean"/>
<xs:any minOccurs="0" maxOccurs="unbounded"
namespace="##any"
processContents="lax"/>
</xs:sequence>
<attribute name="operationName" type="string" />
</restriction>
</complexContent>
</complexType>
The return type can be an array of operationStatus type..
Just my two cents :)..
Thanks,
Thilina
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
