cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivelin Ivanov <ive...@apache.org>
Subject Re: [RT] WebServicesProxy Generator
Date Tue, 25 Jun 2002 01:28:26 GMT

Hi Matthew.



Matthew Langham wrote:
> Hi Ivelin,
> 
> I think a component like this is a natural addition to Cocoon and the
> portal. It's been talked about several times before and it's great to see
> you starting to work on it.
> 
> 
> Fire and Ice welcome ;)
> <<
> How can I select which parameters to pass to the Webservice? From your
> example it looks as though all the parameters are passed from the request to
> the service.


To be able to plug-in an interactive remote application, which was 
designed for http request/ xml response, like the feedback wizard,
you would want to require minimum effort for integration.
This is why I expect that in most cases a simple pass through proxy will 
do a fine job.

If you will need to manipulate the request stream, then you can extend 
the proxy generator and override the formatting methods.

Allowing too much flexibility through sitemap config parameters will 
obscure the main purpose of this component - transparent integration 
between portal applications.


> 
> Wouldn't it be better for the WebServicesProxy to be a transformer? That way
> it would be more flexible to build up the actual call and parameters using
> previous components in the pipeline, stylesheets etc. Also I could have
> multiple WSPtransformers in the pipeline to do multiple calls.



Initially I was thinking about a transformer as well.
Over the last few months, as I gained more experience with Cocoon,
I came to agree with something Stefano was preaching all along.
Sitemap is the place to handle metadata, not to process data.
Similarly transformers are the place to transform XML, not any data in 
general.

This is why I agree that the emailer for example should be an action or 
generator, not a transformer.

Of course this is all too vague, easy to talk about and hard to prove, 
but I cannot make a case for the opposite yet. Maybe you can help.

Once a generator the WebServiceProxy can be turned into a transformer,
although I have yet to learn who and when would like to have that.

> 
> Are you going to use Axis?

Didn't plan to initially, but you make me think about it.
I was simply going to implement an HTTP proxy using Jakarta HttpClient. 
Can you tell why I would want to use Axis?


Thanks for the feedback,

Ivelin


> 
> Matthew
> 
> --
> Open Source Group       Cocoon { Consulting, Training, Projects }
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
> -----------------------------------------------------------------
> Cocoon book:
>   http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
> =================================================================
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> The WebServiceProxy Cocoon generator is intended to:
> 
> 1) Allow easy syndication of dynamic content as a natural extension of
> the currently popular static content syndication with RSS.
> 
> 2) Allow transparent routing of web service request through GET, POST,
> SOAP-RPC and SOAP-DOC binding methods.
> 
> 3) Allow almost full control through sitemap configuration.
> 
> 4) Allow use of Cocoon components for content formatting, aggregation
> and styling through a tight integration with the Cocoon sitemap.
> 
> 5) Require 0 (zero) lines of Java or other business logic code in most
> cases.
> 
> 6) Be generic and flexible enough to allow custom extensions for
> advanced and non-typical uses.
> 
> 7) Support sessions, authentication, http 1.1, https,  request
> manipulation, redirects following, connection pooling, and others.
> 
> 8) Use the Jakarta HttpClient library which provides many sophisticated
> features for HTTP connections.
> 
> 
> 
> ------------------------------------------------------------------------
> Example I: Integration of the Amazon book search service in a Cocoon portal:
> ------------------------------------------------------------------------
> 
> pipeline:
> ---------
> 
>      <map:pipeline>
>        <map:match pattern="amazon/searchform">
>            <map:generate src="AmazonForm.xml"/>
>            <map:transform src="AmazonForm2html.xsl"/>
>            <map:transform
> src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>            <map:serialize type="html"/>
>          </map:act>
>        </map:match>
> 
>        <map:match pattern="amazon/search*">
> 
>            <map:generate src="http://rcm.amazon.com/e/cm{1}">
>                <!-- The WebSericeProxy generator takes 3 arguments: -->
>                <!-- 1) The URL of the targeted web service -->
>                <!-- 2) The binding method: GET, POST, SOAP-RPC or
> SOAP-DOC -->
>                <!-- 3) Optionally, name of the session to the remote
> service, which allows scoping and grouping between different sitemap
> sections. -->
>                <map:parameter name="wsproxy-method" value="GET"/>
>                <map:parameter name="wsproxy-session"
> value="myAmazonSession"/>
>            </map:generate>
> 
>            <map:transform src="amazonform2html.xsl"/>
>            <map:transform
> src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>            <map:serialize type="html"/>
>          </map:act>
>        </map:match>
>      </map:pipeline>
> 
> 
> AmazonForm.xml:
> ---------------
> 
> <?xml version="1.0" ?>
> <document xmlns:xf="http://xml.apache.org/cocoon/xmlform/2002">
>    <xf:form id="form-amazon" view="search"
> action="amazon/search?t=myAmazonId-02-20&l=st1&mode=books&p=102&o=1&f=xml">
>      <xf:caption>Amazon book search by keyword</xf:caption>
>      <xf:textbox ref="search">
>          <xf:caption>Keywords</xf:caption>
>      </xf:textbox>
>      <xf:submit id="submit" class="button">
>        <xf:caption>Submit</xf:caption>
>      </xf:submit>
>    </xf:form>
> </document>
> 
> 
> ------------------------------------------------------------------------
> Example II: Even more interesting.
> Integration with an interactive web service - the Cocoon FeedBack Wizard.
> Notice that it is actually simpler to integrate with an interactive
> service then a "single call" based one, because WebServiceProxy supports
> sessions as well !
> ------------------------------------------------------------------------
> 
>      <map:pipeline>
>        <map:match pattern="RemoteWizard/*">
>          <map:generate
> src="http://remotehost:8080/cocoon/samples/xmlform/{1}">
>            <map:generate src="http://rcm.amazon.com/e/cm{1}">
>                <map:parameter name="wsproxy-method" value="POST"/>
>                <map:parameter name="wsproxy-session"
> value="myFeedbackWizardSession"/>
>            </map:generate>
>            <map:transform src="myNewStyle-wizard2html.xsl"/>
>            <map:transform
> src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>            <map:serialize type="html"/>
>          </map:act>
>        </map:match>
>      </map:pipeline>
> 
> 
> 
> ------------------------------------------------------------------------
> End of file
> ------------------------------------------------------------------------
> 
> 
> --
> 
> -= Ivelin =-
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 



-- 

-= Ivelin =-


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


Mime
View raw message