Fiorano Products
FioranoMQ®
Fiorano Integration Platform®
Fiorano ESB®
Fiorano Cloud Platform®
Fiorano B2B™
Fiorano API Management  
Fiorano Mobile Integration  
Fiorano Microservices  

 

United States Coast Guard

"We found that developing and deploying new processes, as well as modifying and redeploying existing processes,..." Read More »

"For the United States Coast Guard, adopting enterprise-wide SOA as part of our Enterprise Architecture Framework was a necessity to deliver..." Read More »

"As very active users of Fiorano's latest software, we are delighted to find that we have become masters of reuse of components within our projects..." Read More »

Message-Driven SOA - Fiorano SOA Platform®

Mapping logical designs to physical implementations: composing implementation-level message-flows between distributed application instances

Almost all integrations require data to be routed in some order between different applications running on distinct machines in a heterogeneous network. Such integrations are surprisingly hard to set up within existing "process driven" Integration Broker suites, since such suites provide no in-built GUI tools to automatically configure the flow of data between physically executing application processes; rather, all actual data flows have to be manually configured, typically using standards such as JMS, or other messaging middleware, increasing the time and complexity of the implementation. For instance, in a typical scenario, "topic-names" need to be configured for all data flows, and name-clashes need to be manually detected; developers have to understand low-level messaging concepts such as "durable subscriptions, persistent and non-persistent messages", etc.

Fiorano's Enterprise Service Bus™ isolates developers from these low-level details, allowing the direct routing of data between distributed application components using point and click tools. For instance, consider the example below

This figure illustrates a transfer of data from an Oracle database running on a server, to an SQL database running on a different server on the network. An XML transformation is applied before the data extracted from the Oracle database is inserted into the SQL database. There are several important differences between this figure and the normal 'process flow' drawing seen in traditional broker suites. In particular:

  • The lines between the components are real JMS queues and not just logical connections between abstract processes; these queues create a reliable and secure communication channels between applications distributed across the network. These queues are set up dynamically between distributed Fiorano Peer Servers, to which individual applications are connected. Programmers do not have to manually set up queues and other middleware structures as with process-driven platforms.
  • By adding more connections (or altering existing ones) between the ports of the Services within the Fiorano Studio, new queues are automatically and dynamically set up, without any programming or manual intervention, dramatically reducing the time it takes to create new workflows or modify existing flows of data within a complex integration.
  • Changes to message-flows can be affected in seconds and require no low-level programming, unlike existing process-driven implementations in which changes to the high-level 'process diagram' require painstaking low-level programming changes.
  • Parallelism is in-built into the infrastructure: messages flow directly between individual components running on different machines across the network; unlike current process-driven approaches, data does not have to traverse a centralized point because JMS queuing is in-built into the Fiorano Peer Servers at the network end-points.
  • The components/services represent live applications which are directly connected to each other via JMS queues; for instance, the component marked "OracleOut" is actually a database adapter that extracts data from an Oracle database running on a given server; the name of the server can be easily configured using property-sheets as illustrated on the LHS of the figure.
  • Components can be dynamically deployed on any machine across the network by simply changing the name of the server on which the component runs, using a nodelist dialog from the property-sheet for the component.

By combining distributed infrastructure at the end-points of the network with tools that give the developer a view of available components on the network, the message-driven approach of the Fiorano Enterprise Service Bus™ allows a direct visual composition of the actual implementation. What you see logically is what happens physically. This reduces implementation time dramatically since developers are completely shielded from the details of low-level middleware programming.