axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Use-cases for Services
Date Mon, 14 May 2001 19:58:49 GMT

Here are some use-cases and example code snippets for various things we
might want to do with Services in Axis.  I'm in the midst of framing out the
architecture for this stuff - your comments would be most helpful.

Basic context first:

A Service represents the conduit through which everything in Axis happens.
It looks something like this:

 class Service {
    String name;
    ServiceDescription description;
    TypeMappingRegistry serviceTypes;
    Operation [] operations;

The Operation class represents a particular operation (in the WSDL sense).
It's not necessary to have any of these, but they can specify per-operation
type mappings or extensions (headers)....

Other stuff might also live in there, like Handler registries (assuming that
ends up different from TypeMappingRegistry).  The stuff in the base class is
useful on both the client and the server.  The remainder of this message
talks specifically about client-side patterns.  I'll deal with server-side
stuff in a separate note.

So we have the client-side service class, which adds a transport binding...

 class ServiceClient extends Service {
    TransportBinding transport;

...and then there's likely an RPC subclass which has the call() method:

 class RPCServiceClient extends ServiceClient {
    public Object call(String method, Object [] args);

This is not fleshed out yet, clearly, and the examples below try to dig into
a bit more of the desired functionality/api of these classes.  The idea is
that using the classes should be easy and natural with or without service
descriptions or local deployment.

OK, now some use-cases:

For all these examples, assume -

 Service s = new Service(Endpoint.newEndpoint("http://destination"));
 Service s = new Service(new HTTPEndpoint("http://destination",

1. Send a plain XML message (no service description) wrapped in SOAP

 Element xml = getDOMFromSomewhere();

2. Send a plain XML message with some context extension (SOAP header)

 Element xml = getDOMFromSomewhere();
 SOAPEnvelope env = s.createSOAPEnvelope(xml);
 env.addHeader(new my.package.SecurityHeader("user","password"));

3. Send an XML-encoded Java object

 s.addTypeMapping(obj.getClass(), someSerializer);

I'm not sure I really like this, since there's no explicit differentiation
between encoding an object and just passing it to invoke() - i.e. invoke()
might know how to deal with DOM Elements, but we also might want to have a
custom encoding for DOM Elements.... maybe something like:

 SOAPEnvelope env = s.createSOAPEnvelope();

4. Send a message with attachments

 Message m = new Message(soapEnvelope);
 m.addAttachment(new File("test.jpg"));
 m.addAttachment(inputStream, "text/html");

5. Send a request, wait for a response

 Message m = getMessageFromSomewhere();
 Message resp = s.invokeWithResponse(m);

6. Invoke an RPC method

 RPCServiceClient s = new RPCServiceClient(endpoint);
 Object result ="echoString", new Object [] { "hi!" });

** Add service description **

Any of these may be augmented with a service description...


Adding this will cause the Service to check RPC method invocations against
the valid methods in the service description, perhaps validate
datatypes/schemas, etc...


1) invoke() or send()?
2) Should we support asynchronous request/response messaging, i.e.:
   s.invokeAsync(message, callback);
3) Does this look like a reasonable start for where we want to be?

Glen Daniels
Engineering Manager
                                Building cool stuff for web developers

View raw message