This schema specifies how a service call should look like With this tag you can declare a service call inside a document. The service call then can be passed to the engine for materialization. The engine parses every service call tag in a document and proceeds with respect to what is declared within the tag, in other words this tag holds all the configuration needed for the execution engine. As theoretically a service call looks like a call to a function on a web the syntax resembles a function call in a programming language, for example: a) return void soap(http://address/to/Web/service) b) return append rest(http://address/to/Web/service) Any descriptive information. For instance, it could be used for giving a comment for a service call. Other systems that know about active documents can use this part for passing meaningful information during the execution process, e.g. an optimizer can append the details about where (which peer and document) the service call is being executed. This tag does not affect the normal execution of the service call. The tag holds information about how the service call should be executed and what its current status. Materializing a service call means that it is first activated, then it is running and finally it terminates (or fails). Also some ordering constraints can be imposed for service calls, however, this feature should be used with caution in order to avoid loops. In the simplest case this tag can initially be absent. Roughly Web services can be split into two groups: IN-Only and IN-OUT (as defined in WSDL Message Exchange Patterns). The former means that the Web service does not return any message in a response (except faults), the latter means that a Web service returns some message. Accordingly, service calls can be seen as OUT-Only and OUT-IN. The former means that the service call should not expect any results, while the latter means that results will arrive and will have to be merged into the document. The absence of this tag implies OUT-Only service call. Equivalent to not specifying the 'return' element at all. There are many ways of merging incoming results into the document, the simplest one is to append the results next to the service call. The validity of results of a service call can be handled internally. This implementation allows to specify the time interval when the result should be deleted. In the future tracking of results might be delegated to a specialized service. For instance, some caching service could be responsible for clearing the out-dated results. When nothing about validity is said, it is assumed that result is valid forever (but it means nothing if the results are not merged; see 'return' tag). Here the actual values of the validity interval are specified. This is quite an advanced feature. It is sometimes the case that the default way of calling a Web service is not enough or inefficient; for instance, theoretically every peer has SEND and RECEIVE Web services used for passing data around, however, calling SEND using a service call is not the same as calling some other stateless service on the Web because of its streaming nature. Therefore in this attribute different implementations of materialization behavior can be specified. I.e. here we give the full calss name of the materializer. Currently these are subclasses of: fr.inria.gemo.axml.model.sc.materialization.AbstractOutOnlyMaterializer, fr.inria.gemo.axml.model.sc.materialization.AbstractOutInMaterializer When the attribute is not specified the default materializer is used: fr.inria.gemo.axml.model.sc.materialization.DefaultOutOnlyMaterializer, fr.inria.gemo.axml.model.sc.materialization.DefaultOutInMaterializer SEND, RECEIVE and QUERY services have their own materializers, and using the default materializer with these services can cause unexpected outcome. The attribute is not designed for simple users but rather for systems leveraging ActiveXML. Here we mainly specify the endpoint and actual parameters of a Web service As service calls themselves can be a result of a service call they should be markable by the system namespace attributes, since currently to identify a result node a couple of attributes are used (see 'result' tag) This is an id of a service call in a document, aka current-node-id. In a distributed environment a notion of currentID and originalID was introduced where the currentID is a tripple (current-peer-id, current-document-id, current-node-id). Since any node at any point of time is on some peer in some document on the implementation level it is enough to keep only the current-node-id attribute (that is this attribute). The originalID, on the other hand, has all the three attributes denoting the triple (original-peer-id, original-document-id, original-node-id) (see attributes 'peerID', 'docID', 'nodeID'). The original ID is needed to have consistent referencing mechanism inside all the active documents in P2P system. It is of the qualified form because there may be also other (non service call) nodes that need a currentID. The engine assures that whenever this id changes the references to it (within the document) are also updated. This is important when data is travel from one document to another inside the P2P network. For instance, when a service call is to be inserted into a document that already has another service call with the same id the incoming id must change to be unique within resulting document. So when the id changes the following things are updated: 1) the results that belong to the service call that is being changed 2) the constraints specified inside 'activation' tag The details are in UpdatingOperator class. The value denotes the first id that the node was assigned (i.e. the first current-node-id) The id of a document that the original service call belonged to (i.e. the first current-document-id) The id of a peer that the document with the original service call belonged to (i.e. the first current-peer-id) The timestamp of when the service call was activated (started to be materialized). The execution engine assigns this attribute. It is useful for debugging, as well as for tracking the validity of service call results. rpc/lit and doc/lit-wrapped messages in SOAP envelope body must be supported (this is the future of WSDL). This is pretty much enough because rpc/enc and doc/lit-unwrapped are not WS-I compliant. Thus here an actual message body (the payload) should go. According to conventions the element name coincides with the Web service operation name. Here goes the message that is POST'ed to the service using 'application/xml' encoding. This is actually how the XForms are submitted by default. Allows to call a Web service using SOAP by providing only the body of the message. Allows to call a Web service the REST way. When the payload is given it is POST'ed otherwise it is GET'ed Normally the wsdl is not needed. However, for some applications, like type checking or GUI it would be crucial for consulting the types and validating. It also sometimes needed to extract some properties like soapAction in order to successfully call the Web service. The endpoint reference of the Web service. Normally it is an HTTP address. When other communication protocols are used additional configuration might be required for Axis2 The service call will be (scheduled and) executed only if it does not have a marked execution time. Depends on the last execution of the service call. In terms of streams the recurrent nature of this way of activation means that the stream is never ending even if an end-of-stream message arrives the scheduling is not canceled. Serves to create a chain of execution. For non-streaming service calls this coincide with afterTerminated, otherwise it means something like "after got 'OK' from server" The xs:IDREF type is not used on purpose, because the whole document is normally not kept in memory, therefore the reference would not make sense. A service call is activated starting with a "click" until the end-of-stream. Then it becomes terminated. So on subscription to a stream the receiving service call must be marked as activated. A "running" document has at least one activated service call. For simple (non-streaming) service calls the termination coinsides with the first response. IMPORTANT [Not implemented]: When publishing a running document it first should be determined if the activated service calls inside it are really active. This usecase can appear when recovering a system from the failure or after turning it OFF and ON again. Means that the service call can be activated It means that a service call is not activated at all. Its children are still evaluated. Means that the service call is running. Trying to materialize a service call in this state will not succeed. Coincides with the 'ENABLED' state just that it shows that the service call is terminated. Coincides with the 'ENABLED' state just that it shows that the service call failed. This merge function is useful for lazy OUT-IN operations, when one needs to specify that the service returns result, but no merge is needed. Replaces all the earlier results with the incoming ones