Axis proof of concept and next step questions (was Axis mailet / matcher)

[Tim Stephenson <ti...@thestephensons.me.uk>]

Here is a 'proof of concept' implementation of integrating Axis into James.

First I had to include the following service config in the
server_config.wsdd embedded within the axis jar since I have not yet worked
out a dynamic config option
<service name="urn:xmltoday-delayed-quotes" provider="java:RPC">
    <parameter name="className" value="samples.stock.StockQuoteService"/>
    <parameter name="allowedMethods" value="getQuote test"/>
    <parameter name="allowedRoles" value="user1,user2"/>
    <parameter name="wsdlServicePort" value="GetQuote"/>
  </service>

I made the following changes to James as built and configured in CVS
a) added the following libraries to compile and sar creation (thru mods to
the build script and associated props):
    axis-1.1rc2.jar - modified see above
    commons-discovery.jar
    commons-logging.jar
    wsdl4j.jar
    jaxrpc.jar
    saaj.jar
    axis-samples.jar (a jar of the samples included with Axis, though not
normally jarred)
b) added this mailet to the 'root' James config immediately before the catch
all mailet.
         <mailet match="HasHeader=SOAPAction" class="Axis">
         </mailet>
c) test using the attached GetQuote client

What I have not done at this point is to configure the axis engine
dynamically and have some questions about how I should approach this:
a) Is a mailet the best approach or should it be a 'server' in it's own
right like say pop or smtp are? In particular is just one mailet
instantiated for all requests? I presume it would be better to be able to
devote multiple threads to servicing axis requests.

b) Would it be ok to put Axis' server_config.wsdd in the SAR-INF directory?
How can I get the actual path to this directory at runtime?

Tim

----- Original Message -----
From: "Tim Stephenson" <ti...@thestephensons.me.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 2:54 PM
Subject: Re: Axis mailet / matcher


> Vincenzo,
>
> I had not worried about your option 1) for the time being as administative
> requests can be configured prior to runtime - obviously this requires
server
> restart and is less than ideal so it would be great to have a means to do
it
> dynamically, but it is good enough for a few experiments. I had rather
> assumed the obvious option would be to get your option 2 (i) in place and
> then configure the server using a web service call.
>
> 2(ii) is really what i was looking into - I too believe it would be
> incredibly powerful to have such loosely coupled processes requiring
nothing
> more than email access.
>
> My first thought was simply to have a matcher to identify incoming
messages
> either by their address or because they contain a soap envelope (content
> type seems to be unreliable since the client controls it, though
> 'application/soap+xml' may be used at some point). The mailet could then
> handle them by simply handing off to an Axis engine. This much I have
> trialed using the classes in org.apache.axis.transport.mail (basically the
> commons-net pop3/smtp clients). This could simply be wrapped as a mailet.
>
> Some questions before I get too carried away!
>
> how should axis engine be started? i dont know avalon at all should it be
> another app or would it be better off inside james 'proper'. What hooks
> exist for starting the engine this way - is it simply a question of the
> mailet holding an engine reference or is there a better option?
>
> i look forward to all your views.
>
> tim
>
> BTW I have not looked into the SOAP2HTTP bridge at all but it seems to me
> that Axis has moved beyond the SOAP project in this as in other areas.
Axis
> has a core engine that is abstracted from the transport. The current axis
> mail transport class reads email in a specified mailbox after it is
> delivered which is reasonable for supporting arbitrary mail servers, but
> James could integrate it much more tightly avoiding the need for polling.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>