You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <ki...@hp.com> on 2002/01/22 19:03:39 UTC
Donating Dispatcher/Adapter processing extension and SOAP server
to the Cocoon project (Part 1)
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
Re: Donating Dispatcher/Adapter processing extension and SOAP server to the Cocoon project (Part 1)
Posted by 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