Ability to easily map changes to abstract Business Process Flows to actual implementation-level data-flows between distributed Services

Traditional process-flow suites are based on the notion of 'control flows' between abstract processes, typically rendered using graphical process-design tools. However, the logical flow-diagram of the business process within the process-designer tool is completely disconnected from the physical realization of the overall business process as it executes across the network, since a single 'activity' within the logical business process may require the flow of data between multiple application instances, across different physical machines. As a result, what one sees logically on the process-flow screen is not what happens physically at execution time.

Fiorano flows follow a different approach, in which the logical connections between Services on the application composition screen map directly to the physical flows of data between Service-instances running on different machines across the network. Thus, what one sees logically is what happens physically at runtime, as illustrated in the figure below.

Click image for a larger view

The figure illustrates an order-processing flow where orders accepted after traversing the ERP system are passed through an XML transformation step and then fed to an SMTP Service for email notification to end-users. The links between the Services represent live message-flows over asynchronous JMS queues and not 'process sequence steps' as in a typical process diagramming tool; as such, the workflow diagram describes the actual business process execution flow at runtime.

This approach has the critical advantage that any changes to the process are mapped directly to the implementation with no additional programming or intervention by technical staff. The workflow process can be dynamically modified at runtime without stopping existing Services or affecting other parts of the flow.

For instance, if a requirement arises to send an SMS message to a set of end-users in addition to also sending email, then an SMS Service can be dynamically inserted into the flow at runtime, and a new link created from the output of the XML transformation Service to the input of the SMS Service, as illustrated in the figure below:

Click image for a larger view

The figure above illustrates several important points:

• the additional link between the XML transformation Service and the SMS Service directly routes a copy of the data output from the transformation Service to the SMS Service in addition to the copy sent to the SMTP Service.
• the additional flow is added dynamically, without stopping the running flow or affecting other participating Services within the workflow.
• the change to the business process is reflected directly in the implementation, without any manual intervention or additional programming; this allows the implementation of the flow to be changed directly and dynamically in response to external business requirements.

The execution model used by current process-driven SOA suites does not permit this flexibility and normally requires reprogramming and manual intervention to implement any change to a business process, increasing the cost and complexity of the implementation and delaying the time to market for solutions. Fiorano message-driven SOA approach frees developers from problems relating to the mapping of business process changes to the final implementation, reducing development and maintenance costs and decreasing time to market.