Ability to easily debug the flow of data across multiple distributed applications

Most real-world integrations involve the exchange of data between applications distributed across a network. During the course of an implementation, it becomes necessary to debug the data flows between distributed applications. Current process-based SOA suites, mostly based on centralized process engines, provide little or no support for debugging flows across applications running at the end-points of the network.

Fiorano's Message-driven SOA approach simplifies distributed system debugging by

• allowing live data-flow breakpoints to be set across distributed services, and
• enabling dynamic changes to log and trace levels within Services at runtime.

Both these features are enabled by Fiorano's unique distributed, message-driven architecture, as explained in greater detail below.

1. Live data/message-flow breakpoints.

On the Fiorano platform, data exchanged between two distributed services always passes through the local Fiorano Peer Server to which each individual Service is bound. The Fiorano Peers implement a store-and-forward mechanism for data routing. When a breakpoint is set, the data is stored for viewing until the end-user decides to either remove the breakpoint or continue step-through processing, as illustrated in the figure below.

Click image for a larger view

In the application above, a breakpoint has been set between the CRM and ERP Services which run on different machines. Users set the breakpoint (assuming they have the appropriate permissions) by simply right-clicking the route and selecting the 'Insert Breakpoint' option.

The figure above displays an order captured as it exits the CRM system in a live workflow. This data can be viewed by the end-user/developer and passed on for further processing as required. No manual programming or extra effort (other than using the point-and-click breakpoint and viewing menus) is required.

With current process-server technology, the capture of such live data-flows is impossible; anytime a data flow needs to be debugged, the individual Service needs to be recompiled with 'print' statements manually inserted into the code. If the Services execute on different machines (the typical real-world scenario), the end-user needs to painstakingly view manually configured log files on different machines - a cumbersome, time-consuming and error-prone task. Current process brokers restrict debugging to the flow of control information within the broker only, providing little or no support for debugging the flow of data across participating Services in a distributed workflow.

The Fiorano SOA Platform^® bypasses all of these problems, allowing breakpoints to be set up on any number of routes in a Fiorano application.

2. Dynamic logging and tracing for remote Service debugging

The Fiorano platform allows trace levels within a Service to be dynamically modified at runtime. For instance, if the end-user suspects that a particular Service has a problem while running as part of a live flow, then the trace-level within the service can be altered without stopping either the Service or the flow. Increased trace-levels result in more logging and tracing information being published by the Service, which is captured within a Service-log for each individual Service and easily viewable from within the Fiorano Studio or on the Fiorano Web-based Dashboard, as illustrated in the figure below.

Click image for a larger view

The figure illustrates the result of increasing the trace-level of the Display component for Accepted Orders increased from severe to All. When the log level was severe, very little logging information was written to the log-file; when the trace-level was increased to all, the actual message that was fed as input to the Service was written out to the log-file. The developer of the actual component uses the Fiorano Tracing and Logging API to write out different trace messages to the log-file depending on the value of the Trace-levels at runtime. This way, the end-user gets additional help in debugging the application at runtime without stopping any particular application components.