Hi All,
Hope all is well.
After working through some interesting issues :) I've updated the
SOAP server for Cocoon that I've been working on in the following
areas:
o SOAP server reader is now based on Axis, rather than Apache SOAP.
o Helper abstract classes have been written allowing webservices
to implement LogEnabled and Composable.
o Several webservices are now included:
o cache (allows you to remotely manipulate the Cocoon cache
via soap, eg. clear it)
o memory (allows you to view the total and free amount of
memory in your Cocoon application, also allows you
to remotely invoke the garbarge collector)
o system (allows you to inspect the hardware your server
is running on)
o process (allows you to run a system process on the server
and view the output. eg. ps, uptime, df, etc)
o Included a small sample webapp which allows you to list the
services currently deployed.
o Moved entire source over to scratchpad, rather than core
The source with libraries is now much larger than the original version,
I'll make it available via http somewhere and enter a bugzilla patch.
Comments, suggestions more than welcome.
Cheers,
Marcus
On Thu, Aug 15, 2002 at 04:30:09PM +0200, Marcus Crafter wrote:
> Hi All,
>
> Hope all is well.
>
> Over the past couple of days I've been working on adding the
> ability for a Cocoon application to serve SOAP requests.
>
> The motivation for this work came from:
>
> o The need to share business logic data with other projects, ie.
> B2B communcation.
>
> o The desire to build an administration application and remotely query
> a live system about its status.
>
> Instead of building a second server into our application (ie. RMI,
> CORBA, etc), I thought it might be better to use SOAP for this for
> several reasons, mainly since servlet based Cocoon applications are
> really HTTP oriented servers anyway.
>
> The code adding this functionality is in bugzilla, #11728.
>
> My hope is that this feature is of use for others too.
>
> Essentially, I took the RPCRouterServlet from the Apache SOAP
> project and ported it to Cocoon as a Reader, which in effect
> allows you to register SOAP services within your Cocoon app, and
> serve data to other clients.
>
> The reader can be configured in the sitemap as follows:
>
> <!-- Defines a SOAP RPC reader that will serve SOAP requests via HTTP-POST.
>
> 'managed-services' defines a list of Apache SOAP deployment descriptors
> that will be automatically deployed at startup and undeployed at
> shutdown of this reader.
> -->
> <map:reader logger="sitemap.reader.soap-rpc" name="soap-rpc"
> src="org.apache.cocoon.reading.SoapRPCReader">
> <managed-services>
> <descriptor
>src="resource://org/apache/cocoon/components/soap/services/memory/DeploymentDescriptor.xml"/>
> </managed-services>
> </map:reader>
>
> Consult the javadocs for the full option set which includes the
> ability to set an EnvelopeEditorFactory, and custom SOAP server xml
> config file.
>
> The pipeline match is quite simple like most readers:
>
> <!-- Match SOAP RPC Router requests -->
> <map:match pattern="rpcrouter">
> <map:read type="soap-rpc" mime-type="text/xml"/>
> </map:match>
>
> With these 2 sections added to your sitemap, you can then make
> HTTP-POST queries to the above pipeline to deploy, list, invoke or
> undeploy particular SOAP services from your Cocoon app. The
> ServiceManagerClient class that comes with Apache SOAP is quite
> useful for this.
>
> I've included an example service with my patch which allows a
> remote client to query the amount of free & total memory the remote
> Cocoon app currently has, and also allows a client to invoke the
> garbage collector on the remote application.
>
> For those interested have a look at the class and deployment
> descriptor in the o/a/c/components/soap/services/memory directory,
> and the webapps/samples/soap directory.
>
> The SoapRPCReader also adds the Cocoon request, response, context
> and ComponentManager to the SOAP request context, which means it's
> possible for your SOAP services to access any avalon components you may
> have written, and also session data that may be relevant for the
> particular request. Have a look at the
> o/a/c/components/soap/services/template directory for an example of
> this.
>
> Normal SOAP services (ie. cocoon independant) can also be deployed,
> including those implemented in other languages via BSF support. The
> Apache SOAP documentation describes how this can be done.
>
> The reader itself requires the presence of the Apache SOAP jar
> (2.3.1 used during development), and the SUN activation and
> javamail jar. I've modified the build.xml so that the reader and
> associated services are only built if these libraries are present.
>
> I'm now looking at the various statistical & administration
> information we might like to provide from Cocoon, hopefully in
> combination with the instrumentation interfaces from Excalibur.
>
> Ok, so I hope its of use for more people that just me, if there's any
> questions, comments, feel free to ask.
>
> Cheers,
>
> Marcus
>
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: ManageSoft GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&'
> &&&&.
> &&&&&&&:
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
