Creating Web Services in TIBCO
Web service is a standard and reliable way of communication between two applications over the Internet. It is a secure way of exposing functions that a client application can use without revealing the internal mechanism of the providing application. For example, you want to get a list of all items from a store which have a name that starts with letter A. You send a request to the providing application specifying the operation and you get a response that is the list of all items. You are not certain whether the records came from a file, a database, or another cloud application. As long as you correctly specify the request in the format expected by the provider, the rest of the details are unknown to you. This is how the exchange of information works with web services. A protocol agreed by both the provider and the client needs to be established. The protocol is the set of rules the caller of the web service needs to follow in order to invoke the web service successfully. Most common of which is the SOAP or Simple Object Access Protocol. Next, you have to create the definition of the protocol which consists of the structure and format of the messages, the port type or technology to be used to transport the messages (usually HTTP), and the name of the operation being invoked. Web services can support multiple operations over multiple port types, and this is what makes web services quite scalable as well. The definition is more commonly known as WSDL or Web Service Definition Language.
Thus said, you need three things to create a web service: the abstract WSDL, the endpoint type or transport, and the process implementation. The WSDL is composed of input, output and/or fault messages, one or more port types, and one or more operations for each port type. The message schema can be a complex type or element. Now, let's create a sample web service. This web service would accept two numbers as input, and returns the sum of the two numbers as output. It also returns two types of fault messages if the input are not valid numbers, or if any general error occurs. First, you may want to create the XML Schema as follows.
Create a WSDL shared resource, and add four messages and one port type into the WSDL. Add a new item into the part table and specify the type or element referencing to the XML schema that was previously created.
Next, you would need to add an Operation into the PortType. Add an item into the Message Table referencing to the Messages that were previously created. You have input, output, and fault as message kinds.
Now, you need to create a Process Definition that uses the input, output, and fault messages. To do that, specify the content as WSDL message in the Output Editor of the Start activity, Input Editor of the End activity, and Error Schemas tab of the End activity. We have a very simple example that checks if any of the two inputs are valid numbers; otherwise, the process will throw an exception that has an errorCode as NaN. This is checked on the error transition from the Catch activity which captures all exceptions. If the errorCode is not NaN, a general exception is thrown.
You also need to create a HTTP Connection shared resource specifying the host, port, and server type.
Thus said, you need three things to create a web service: the abstract WSDL, the endpoint type or transport, and the process implementation. The WSDL is composed of input, output and/or fault messages, one or more port types, and one or more operations for each port type. The message schema can be a complex type or element. Now, let's create a sample web service. This web service would accept two numbers as input, and returns the sum of the two numbers as output. It also returns two types of fault messages if the input are not valid numbers, or if any general error occurs. First, you may want to create the XML Schema as follows.
Create a WSDL shared resource, and add four messages and one port type into the WSDL. Add a new item into the part table and specify the type or element referencing to the XML schema that was previously created.
Next, you would need to add an Operation into the PortType. Add an item into the Message Table referencing to the Messages that were previously created. You have input, output, and fault as message kinds.
Now, you need to create a Process Definition that uses the input, output, and fault messages. To do that, specify the content as WSDL message in the Output Editor of the Start activity, Input Editor of the End activity, and Error Schemas tab of the End activity. We have a very simple example that checks if any of the two inputs are valid numbers; otherwise, the process will throw an exception that has an errorCode as NaN. This is checked on the error transition from the Catch activity which captures all exceptions. If the errorCode is not NaN, a general exception is thrown.
You also need to create a HTTP Connection shared resource specifying the host, port, and server type.
Finally, you need to create a Service shared resource. Add a new interface referencing to the WSDL. In the Operations tab, specify the Operation Implementation referencing to the Process Definition previously created. In the Endpoint Bindings tab, add a new endpoint, specify a name, and the endpoint type as SOAP. By default, you have PortTypeEndpoint1 as name. Specify the HTTP Connection as transport, and optionally you can modify the Endpoint URI.
If configured correctly, you will see the following under the Overview tab.
We can now package the web service in an EAR file and deploy it in TIBCO Administrator. But we don't have a resource provider yet that will return the concrete WSDL of the web service. This can be done by creating a process starter that accepts a request and returns a response from RetrieveResources activity. We can also use the built-in feature of TIBCO Administrator to do the same. As you would notice, we have builtinResource.serviceAgent starter process for every deployed application. This is primarily used to retrieve the WSDL.
To do that, you have to set the following properties before deploying the application.
bw.platform.services.retreiveresources.Enabled = true
bw.platform.services.retreiveresources.Hostname = localhost
bw.platform.services.retreiveresources.Httpport = 8010
You can test this by accessing http://localhost:8010/.wsil on your web browser. You will get an XML response with the exact location URL of the WSDL.
thank you
ReplyDeletego langaunage online courses
ReplyDeleteazure online courses
java online courses
salesforce online courses
hadoop online courses
Data Science online courses
linux online courses
etl testing online courses