You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Davanum Srinivas <di...@yahoo.com> on 2002/01/23 02:41:54 UTC
RE: Donating Dispatcher/Adapter processing extension and SOAP ser ver to the Cocoon project (Part 1)
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)" <ki...@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)"
> > <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
>
=== 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
Re: Donating Dispatcher/Adapter processing extension and SOAP ser ver to the Cocoon project (Part 1)
Posted by kingadziembowska <ki...@msn.com>.
Thanks,
Let me know if you need any more info.
Kinga
----- Original Message -----
From: "Davanum Srinivas" <di...@yahoo.com>
To: <co...@xml.apache.org>
Sent: Tuesday, January 22, 2002 8:41 PM
Subject: RE: Donating Dispatcher/Adapter processing extension and SOAP ser
ver to the Cocoon project (Part 1)
> 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)" <ki...@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)"
> > > <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
> >
> === 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org