More precisely, I’m interested in models and formats for the description of caracteristics of services such as price, answer time, availability, security, popularity… I can imagine the following use cases for example:

1) Creating an SLA (Service Level Agreement) between a service provider and a user, to express guarantees on QoS and make sure that they are observed

2) Making easier the choice of a service at designtime for a particular task, in order to optimize the ratio cost/QoS

3) Deciding at runtime whether a service should be called, depending on dynamic parameters (e.g. depending on the answer time for time-critical tasks), or choosing dynamically a service among several preselected ones, that fulfill equivalent functions

4) Selecting services automatically (based on their non-functional properties) at designtime to fulfill the different tasks of a business process, and reconfiguring the mapping task/service automatically at runtime to reflect change in the QoS parameters of the services

My first question is:

Which of these scenarios are realistic? Which actually happen in reality?
I guess 4) is unrealistic, since semantic technology is not mature enough to allow automatic matching of services for particular tasks.

My second question concerns the description formats.

Several formats have been developed (e.g. WSLA, WS-Agreement, WS-Policy for Web Services), but as far as I know, none has established itself as a de facto standard.

What formats are used in practice? (I assume that non-functional caracteristics are actually dealt with, since they play an important role) Proprietary formats, that are developed by the ESB vendors? And why isn’t there any widely accepted standard like WSDL and BPEL for functional description?

Thank you for your help and opinion.

Philippe Marcy

This request for help was originally submitted to the Research Assistant on WhatIs.com.

I am facing a strange problem in the ESB.
Here is the issue description.

When a ESB is made to call a webservice, where the webservice throws a RuntimeException inside its implementation, the ESB captures it, wraps it and shows it as ESB Exception.

In this case the SOAP response from the webservice is mentioned below,

<env:Envelope><env:Body><env:Fault><faultstring>Internal Server Error (Caught exception while handling request: java.lang.StringIndexOutOfBoundsException: String index out of range: 10) </faultstring></env:Fault></env:Body></env:Envelope>

As you can see the exception root cause information is present in the <faultstring> SOAP response element and the ESB layer picks this exception root cause, wraps it and shows it as ESB Exception.

Now here comes the actual issue,

We have a third party system expose itself as webservice and we are calling that webservice interface through the ESB.

In case of RuntimeException, the third party (Java Implementation) sends the following SOAP response

<env:Envelope><env:Body><env:Fault><faultstring>Server Error</faultstring><detail><detailedErrorMessage> Any run time exception trace/root cause information </detailedErrorMessage></detail></env:Fault></env:Body></env:Envelope>

As you can see, <faultstring> contains only “Server Error” and the actual root cause is only present in the <faultstring><detail><detailedErrorMessage> element.

As usual ESB layer wraps the information present in the <faultstring> element and shows as “Server Error” in the ESB exception, which is not providing the root cause of the issue.

As per the SOAP 1.2 specification (http://www.w3.org/TR/2001/WD-soap12-part1-20011217/), the SOAP response given from third party is valid.

1) We can have an optional <detail> element inside <faultstring> element to indicate application specific error information
2) Detail element can have zero or more child information element

But ESB does not wraps this root cause of the exception and does not shows it in the ESB exception.

ESB Experts please advice.

Kind regards,
Arun