RE: How to add more transports/protocols to XProc?

This raises another question, there are no transactional semantics built
into XProc language. Was it left intentionally? What could be the best way
to achieve a transaction? Calumet does this is XDB integration where we can
set auto-commit to false explicitly in plugin configuration.

 

There is no persistence context in XProc either, consider a scenario where I
could serialize the state of a pipeline and invoke it after a  long running
task would have finished, may be raise an event and a pipeline step could
have been registered to listen to a special 'Event (Event ID)' port for
later invocation? This could make XProc the most versatile asynchronous
workflow processor. 

 

Sounds tough to achieve though. 

 

Alam Sher

 

From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf
Of Conal Tuohy
Sent: Tuesday, March 15, 2011 8:16 AM
To: xproc-dev@w3.org
Subject: Re: How to add more transports/protocols to XProc?

 

Another option is to wrap your external systems with web services (using the
term in the most general sense) of some sort. XProc has pretty good support
for HTTP in general, so if you can wrap your external systems with XML+HTTP,
then you don't need XProc extensions in order to be able to use them - you
can use pure XProc, and hence you have no dependency on any particular
version of any particular XProc processor. 

Regards

Con


On 14/03/11 19:07, vojtech.toman@emc.com wrote: 

Adina,

 

The most natural way to accomplish this is by using extension steps.
Basically, you would be adding new "black boxes" to your pipeline that do
the things that you want - executing SQL queries, making SOAP requests etc.
We have done this quite often at EMC and this approach actually works quite
nicely.

 

One thing to note is that you should be careful about ensuring that the
steps are executed in the right order. In a workflow situation, this is
typically quite important. It is therefore a good practice that the
extension steps have input ports and output ports, so that you can easily
express dependencies between the steps by adding explicit connections
(p:pipe bindings). In some situations it doesn't matter, but you typically
want to prevent the XProc processor from "randomly" deciding the execution
order of the steps in the pipeline.

 

Regards,

Vojtech

 

 

--

Vojtech Toman

Consultant Software Engineer

EMC | Information Intelligence Group

vojtech.toman@emc.com

http://developer.emc.com/xmltech

 

From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf
Of Adina Gupta
Sent: Friday, March 11, 2011 8:26 PM
To: xproc-dev@w3.org
Subject: How to add more transports/protocols to XProc?

 

Hi!

I'm wondering how could I use XProc to form a workflow to do things that are
not directly related to XML or the kind. For example, Calling SQL
queries/stored procedures, communication over plain udp/tcp sockets etc.

More precisely my workflow would be to couple a few sql select queries, a
few stored procedure calls and then based on the output plug some sockets
and write/read data over them, transform the response and that's it return
an output XML.

Is it possible? If yes then what's the best way of writing connectors for
such transports? An extension step or may be something else? 

Adina






-- 
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297
  _____  


No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3506 - Release Date: 03/14/11