XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Transformative Programming: Flow-based, functional,and more

I'm sure it could be made to work, but I'm not sure it should be made to 
work.
=============

My very reason for implement xmlsh pipelines *in process* was that it is highly inefficient in practice to have lots of little tasks
in a pipeline if you have a heavyweight protocol connecting them (say, starting a sub-process).  In my case 100x - 10,000x inefficient.

I simply cannot imagine writing an pipeline where every step involved a REST call ...
It *could* be done, and maybe in cases parts of a pipeline are well suited to an external REST call ... (say fetching an external resource)
but basing the fundamental architecture of a pipeline infrastructure on REST to me makes no sense.  It would lead to the opposite,
optimizing the pipeline so it had as few (but huge) pieces as possible to get over the infrastructure cost of step invocation.

Now to flip sides, some standardized workflow engines are based on either SOAP (BPEL) or REST (AWS Workflow) ... 
but IMHO  for similar reasons, each step tends to be huge and the workflow coordinates as few as possible big steps because the infrastructure
to cross domains is heavy.   This is a mega-scale pipeline, not a micro-scale.  Scale matters.



-David

----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS