Ability to easily configure different services and applications participating in a distributed integration

Most process-driven SOA suites do not provide adequate support to configure the services and applications running at the network end-points that actually participate in the SOA workflow. In the typical case, the configuration of each service and distributed application needs to be manually updated within a centralized repository, from where it is manually loaded to compose the integration workflow, leading to increased programming time and maintenance complexity.

Fiorano obviates these problems by allowing advanced customizations options for individual services:

• For each Service or Adapter, the original user interface used for application configuration can be fired up as Custom Property Sheet from within the Fiorano Studio; no additional work needs to be done to achieve this.

Click image for a larger view

The above diagram illustrates the configuration of the Transformation service being invoked from within the Studio. The configuration changes that are made during the design phase are automatically fed to the service at runtime.

• The Fiorano platform allows creation of dynamic ports as well as associated data formats (i.e. input and output assertions in the form of XML schemas) to these ports. This allows the service developer to design general purpose services that can be used in any distributed Application without having to define intermediate data formats.

Click image for a larger view

• The above diagram represents a Business process that uses the Fiorano SOAP Adapter. The data format represented by the input port is available in the designer and is specific to the WSDL that this SOAP Adapter invokes. In this particular case the Soap Adapter has been configured to invoke the ConversionRate() method of the "http://www.webservicex.net/CurrencyConvertor.asmx?WSDL" WebService. The data format used to represent the invocation of this method is made available as the input data format.
• The data formats of any service are also made available to the Studio and other services during Application Composition, so that data-formats across services can be mapped without having prior knowledge of the service functionality or their contracts.

Click image for a larger view

The above figure shows a simple business process that allows user-input via a feeder service to be sent to a WebService. The output port of the Feeder service is connected to the input of the Soap Adapter. The results of the WebService invocation are available in the Display Service.

Fiorano allows a service port data definition to be made available to other services at design time. The Custom Property Sheet of the Feeder Service can extract the schema of the input port of the SOAPAdapter and also generate a sample XML based on the schema.