Lists Home |
Date Index |
I stand corrected. I was using the terms pipeline and pipe somewhat
sloppily. Obviously, the applications connected by the pipes -- and not
the pipes themselves -- transform the documents.
I'm sure I'll get grilled for this, but to my mind, XML grids, XML
pipelines, whatever glues SOAs together, and similar systems are all of
a feather. The important characteristics (in my mind) are that the glue
is configurable by the developer and that the applications don't realize
they are being linked together. Note that the first characteristic
excludes a single, custom glue application, although that is certainly
> Hi Ron,
> Normally a pipe wouldn't modify the contents of what it
> is transporting. As you say, Unix pipes transport the contents
> to the destination where one assumes they arrive unchanged.
> On these XML pipelines, when data or a document comes
> out of a pipe, it is then modified by a process or
> program. That's where I got confused. I thought the
> modifications were being done in the pipe. It seems
> that they are actually being done once the data
> comes out, and that seems logical to me.
> And this pretty much sums up the paradigm that most
> people are using to build xml applications. A set of
> custom pipes, put together, with custom processes do
> stuff with whatever comes out of the pipe. Validation,
> transformation etc.
> It's a conventional paradigm where the programmer handcrafts
> a process and a set of messages into a tightly coupled
> set to do some job of work.
> Pipe sizes vary, and all have a multitude of different
> There is little or no conformity.
> Every pipe that appears in a business (customer request?)
> must be custom crafted by a programmer so that the data that
> pops out is useful.
> So we have lots of custom tools and thousands of
> combinations of everything so that there is never a
> shortage of programming work when trying to do something
> with xml. This is supposed to be good I guess.
> But I would suggest the ability to build every different
> size of pipe with "any connector you could possibly want"
> is an impediment to interoperability.
> XML Grids on the other hand are very different. Instead
> of a custom made connector at the end of each pipe to
> process each type of message, the approach is to use a
> mass-produced connector and make hundreds or thousands of
> copies of it, and make an array of those. With the
> array online, you have an automatic grid.
> The key concept of the Grid approach is to use a simpler
> type of message server but make it in such a way that it can be
> duplicated many times over.
> So this is just a slightly different paradigm I guess
> and possibly something for the future.
> Best Regards
> Quoting Ronald Bourret <email@example.com>:
>>I'm not sure why a pipeline wouldn't modify the contents. Isn't that the
>>point of pipes? For example, UNIX pipes are used to pass a character
>>stream from program A to program B, which modifies that stream and
>>passes it to program C, and so on. An XML pipeline, it seems, would do
>>the same thing, with the data stored in a document and the programs
>>being XML aware.
>>>ok, I know nothing...
>>>but it doesn't sound like an xml pipeline to me..
>>>one would normally think that the pipes wouldn't
>>>be modifying the contents. You wouldn't normally
>>>want that in a pipeline.
>>>It might be a relay, or a daisy-chain, but it
>>>doesn't really sound like what you need is
>>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>initiative of OASIS <http://www.oasis-open.org>
>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>To subscribe or unsubscribe from this list use the subscription
> This message was sent using IMP, the Internet Messaging Program.