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]