Re: Donating Dispatcher/Adapter processing extension and SOAP server to the Cocoon project (Part 1)

[Davanum Srinivas <di...@yahoo.com>]

Kinga,

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
Environments?
2. Is it possible to implement this in such a way that sitemap syntax is not changed (You have
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 used
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?

Thanks,
dims

--- "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <ki...@hp.com> 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 DemoDispatcher.java, DemoAdapter.java, and DemoAdapter1.java. 
> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org