cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Irv Salisbury III <...@dotech.com>
Subject Re: POST XML to cocoon protocol
Date Thu, 27 Jan 2005 22:37:32 GMT


Daniel Fagerstrom wrote:

> Irv Salisbury III wrote:
> <snip/>
>
>> I did get great answers.  One of the "hot" things a lot of our 
>> customers are looking at now is orchestrating web services together.  
>> Separating major pieces of the app behind REST style web services
>
>
> I didn't connect the term "REST style web services", to WS with XML 
> input. Can you expand a little bit about what you mean, are you 
> refering to something like: 
> http://www.intertwingly.net/stories/2002/07/20/restSoap.html ?
>
>> and then tying that together with things like BPEL.  That is really 
>> where my question was driven at.  I guess it would be interesting to 
>> see if there was any thought about integrating BPEL into cocoon.  
>> Kind of like a "flowscript" but in XML, but that could call cocoon 
>> pipelines, massage their content and string together reusable smaller 
>> pipelines.  That was where my difficulty lies.  I have a series of 
>> small, reusable pipelines, but that take XML in and return XML.  So, 
>> I need to "orchestrate that".  A key piece to this would be an 
>> architecture that let XML come into each internal cocoon call.
>
>
> I know to little about WS orchestration for having any opinion about 
> that yet. But I would be very interested in strenghtening Cocoon's 
> abilities for XML in XML out.
>
> I wrote the XModuleSource, ModuleSource and the SOAP stuff I mentioned 
> with that intension. The Cocoon architecture seem for me ideal for 
> document style SOAP handling, booth as a server and as a client. But 
> more work is needed to actually make i easy to use for such things.
>
> I have had some ideas about implementing postabillity for the cocoon: 
> protocol. That would be usable if you have a set of functionalities in 
> terms of WS written in Cocoon and want to reuse them within your 
> webapp. Then I have felt that a postable cocoon: protocol would 
> overlap to much in functionality with the (hopefully) forthcomming 
> virtual transformer http://wiki.apache.org/cocoon/VirtualComponents. 
> But I don't know.
>
> Unfortunatly I haven't found time to push this development any further.
>
> You are very welcome to discuss about how we could make Cocoon more 
> convenient for WS and WS orchestration here.
>
> /Daniel


In my case, it would actually have been easier to have something like:

<call-pipline "test-pipeline">
    <generator-xml>
          <mydata>
             ....
            </mydata>
      </generator-xml>
</call-pipeline>

And then be able to have multiple ones of these.  So, basically you are 
calling a pipeline and passing the XML data to it that you want to use 
for its generation.  The result would then be put in place of the mydata 
element.  People have provided many great suggestions for how to do this 
with existing components, but because you know you are calling a cocoon 
pipeline, why can't this just be substituted for its generator?  I 
realize the pipeline without the generator would only be useful if 
called this way, but it would help me design things that were broken 
down into smaller pieces as reusable pipelines. 

I realize I chose bad names below, but here is the idea:

<map:pipeline no-generator="true">
    <map:match pattern="test-pipeline"
        <map:transform src="foo.xsl"/>
        <map:serialize type="xml"/>
   </map:match>
</map:pipeline>

Our current design pattern for cocoon webapps encomasses starting out 
with small REST style interfaces that take request parameters and return 
XML.  These perform service oriented calls to the database, etc.  When 
we then build pages, we look at the page and see what web services we 
need to build that page.  We then use an XSL to aggregate these calls 
(with CIncludeTransformer) and then style it appropriately.  We have a 
rule that all business logic, SQL, etc has to go behind the web 
services.  Keeps things very separate and we have enjoyed quite a 
success building apps this way.  The problem comes in when you want to 
have a web service component that takes in XML and sends XML back out.  
It seems like cocoon should be awesome for this, and I am one of its 
biggest fans.  However, this really isn't that easy or straightforward.  
Something along the lines of BPEL where I can setup inputs from one web 
service to be outputs to another.  Maybe something like:

<fancy-cinclude>
    <variable name="userdata" call-pipeline="userdata-pipeline"/>
    <variable name="securitydata" call-pipeline="security-pipeline"/>
    <variable name="processed-data">
        <call-pipeline>
           <aggregate root="aggregate">
              <use-variable name="userdata"/>
              <use-variable name="security-data"/>
           <aggregate>
        </call-pipeline>
    </variable>
    <final-pipeline call-pipeline="final" variable="processed-data"/>
</fancy-cinclude>

Now, this would have been really slick for me.  Basically, you can call 
internal pipelines and store them in variables.  Then, those variables 
can be passed as input to other pipelines.  This makes shuffling XML 
around in this arena very slick.  I am not as up on flowscript as I 
should be, so maybe someone can show me how to do the above in 
flowscript.  (Or with existing components)

Thanks for listening.

Irv

Mime
View raw message