<?xml version="1.0" encoding="UTF-8"?>
<wflow:Workflow xmlns="http://schemas.ggf.org/wflow"
	xmlns:wflow="http://schemas.ggf.org/wflow"
	xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl"
	xmlns:xsi="http://www.w3.org/2001/XMLSchemas-instance">

	<!-- In this section of the document we are going to describe some JSDL
		 "templates" that will be "instantiated" inside of our work flow.
		 These are templates in the sense that we may or may not refer to them
		 in various places with various pieces (for example, data staging
		 elements) reified or filled-in with specific, job instance
		 information
	-->
		<!-- Here we create a JSDL template and assign it a unique id called
			 "add-task" that we can use to refer to it later
		-->
	<jsdl:JobDescription id="add-task">
		<!-- The job identification element is standard JSDL and not relevant
			 to this example
		-->
		<jsdl:JobIdentification>
			<jsdl:JobName>Adder</jsdl:JobName>
			<jsdl:Description>A job which takes two input values (integers) and produces an output value which is the sum of the inputs.</jsdl:Description>
		</jsdl:JobIdentification>

		<jsdl:Application>
			<jsdl:ApplicationName>adder</jsdl:ApplicationName>
			<!-- In most cases, this element would have other information
				 inside of it (like a POSIXApplication element or
				 HPCApplication element).  We leave it blank here to simplify
				 the example.
			-->
		</jsdl:Application>

		<!-- We now define data staging elements, but notice how the
			 "Source/Target" elements inside are empty.  This is because of the
			 "template" nature of this JSDL document.  We will reify these
			 data stages later with actual data staging information as the
			 workflow orchestrator sees fit.  For now, we simply indicate
			 with empty Source/Target elements whether or not the data stage
			 shown is to be considered an input or an output (so that the
			 Workflow orchestrator can hook up the edges later).
		-->
			<!-- Notice that each data staging element is given a unique name.
				 This will be used later in the work flows to reference
				 data stages inside of JSDL templates.  These names must be
				 unique within a given JSDL template, but don't need to be
				 unique across JSDL templates (as we always refer to data
				 staging elements in the context of a JSDL template).
			-->
		<jsdl:DataStaging name="input-1">
			<jsdl:FileName>input-1.dat</jsdl:FileName>
			<jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
			<jsdl:Source/>
		</jsdl:DataStaging>

		<jsdl:DataStaging name="input-2">
			<jsdl:FileName>input-2.dat</jsdl:FileName>
			<jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
			<jsdl:Source/>
		</jsdl:DataStaging>

		<jsdl:DataStaging name="output">
			<jsdl:FileName>output.dat</jsdl:FileName>
			<jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
			<jsdl:Target/>
		</jsdl:DataStaging>
	</jsdl:JobDescription>

	<!-- Now that we have "declared" our JSDL templates (we could have given
		 more than 1), we start defining the work flow.  These define edges
		 in the flow, but don't really "bootstrap" the process.
	-->
		<!-- Just as with the JSDL, we give each workflow node a unique name
			 that we can use to reference it later.
		-->
	<wflow:Node id="fib-2">
		<!-- For this work flow node, we are saying that it is formed by
			 instantiating a JSDL template (the one called "add-task").
		-->
		<wflow:JSDL jsdl-ref="add-task">
			<!-- Since this work flow was instantiated by a JSDL template, we
				 have to describe how to reify the document (i.e., how to hook
				 up the data flows).  We do that by indicating that the data
				 stage called "input-1", which MUST exist in the JSDL template
				 called "add-task", is to be reified by plugging in the given
				 data stage URI (and this is for the source or target as per
				 the empty Source/Target element in the original JSDL
				 template).  This amounts to a constant or literal workflow
				 edge (i.e., not coming from another node).
			-->
			<wflow:Input data-ref="input-1">
				<wflow:URI>http://tempuri.org/data/one.dat</wflow:URI>
			</wflow:Input>

			<wflow:Input data-ref="input-2">
				<wflow:URI>http://tempuri.org/data/one.dat</wflow:URI>
			</wflow:Input>
		</wflow:JSDL>
	</wflow:Node>

	<!-- This node is similar in format and use to the "fib-2" node, but
		 notice that the second data stage reification element is different.
	-->
	<wflow:Node id="fib-3">
		<wflow:JSDL jsdl-ref="add-task">
			<wflow:Input data-ref="input-1">
				<wflow:URI>http://tempuri.org/data/one.dat</wflow:URI>
			</wflow:Input>

			<!-- This time, we aren't specifying that a work flow input is
				 coming from a literal or constant source.  Instead, we are
				 saying that the input-2 element for the add-task JSDL document
				 should be acquired by "hooking up" the output from the fib-2
				 workflow node.  Because fib-2 may have multiple outputs (as
				 per the JSDL or other nodes reference in it), we identify
				 which output we are referring to by naming it.  It is the
				 output called "output" from that node and since that node is
				 a JSDL instantiation, then its the data stage called "output"
				 that we mean.  The orchestrator of this work flow is free to
				 reify the JSDL document in anyways it wants and may specify
				 URI's for sources or targets that it generates on the fly to
				 move data from one node to another (one could imagine
				 BES activites using RNS and ByteIO for example to flow data
				 from one place to another).
			-->
			-->
			<wflow:Input data-ref="input-2">
				<wflow:Node node-ref="fib-2">
					<wflow:Source data-ref="output"/>
				</wflow:Node>
			</wflow:Input>
		</wflow:JSDL>
	</wflow:Node>

	<!-- Once again, this is like fib-3 and fib-4 except that we add
		 an entry for an output.  Usually, when we don't specify an output
		 we either intend to hook up any implied outputs from the node to
		 other nodes later, or we will just drop them on the floor.  This
		 node essentially is our sink of the work flow and as such we specify
		 a constant output location to send output to.  Nothing prevents us 
		 from using this output in other nodes however.  In otherwords, 
		 outputs can be hooked up to as many targets as we wish.
	-->
	<wflow:Node id="fib-4">
		<wflow:JSDL jsdl-ref="add-task">
			<wflow:Input data-ref="input-1">
				<wflow:Node node-ref="fib-2">
					<wflow:Source data-ref="output"/>
				</wflow:Node>
			</wflow:Input>

			<wflow:Input data-ref="input-2">
				<wflow:Node node-ref="fib-3">
					<wflow:Source data-ref="output"/>
				</wflow:Node>
			</wflow:Input>

			<wflow:Output data-ref="output">
				<wflow:Target>http://tempuri.org/fib-4.dat</wflow:Target>
			</wflow:Output>
		</wflow:JSDL>
	</wflow:Node>

	<!-- Finally, all work flow documents MUST have a wflow:Flows element
		 which essentially specifies an external dependency to get the
		 whole flow moving.  Here we say that this document requires
		 fib-4 to execute in order to complete, and so whatever the
		 orchestrator needs to do to make this happen is required.  More then
		 one flow may be given.
	-->
	<wflow:Flows>
		<wflow:Flow node-ref="fib-4"/>
	</wflow:Flows>
</wflow:Workflow>
