axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <>
Subject Re: Use-cases for Services
Date Thu, 17 May 2001 07:05:17 GMT

I am not sure if "Service" is a good name here.
In WSDL, "Service" a collection of ports, including physical addresses.
On the other hand, the Service class seems more abstract in the sense
that it is not (but will be) bound to any address.
Furthermore, "Service" seems to be a server-side object, but you want
to use it at the client-side also.  I do not understand why?
Maybe, I am missing your point.  Or did you have some discussion relating
to this previously?

As for your second question, we may need async reqest/response, but
it would be difficult to include it in the current architecture.
Futhermore, request and multiple responses is also interesting feature
although we have decided that we are not going to support it.

Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668

From: on 2001/05/15 04:58

Please respond to

Subject:  Use-cases for Services

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
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
ends up different from TypeMappingRegistry).  The stuff in the base class
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
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