Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <079FD72E42C9D311B854009027650E6F0ABED2BA@xatl02.atl.hp.com>
From: "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <kinga_dziembowski@hp.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: Donating Dispatcher/Adapter processing extension and SOAP ser
	ver   to the Cocoon project (Part 1)
Date: Tue, 22 Jan 2002 16:20:08 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Davanum Srinivas [mailto:dims@yahoo.com]
> Sent: Tuesday, January 22, 2002 3:35 PM
> To: 'cocoon-dev@xml.apache.org'
> Subject: Re: Donating Dispatcher/Adapter processing extension and SOAP
> server to the Cocoon project (Part 1)
> 
> 
> 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?

I tried, but due to inconsistencies between Request  and HttpRequest it was
impossible.
I had the about this discussion with Carsten and at some point we invited
all developers to discuss it but nothing happened..  
If you scan the archive you will find part of my discussion about
relationship between the two.
I did an analysis of methods defined by HttpServletRequest, HttpRequest and
Request. I found strange holes in the definitions. Some methods are not
defined in Request but implemented in HttpRequest. I am not sure is this for
a reason or by mistake. I still hope that some cleaning can be done to
improve the relationship between HttpRequest  and Request. 

> 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.

The Adapters are defined in the sitemap and dynamically loaded by the
dispatcher using Adapter.ROLE mechanism. 
It is true that it is not 100% sitemap component in the sense of being
explicitly used in the pipeline definitions. But it is a Component, it
should be "scriptable", more then one can be defined. Being sitemap member
adapters will be loaded, composed, setup ... and ready to be dynamically
selected by selector and used.


> 3. [OFF-TOPIC] Any reasons for not considering Axis for 
> implementing HP-SOAP?

1. Timing reason - we needed an implementation and Axis was not in release
stage.
   The side effect of our development is that we realized how extensible a
publishing framework can be with few new concepts - you can build very
powerful solution with minimal effort - the framework is doing the job for
you!!!!! You can view Cocoon as a pipeline controller and implement much
more then publishing. We did enjoyed this experience.
3. We are investigating Axis. 

Kinga

> 
> Thanks,
> dims
> 
> --- "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" 
> <kinga_dziembowski@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
> 

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