axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject API for ServiceClient
Date Mon, 17 Sep 2001 17:24:43 GMT
In response to some of the EJB embedding bugs, I would like to componentize
the ServiceClient code for you, but I need some input.  Part of the process
is identifying what the end user is expected to interact with.  I do not
like making interaction points classes.  I think these should be made interfaces,
and that users should only interact with the interface.

There are a number of methods and constructors that make instantiating a
ServiceClient impossible to instantiate in constrained environments like
EJBs.  Also, they muddy the interface.

The Avalon mentality is to provide the simplest interface to the user--kind of
like only one way of doing things.  I understand that the interface as it is
reflects the hard work you guys have already done.  That being said, I think
it can be simplified.  The simplified interface would be made into a Java
interface, and the ServiceClient class would be augmented to handle the
process.

Avalon has solved alot of the architecture issues in providing a scalable system.
I am more familiar with that background, so therefore, my proposals are slanted
in that direction.  Let me give a quick overview for how this can work:

Avalon defines a component accessor methodology called the Component Management
infrastructure.  This is the core of Avalon.  Avalon has separated the concern areas
of managing components behind the scenes, so if a component implements specific
interfaces the component is treated accordingly.  As a result, things like
component instantiation can not only be implemented, but the strategy is hidden
from the user.  For instance, anytime that you have an interface that requires
more than one method invocation on a component in a session--it cannot be
threadsafe.  Your choice is either to pool instantiations of the component, or
to create a new component for each time it is needed.

Cocoon uses this to great effect since they have chosen to expose the SAX 2 API
for all the components in the XML pipeline.  You can also control the number of
instances and how quickly the pool grows very easily.  Each thread has their own
unique instance of the Component they need--therefore the ServiceClient interface
does not need to change that much.

Part of the Component Management infrastructure is the concept of Component Selectors.
The Component Selectors allow you to obtain a specific reference to a Component
Instance depending on an Object accessor.  All the Components in the selector implement
the same interface, and perform the same function.  The idea here is if we wanted
to have a ServiceClient instance per endpoint URI.  You would be able to choose the
ServiceClient based on the URI.  Considering the use of the ServiceClient, the selector
approach would most likely not be used.

All that being said, there are a number of methods that are used to manage the
ServiceClient that are made public due to the almost reflective nature of the
current configuration scheme.  Setting the different transport protocols, timeout
settings, and option management can all be done without exposing the methods to
the client.  Adding the serializers and deserializers can be a client specific
task--however, the client configuration can do that as well.

All that being said, the public API for ServiceClient can be reduced to this:

public interface Client {
    //endpoint URL management
    void setURL(String endpointURL);

    //MessageContext option management
    void set(String name, Object value);
    Object get(String name);

    //Message handling
    void setRequestMessage(Message msg);
    Message getResponseMessage();

    //Session handling
    setMaintainSession(boolean isMaintained);

    //MessageContext
    MessageContext getMessageContext();

    //ServiceDescription
    void setServiceDescription(ServiceDescription serviceDesc);

    //Output Parameters (this is modified to allow typesafe params)
    Parameters getOutputParams();

    //Invocation methods
    SOAPEnvelope invoke(SOAPEnvelope env) throws AxisFault;
    Object invoke(String namespace, String method, Object[] args) throws AxisFault;
    Object invoke(String method, Object[] args) throws AxisFault;
    Object invoke(RPCElement body) throws AxisFault;
    void invoke() throws AxisFault;

    //might not be appropriate
    void AddSerialzier(Class clazz, QName qname, Serializer serializer);
    void AddDeserializerFactory(QName, qName, Class clazz, DeserializerFactory factory);
}

Mime
View raw message