cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject RE: Donating Dispatcher/Adapter processing extension and SOAP ser ver to the Cocoon project (Part 1)
Date Wed, 23 Jan 2002 01:41:54 GMT
Hi Kinga,

Thanks for the feedback.Let me spend a few more hours on this tomorrow. 

As of right now...Am definitely +1 on accepting this donation.

Thanks,
dims

--- "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <kinga_dziembowski@hp.com> wrote:
> 
> > -----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
> 
=== message truncated ===


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


Mime
View raw message