cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: Donating Dispatcher/Adapter processing extension and SOAP server to the Cocoon project (Part 1)
Date Tue, 22 Jan 2002 20:35:07 GMT

Thanks a ton for using Cocoon2...I had a few questions.

1. Is it possible to use org.apache.cocoon.environment.Request instead of
org.apache.cocoon.environment.http.HttpRequest so that this framework can work in Non-Servlet
2. Is it possible to implement this in such a way that sitemap syntax is not changed (You
introduced map:adapters/map:adapter)? Especially since you don't refer to the named Adapter
in the
sitemap, you refer to it in .xconf. For example, DemoAdapterA is defined in sitemap, but not
only in demo_dispatcher.xconf. I understand that you define it in sitemap so that you can
auto-magically configure the Adapters.
3. [OFF-TOPIC] Any reasons for not considering Axis for implementing HP-SOAP?


--- "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <> wrote:
> As you may know, we at HP Middleware have been doing extensive development
> using Cocoon2. I am writing to share my very positive experience with
> Cocoon2 and to propose the extension of the Cocoon2 publishing framework
> into the role of a processing framework. Below, I will summarize the basic
> concept, which I propose to submit for inclusion in Cocoon2 framework. In
> addition, I will provide a very simple example of implementation to
> illustrate the concept. 
> Enclosed with this email is set of interfaces and abstract classes that we
> came up with to answer a need that arose during our work on implementing the
> SOAP server. The concept is a foundation for further development of XML
> processing under Cocoon2 and should not be viewed as limited strictly to the
> SOAP server. If you find the proposed pieces useful, I would like to submit
> the full SOAP Server.
> First, a few words as to the origin of our project and involvement with
> Cocoon2. During design phase of our Web Services Platform, we recognized
> several fundamental requirements for the product's XML processing stack:
> 		Required use of existing standards rather than proprietary
> solutions
> 		Required flexibility and extensibility that allows
> adding/removing stages of processing
> 		Required Plug and Play support that enables the
> customization of processing
> Based on the above specifications, we recognized the need for a configurable
> pipeline for XML processing and routing. The pipeline therefore represents a
> set of processing modules that an incoming request goes through. As a result
> of the above analysis and identified requirements we chose Cocoon2 as the
> underlying pipeline based framework. 
> The processing for the SOAP server can be defined by:
> 		The soap message is posted to the host.
> 		The message processing goes through a soap header processing
> stage.
> 		The message processing goes through soap body processing
> stage.
> 		The resulting message or SOAP Fault is sent to the
> requestor.
> We applied the following Cocoon2 components to model the SOAP processing
> defined above: 
> 		Generator intercepting the message.
> 		Header Transformer responsible for header processing.
> 		Body Transformer responsible for body processing.
> 		Serializer responsible for formatting the response message
> to the requestor.
> Dispatcher/Adapter Concept
> We recognized the need for our pipeline to facilitate plug-and-play
> processing to meet our requirements. To accommodate this need, we introduced
> a new concept, Dispatcher/Adapter. The Dispatcher/Adapter is represented by
> a set of two interfaces, (1) Dispatcher; (2) Adapter. The data transfer
> between Dispatcher and Adapter is achieved through HttpRequest object. 
> Dispatcher
> 		Dispatcher - responsible for lookup and acquisition of the
> appropriate Adapter and to delegate the processing to it 
> 		In the proposed implementation the best candidate for the
> Dispatcher is a transformer which implements Dispatcher interface.
> Adapter
> 		Adapter - knows how to execute the required processing
> 		The Adapter is a new sitemap component. Several adapters can
> be registered in the sitemap under the <adapters> tag. 
> 		Adapter can be configurable if it extends one of the
> abstract classes, which provide configuration-reading capabilities. In such
> case the sitemap parameter determines the configuration file.
> The Dispatcher/Adapter concept provided us with a unique way to extend plug
> and play functionality to the SOAP server. A specific example will
> illustrate its capability. Assume that we would like to expose an SOAP RPC
> service encapsulated by EJB object.
> A specific method of this object needs to be executed in order to obtain the
> required information. When a request comes to our pipeline, we need to
> understand the message, find the appropriate EJB, load it and execute the
> method specified in the message on an EJB object. Then we need to form the
> response SOAP message containing the result of the method execution.  
> The Dispatcher, using the configuration info, dynamically selects the
> appropriate Adapter from the pool of registered adapters and dispatches the
> processing to it. In this case an EJB Adapter is required. The Dispatcher
> will dynamically acquire an EJB Adapter and ask it to processRequest(). EJB
> Adapter knows how to find and load EJBs in a generic way and all EJB based
> services can use it. The Adapter will acquire the required EJB object and
> will invoke appropriate method. Then it will pass to the Dispatcher the
> result of the method invocation. Dispatcher will "inject" the result coming
> from the Adapter to the result SOAP message. 
> The pipeline build using the Dispatcher/Adapter concept looks like:
>  <<...OLE_Obj...>> 
> The sequence of events in such a pipeline starts with a generator (e.g.
> StreamGenerator). The data associated with POST request InputStream is
> streamed to the next pipeline stage of the dispatcher. The Dispatcher,
> triggered by some events, decides to use a pluggable Adapter to perform a
> specific task and dispatches the processing to the adapter. The Adapter
> returns the results to the dispatcher and the flow continues.
> The benefits of the above delineated concept are numerous. First, the
> Dispatcher/Adapter concept allows to dynamically delegating the processing
> to the specialized Adapters. Second, it allows for an easy customization of
> the processing by plug and play the operation that can be achieved by
> changing configuration. Third party vendors can easily write their own
> Adapters without knowledge about underlying Cocoon framework.
> As an implementation of Cocoon2 Dispatcher/Adapter extension we built
> Cocoon2 based SOAP server in two flavors. One based on SAX events SOAP
> message representation, second based on JAXM representation. The list of
> identified adapters includes RPC Java Adapter, RPC EJB Adapter,
> and Header Adapter Transaction Adapter.
> The evident benefit of Dispatcher/Adapter concept was the ability to extend
> the meaning of RPC SOAP invocation. The "strict" meaning assumes that
> somewhere there is an object (Java class, EJB) exposing a method with
> specific signature, which needs to be invoked. The concept of Adapter allows
> to broaden this meaning and to leave the interpretation to the Adapter. For
> example, Adapter can interpret incoming message as Workflow engine
> initialization or transaction management participation. Below is the class
> diagram for base abstractions
> for the Cocoon2 processing extension.
> Dispatcher:
>  <<...OLE_Obj...>> 
> Adapter: 
>  <<...OLE_Obj...>> 
> I am presenting a simple demo of Dispatcher/Adapter in action. Once you have
> applied the patches enclosed with this email, invoke the sample by using the
> following URL, <http://localhost:9090/cocoon/DispatcherDemo>. The sample
> will include,, and 
> In this sample an XML message is sent to the processing pipeline composed
> by: StreamGenerator, DemoDispatcher and xml Serializer. There are two
> adapters registered in the sitemap: DemoAdapter and DemoAdapter1. The
> DemoAdapter is a very simple one, extending AbstractAdapter. It extracts the
> child nodes of the <Body> tag and in this place "injects" a simple message.
> The DemoAdapter1 is a configurable adapter. It extends
> AbstractComplementaryAdapter and can take advantage of the information
> contained in the configuration file indicated as a parameter in the sitemap
> registration of the Adapter. In this demo, the behavior of DemoAdapter1 is
> this same as DemoAdapter, but it additionally adds to the response message
> the contents of its configuration file. The dispatch decision is made on the
> basis of Dispatcher configuration file. This file contains mapping of the
> logical Adapter name to the sitemap registered Adapter. Naturally the
> dispatch decision can be done on any type of information for example using
> the request URL. All base classes and abstraction used in this demo are the
> basis of the implementation of HP-SOAP server.
> Instructions for attachments
> 	(1)	Core patches in the format of. diff files
> 	(2)	Zip file containing interfaces, abstract classes and demo
> 	(3)	Apply patches and unzip file
> 	(4)	Build Cocoon application
> I am confident that more developers will benefit from Cocoon2 processing
> addition. I would like to congratulate the Cocoon team for an excellent job
> in providing the framework for many developers to produce better solutions.
> In the meantime, please contact me if you would like any further
> information. I look forward to hearing from you.
> Regards,
> Kinga Dziembowski
> _________________________________
> Kinga Dziembowski
> Hewlett Packard
> HP Bluestone Middleware Division
> 6000 Irwin Road
> Mt. Laurel, NJ 08054
> 856.638.6065
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Davanum Srinivas -

Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!

To unsubscribe, e-mail:
For additional commands, email:

View raw message