axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Client-side Chaining
Date Thu, 08 Mar 2001 14:47:18 GMT
  I just added client-side chaining - something feels strange
about it, but here it is:

The AxisClient Engine will look for an ENGINE_HANDLER defined
in the msgContext bag, if there it will find that handler in
the registry and invoke it.  If there is no registry it will
try to see if it's a class name, if so, it will load it and
invoke it.  If all that fails, it throws a fault.

If there is no ENGINE_HANDLER defined it perform the default
client behavior:
 - search for a service that matches the TargetService field
   in the msgContext.
   If found it will invoke just the "request" side of it, or
   if it's not a targeted chain it will invoke all of it.
 - search for a handler matching the GLOBAL_INPUT id and invoke it.
 - search for a handler matching the TRANS_INPUT id and invoke it.
   it's important to note that we're assuming that someplace
   in this chain is the handler that will actually make the call
   to the server.
 - search for a handler matching the TRANS_OUTPUT id and invoke it.
 - search for a handler matching the GLOBAL_OUTPUT id and invoke it.
 - if the handler in #1 was a targeted chain, invoke the "response"
   side of it.

In all of the above steps if the handler is not found we'll just
skip the invoke.  Also, if the handler is not found we will try to use
that name as a className and try to load it - this will allow people
to pass around classNames as handler id's w/o requiring a registry.
We might need to move this function into the registries themselves
but for now it's not.

In HTTPMessage:
- it creates a new AxisEngine and init's it.
  This allows it a chance to load any registries that *might* be there.
- if the is no registry, or if there is one, but no chain is defined
  with the name "HTTP.input" then we set the TRANS_INPUT field in the
  msgContext to "org.apache.axis.transport.http.HTTPDispatchHandler".
  We need this hard-coded value in the cases where nothing is
  configured.  Note, that this is why I needed to add that registry
  find logic that checks to see if a handler name is really a class
- if there is a registry, and there is a chain named "HTTP.input" then
  we just set the TRANS_INPUT field in the msgContext to HTTP.input.
  The basic idea here is that setting TRANS_INPUT to HTTP.input and
  TRANS_OUTPUT to HTTP.output is what we really want to do so that
  people can deploy chains on the client (called HTTP.input and
  HTTP.output) and the HTTP Transport Sender will automatically pick
  them up.  However, in the cases where nothing is configured/deployed
  we still need to some how get the HTTPDispatchHandler invoked
  some how.

We then invoke the AxisEngine.

So, in order for someone to configure these chains they need to:
  Service Specific:
    - deploy a *service* with the same name as the service on the server.
    - use just the input and output chains - the pivot will be ignored.
    - deploy a chain called "Global.input" and/or "Global.output"
  Transport(HTTP for now) Specific:
    - deploy a chain called "HTTP.input" and/or "HTTP.output"

Deployment should be done using the Admin tool:
  java org.apache.axis.utils.Admin foo.xml
so, the *.reg files need to be in the current dir when you run the
client - until we get the config file stuff done.

Hope at least some of this makes some sense.


ps. Yes, I know input/output is still used in places and I need to
    go back and do another global replace.   8-)

View raw message