•Web Service: using Web Service Description Language (WSDL)
BPEL Servers and Engine
•Create on demand
•BPEL engine: Focus to act as an execution engine which can be programmed using BPEL
BPEL Programming Language
•Programming logic – BPEL
•Data Types – XSD (XML Schema Definition)
•Input/Output (I/O) – WSDL (Web Services Description Language)
http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:print="http://www.eclipse.org/wsws/choreography/2004/engine/Print">
http://schemas.xmlsoap.org/wsdl/" location="../../test_bucket/service_libraries/wsws_EnginePrinterPort.wsdl" namespace="http://www.eclipse.org/wsws/choreography/2004/engine/Print" />
Importing WSDL and XSD files
•The 'import' statement in BPEL is a directive to import a WSDL or XSD file. Importing XSD files allows commonly used datatypes or datatypes required for a particular endpoint (thing that you speak to) to be defined in a file separate to the BPEL file. Importing WSDL files allows endpoint descriptions (definitions of things that you speak to) to be defined in files separate to the BPEL file.
Partner Link
•Partner Links can be thought of as placeholders for things that you actually speak to. A web service is described in full by the WSDL files that specify it but Partner Links allow you to have something like an instance of the web service that you speak to. A partner link basically maps to a WSDL web service 'portType', so one partnerLink (e.g. 'printService' above) maps to a single web service.
•However, partner links don't just describe what you speak to, they also can describe how other web service clients speak to you. In the partner link definition above, a 'partnerRole' attribute defines the web service that this BPEL process will speak to. Alternatively, the partner link could have a 'myRole' attribute which would define a web service that this BPEL process implements.
Variable definition
•Variables are used to contain data in BPEL. A variable can either contain an XSD value or a WSDL message. In the example above, a variable called 'hello_world' is declared as a container for WSDL messages of type 'print:PrintMessage'. Instead of the 'messageType' attribute, the variable could have had a 'type' attribute which would specify some xsd simple or complex type like 'xsd:string' or 'xsd:integer'.
•Variables are used to pass data in and out of web service endpoints.
Variable assignment
•Variables are manipulated in BPEL either through use via web service endpoints or by assignment. The example above shows a literal string value being assigned into the variable 'hello_world'. The variable 'hello_world' in this case is a WSDL message with a part called 'value'. The part called 'value' is an 'xsd:string' type. It can therefore have other 'xsd:string's assigned into it, including literal strings.
•The '$varname' syntax used to reference the variable here is standard XPATH expression syntax. The '.' separator is used to specify the WSDL message part. If the variable or the part were an XSD complex type then a '/' separator could be used to specify the sub-element within the complex type (e.g. '$hello_world.value/subvalue').
Web Service Invocation
•The 'invoke' activity in BPEL invokes a web service endpoint. This is where the BPEL process passes the 'Hello World' data (stored in the 'hello_world' variable) to the 'print' web service. The specified partnerLink tells the BPEL engine the address of the web service you want to invoke here. The 'print' operation specifies what you actually want the web service to do and the 'inputVariable' specifies that the input WSDL message should come from the 'hello_world' variable.
•What the web service actually does and exactly how the web service is implemented is not referenced in BPEL at all - all the implementation and definition information is contained within the defining WSDL file.
Web Service (in Java) - WSDL
http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://www.eclipse.org/wsws/choreography/2004/engine/Print" xmlns:tns="http://www.eclipse.org/wsws/choreography/2004/engine/Print" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/" xmlns:java="http://schemas.xmlsoap.org/wsdl/java/" >
WSDL Messages
•WSDL messages are used to specify what the containers should be like that hold data when a WSDL operation is invoked. They are essentially lists of parts, each of which is an XSD simple or complex type.
•In the example above the 'PrintMessage' is defined as having a single part 'value', which is of type 'xsd:string'.
WSDL Port Types
•WSDL Port Types represent the definition of the web service itself. They describe the API or interface to the web service. A port type is a list of operations with 'input's and 'output's. Each of the 'input's and 'output's is a WSDL message that must have been previously defined (although it could have been imported from another WSDL file).
•A WSDL port type operation can also have any number of 'fault' elements. Each of these specifies an error message which would be an alternative to the 'output' message.
•Note that the name specified on the port type does not have any namespace prefix. This is because the port type is being defined here and now and it will inherit the target namespace. The 'printMessage' specified in the operation definition however DOES have a namespace prefix. This is because the printMessage has previously been defined and is being referenced. The 'tns:' prefix maps to the same namespace as the target namespace in the previously defined 'printMessage' message.
WSDL Port Type Bindings
•A 'binding' in WSDL specifies how the web service is actually implemented. Everything up until this point has been abstract and has dealt with only how to speak to the web service. The binding specifies what is on the other side that you are speaking to.
•A web service can be bound in many different ways. The most common bindings for a web service are: oas a SOAP/HTTP web service - whereby some implementation would be listening on a specified port and would accept SOAP messages over an HTTP transport. oas a Java web service - whereby some java class is mapped to the port type and is used directly as an implementation.
•In the binding above, a mapping has been created which specifies that the port type operation 'print' should be mapped to a Java method called 'print'. In addition to this, the XSD type 'string' has been mapped to the Java type 'String'.
•Using this mapping information a Java class can be specified later in the WSDL file as the 'address' of a concrete web service implementation. This class can be instantiated and when calls are made to the 'print' operation, they will be proxied to the 'print' method of this class. In the process of proxying the 'print' operation, any XSD strings will also be converted to Java strings as specified in the binding.
WSDL Service
•The WSDL 'service' element specifies a WSDL 'port'. A single port is an instance of a web service, which is implemented via a particular binding and which is available at a given address.
•In the case of our printout port, we are defining a web service which is bound using the previously defined Java binding and which can be found at the address 'org.eclipse...EnginePrinterPort‘.
•Note that the address is binding specific. The Java binding knows to interpret the 'className' attribute as a fully qualified Java class name and understands how to instantiate the class and proxy the WSDL operations to the Java methods specified in the 'binding' element.
Partner Link Types
•Partner Link Types are actually not a WSDL construct, but a BPEL construct. WSDL was around before BPEL and is purely designed towards describing web services. BPEL however requires that a partner link instance be associated with a particular WSDL port type. In this case there is only one end of the partner link which needs to be implemented - the 'printService' role. It is possible to have two roles in a single partner link type, each of which can be implemented by two communicating web services.
•The BPEL partnerLink definition specified a partner link type for the partner link and also either a 'myRole' or a 'partnerRole'. In our previous example the 'partnerRole' was defined as 'printService'. This is because the BPEL process will be speaking TO the 'printService', rather than acting as a 'printService' which other web clients can speak to (in that case the 'myRole' part of the partner link would have been defined).
Java Web Service Implementation
package org.eclipse.wsws.choreography.jengine.internal.extensions.wsdlbinding.wsif.ports; public class EnginePrinterPort { public void print(String s) { System.out.println(s); } }
The Java class specified in the WSDL 'service' element is the Java class that the BPEL engine will expect to find at runtime. We therefore need to create that java class and fill it with any methods that we specified mappings to in the WSDL 'binding' element (e.g. the 'print' method).
Deploying web service
•Once you have your BPEL file using the WSDL web service description you created and you have your compiled Java class that implements the web service you need to put it all together.
•The quickest and easiest way to do this is to use the 'Dependencies' tab in the Choreography launch configuration.
•Set up a launch configuration to run your Hello World BPEL file and then click on the 'Dependencies' tab. In here you can tell the engine which JARs are required for any user-provided java endpoints. Just click 'Add' and then choose the JAR containing your Hello World Java web service implementation. You should see the JAR show up in the table and you should ensure that the JAR is set to 'enabled'.
•Once you've added the dependency, just run the launch configuration. If you're running a distributed engine the engine will automatically pass the dependency JAR around for use on remote engines (engines on other host machines).
Redistributable Java Endpoint Deployment (Deploying as an Eclipse Plugin)
•If you want to write a Java web service implementation or build up a library of useful services that you want to be able to distribute or send to other people then you can expose dependencies via the Eclipse Extension Point mechanism.
•Just extend the extension point 'org.eclipse.wsws.choreography.internal_WSDLPortDependency' and add a reference to your JAR. The 'namespace' attributes specify which namespaces your JAR is required for. If any of the specified namespaces are used your JAR will be passed round the engine in anticipation of use by the BPEL program.
Posts
No comments:
Post a Comment