Foros del Web » Programación para mayores de 30 ;) » Programación General »

Consumir Web Service

Estas en el tema de Consumir Web Service en el foro de Programación General en Foros del Web. Hola a todos, Primero, soy bastante novata y ando algo perdida con el tema de los web services. Tengo una aplicación (/TavernaServer.2.2a1) es decir, un ...
  #1 (permalink)  
Antiguo 27/06/2012, 11:41
 
Fecha de Ingreso: mayo-2012
Mensajes: 2
Antigüedad: 12 años
Puntos: 0
Consumir Web Service

Hola a todos,

Primero, soy bastante novata y ando algo perdida con el tema de los web services.

Tengo una aplicación (/TavernaServer.2.2a1) es decir, un punto .war ejecutándose en el tomcat. Necesito utilizar dicha aplicación para ejecutar una serie de workflows que tengo almacenados como ficheros en mi pc, y para ello lo tengo que invocar desde mi aplicación java.

Según la documentación que tengo de dicha aplicación, se supone que bastaría con subir los ficheros a direcciones... Y se supone que se ejecutaría dicho fichero, pero por más que leo la documentación y busco como invocar web services más me lio :(

Esta es la documentación:

Taverna 2 Server release 1

For a full list of operations, see the service listing generated by Apache CXF, which indicates where to access the WSDL and WADL descriptions of the T2Server interface.
Simple Guide to Using the REST API

The Taverna 2 Server supports both REST and SOAP APIs; you may use either API to access the service and any of the workflow runs hosted by the service. This simple guide just discusses the REST API.

The client starts by creating a workflow run. This is done by POSTing a wrapped T2flow document to the service at the address http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs

The wrapping of the submitted document is a single XML element, workflow in the namespace http://ns.taverna.org.uk/2010/xml/server/, and the workflow (as saved by the Taverna Workbench) is the child element of that.

The result of the POST is an HTTP 201 Created that gives the location of the created run (in a Location header), http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID (where UUID is a unique string that identifies the particular run; this is also the name of the run that you would use in the SOAP interface). Note that the run is not yet actually doing anything.

Next, you need to set up the inputs to the workflow ports. This is done by either uploading a file that is to be read from, or by directly setting the value.

Directly Setting the Value of an Input

To set the input port, FOO, to have the value BAR, you would PUT a message like this to the URI http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/input/input/FOO

<t2sr:runInput xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest/">
<t2sr:value>BAR</t2sr:value>
</t2sr:runInput>

Uploading a File for One Input

The values for an input port can also be set by means of creating a file on the server. Thus, if you were staging the value BAR to input port FOO by means of a file BOO.TXT then you would first POST this message to http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd

<t2sr:upload xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest/" t2sr:name="BOO.TXT">
QkFS
</t2sr:upload>

Note that “QkFS” is the base64-encoded form of “BAR”, and that each workflow run has its own working directory into which the uploads are placed; you are never told the name of this working directory.

Once you've created the file, you can then set it to be the input for the port by PUTting this message to http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/input/input/FOO

<t2sr:runInput xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest/">
<t2sr:file>BOO.TXT</t2sr:file>
</t2sr:runInput>

Note the similarity of the final part of this process to the previous method for setting an input.

You can also create a directory, e.g., IN, to hold the input files. This is done by POSTing a different message to http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd

<t2sr:mkdir xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest/" t2sr:name="IN" />

With that, you can then create files in the IN subdirectory by sending the upload message to http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd/IN and you can use the file as an input by using a name such as IN/BOO.TXT. You can also create sub-subdirectories if required by sending the mkdir message to the natural URI of the parent directory, just as sending an upload message to that URI creates a file in that directory.
Uploading a Baclava File

The final way of setting up the inputs to a workflow is to upload (using the same method as above) a Baclava file (e.g., FOOBAR.BACLAVA) that describes the inputs. This is then set as the provider for all inputs by PUTting the name of the Baclava file (as plain text) to http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/input/baclava

Now you can start the file running. This is done by using a PUT to set http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/status to the plain text value Operating.

Now you need to poll, waiting for the workflow to finish. To discover the state of a run, you can (at any time) do a GET on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/status; when the workflow has finished executing, this will return Finished instead of Operating (or Initialized, the starting state).

There is a fourth state, Stopped, but it is not supported in this release.

Every workflow run has an expiry time, after which it will be destroyed and all resources (i.e., local files) associated with it cleaned up. By default in this release, this is 20 minutes after initial creation. To see when a particular run is scheduled to be disposed of, do a GET on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/expiry; you may set the time when the run is disposed of by PUTting a new time to that same URI. Note that this includes not just the time when the workflow is executing, but also when the input files are being created beforehand and when the results are being downloaded afterwards; you are advised to make your clients regularly advance the expiry time while the run is in use.

The outputs from the workflow are files created in the out subdirectory of the run's working directory. The contents of the subdirectory can be read by doing a GET on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd/out which will return an XML document describing the contents of the directory, with links to each of the files within it. Doing a GET on those links will retrieve the actual created files (as uninterpreted binary data).

Thus, if a single output FOO.OUT was produced from the workflow, it would be written to the file that can be retrieved from http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd/out/FOO.OUT and the result of the GET on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd/out would look something like this:

<t2sr:directoryContents xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest"
xmlns:t2s="http://ns.taverna.org.uk/2010/xml/server/">
<t2s:file xlink:href="http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/wd/out/FOO.OUT"
>out/FOO.OUT</t2s:file>
</t2sr:directoryContents>

The standard output and standard error from the T2 Command Line Executor subprocess can be read via properties of the special I/O listener. To do that, do a GET on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID/listeners/io/properties/stdout (or .../stderr). Once the subprocess has finished executing, the I/O listener will provide a third property containing the exit code of the subprocess, called exitcode.

Note that the supported set of listeners and properties will be subject to change in future versions of the server, and should not be relied upon.

Once you have finished, destroy the run by doing a DELETE on http://localhost:8080/TavernaServer%2E2%2E2a1/rest/runs/UUID. Once you have done that, none of the resources associated with the run (including both input and output files) will exist any more. If the run is still executing, this will also cause it to be stopped.

All operations described above have equivalents in the SOAP service interface.

Alguien me puede echar un cable o alguna documentación para invocar dicho web service.

De antemano muchas gracias

Etiquetas: consumir, java, service, xml
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 12:00.