cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [Vision] Knowing When We are Done
Date Wed, 07 Dec 2005 20:20:53 GMT
Mats Norén wrote:
> Ross Gardler wrote:
> 
>> Bertrand Delacretaz wrote:
>>
>>> Le 7 déc. 05, à 09:10, Ross Gardler a écrit :
>>>
>>>> ...I envision being able to build a Cocoon application by saying 
>>>> "given these input types, I want this output type" and to have the 
>>>> resulting application automatically tested against my test inputs...
>>>
>>>
>>>
>>>
>>> Not sure if I understand what you mean, could you give an example?
>>
>>
>>
>> Most businesses are made up of common business processes. The odd one 
>> will be unique to that business, but most are common. In the case of 
>> the unique practices the software needs to be customised, but in the 
>> case of common practices an "off-the-shelf" solution is sufficient.
>>
>> Each common practice has a set of inputs, a set of intermediate states 
>> and a set of outputs. If the new Cocoon provides a series of 
>> components for transforming from an input to an ouput we can use these 
>> components to build complete applications.
>>
>> Here's a simple example:
>>
>> Inputs:
>> - purchase order
>>
>> Intermediate Docs:
>> - customer details
>> - credit approval
>> - stock level
>>
>> Required outputs:
>> - Invoice
>> - Packing slip
>>
>> It is possible to describe this process as a series of components, 
>> i.e. to get from a "purchase order" document to a "customer details" 
>> document use component ABC, to get from a "purchase order" to a 
>> "credit approcal" use component XYZ etc.
>>
>> It is possible to automate the discovery of these components and thus 
>> to automatically configure an application to move from document A to 
>> document B.
> 
> 
> This seem a lot like the concepts of an ESB, someone mentioned 
> ServiceMix [www.servicemix.org] in a recent thread. It's an interesting 
> vision but is Cocoon NG really going to compete in that arena?

See Daniels recent mail about wanting Cocoon to be a set of components 
that can be used in any context, guided by patterns. That's *exactly* 
what I'm talking about.

When I was first drawn to Cocoon it was a much simpler beast, it was 
still an XML processing framework. We all know what has happened since, 
it's been said many times in this and related threads.

However, when Cocoon was nothing more than a sitemap defining XML 
processing pipelines it was a small step away from being eveything any 
"ESB" today claims to be. "ESB" is only a buzzword, this stuff has been 
around for many years.

Now I'd better stop before I start convincing myself that people will 
find all 600 pages of my PhD interesting ;-)

I'll return to this one day when the vision is settled and in place, and 
I have the time to express it in a reasonably concise RT.

Ross




Mime
View raw message