Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[alf-dev] Fiorano BPEL Engine and Studio Analysis

Hello Fellow ALFers,

 

I recently attended a webinar hosted by Fiorano, an Enterprise Service Bus provider.  I share my thoughts about Fiorano with you below:

 

Fiorano BPEL Engine and Studio

 

Fiorano (http://www.fiorano.com/frontpage.htm) provides a BPEL engine as well as a studio tool for the composition of BPEL flows.  A webinar “Using BPEL for Process Orchestration - involving Web Service and Non-Web Services enabled endpoints” was given on January 5, 2006 by Fiorano.  This commentary is based upon the webinar, documents on the Fiorano website, and correspondence with Fiorano.

 

Webinar Hosts:

Atul Saini, CEO & CTO, Fiorano Software, Inc.
Amit Gupta, VP of Engineering, Fiorano Software, Inc.

 

Attendance: ~ 55

 

Webinar Summary

 

The webinar served as a general introduction to distributed process orchestration and its benefits.  A general summary of the creation and features of BPEL was given: visual studio type drag and drop building of flows, the ability to create logical scopes encapsulating “ACID” transactional semantics, etc.  An overview demonstration of Fiorano BPEL designer was given.  A brief amount of time was spent on the advantages of the Fiorano SOA framework in particular.

 

A striking difference between the Fiorano BPEL designer and other existing tools was the use of pre-built business components (See architecture discussion below) to simply construct BPEL flows.  For example, an oracle database query would be represented by a drag-and-drop oracle icon.  The user then would right click on the icon and configure the query as is done with other visual tools like Visual Basic.  Fiorano provides a wide range of  pre-built components (adapters) including ones for LDAP authentication, CVS, XML transformations, and scripting with Perl/Python, Enterprise Java Beans, FTP, SMTP, etc.   Atul mentioned his goal and it’s worth sharing <paraphrase from memory> “Our goal is to make our BPEL designer like ITunes: you just drag and drop your songs to make an album, no coding necessary.”  Fiorano’s tool looked a lot more like ITunes than any other tool I’ve used, like Oracle Designer or ActiveEndpoints, which use a single standard web service icon.

 

 

Architecture Summary

 

The Fiorano SOA platform can be considered a “brokered peer-to-peer” architecture.  It consists of a federation of peer servers (ALF-speak: tools) and one or more enterprise servers (ALF-speak: event manager + BPEL engine).   Peer servers implement a combination of J2EE Connector Architecture (JCA) and Java Messaging Service (JMS) APIs.  JCA provides a standard for building resource adapters for the connection and manipulation of existing information systems or tools.  JMS supports reliable peer-to-peer communication.  JMS providers allow distributed JCA components to send messages to one another.  Fiorano utilizes its own unique distributed peer-to-peer JMS implementation, FioranoMQ.  Each peer node incorporates a JMS-compliant messaging server.  An enterprise server acts as the central point of control.  It performs logging,  tracks workflow state, stores business process configuration and maintains a component registry, among other things.  Access control lists and LDAP are used for user and service authentication.  SSL-based security is provided at the JMS transport level.

 

Fiorano did not provide details or algorithms on how control is implemented in their system.  However, I would imagine that a business process in BPEL is executed in the same way as any other composite process in a brokered peer-to-peer system (e.g., Napster for mp3 sharing):

 

* The central/enterprise/broker server’s role is to give peers data to find each other, act as a directory service

* In order to find the next peer in the process to send data to, the current peer sends a “peer discovery message” to the broker.

* The broker responds to the discovery message with routing data that factors in load (from snmp montoring, etc.).

* The current peer accepts the discover reply message and performs the routing logic.

* The current peer is configured with action logic for next peer failure or rollback.  Maybe “rollback discovery” message is sent to broker, etc.

* Peers send data messages to each other, not to a central hub.

* Bottom Line: the broker introduces the two peers and then gets out of the way.

 

 

Fiorano Advantages: 

 

* The use of JCA adapters provides a standard way to incorporate non-web service entities, such as enterprise java beans, into a service orchestration.  An existing third-party library of “hundreds” of pre-built JCA components reduces coding time.  (Fiorano claims a library of hundreds, but the designer I saw only provided about 75).

 

* Data flow is peer-to-peer, not from peerA-BPEL Engine-peerB.   Routing information for a particular business process is passed from the enterprise server to the peers.  Peers make their own data routing decisions.  Callbacks can be used in ALF, but I think using the BPEL engine as a data intermediary or a central hub is the most often used design pattern.  The ALF BPEL engine will therefore become a bottleneck as scaling increases.  ALF architecture is hub-spoke, with the BPEL engine the hub.  Control and data packets route through the ALF Event Manager + BPEL engine.  Data from peerA is teased out by the ALF BPEL engine using XPath, it is then sent out to peerB.  (Note: John Streiff of Secure Software and Bob Brady of Segue are working on a design pattern for peer-to-peer data flow, spawned from an ALF POC use case).  Fiorano splits the data traffic amongst the peers and limits control to the enterprise server.    

 

* SSL data flows are inherently available via the use of a JMS provider for messaging.

 

* Interoperability:  a JCA component in a BPEL flow can be right-clicked and exported as an axis web service.  (Not sure how good the translation is, though).

 

 

Fiorano Disadvantages:

 

* Fiorano’s existing adapters not open source so can’t build upon what has already been done.

 

* The broker (Fiorano enterprise server) is not open source.  While some standardized parts of the API can be “discovered”, I believe there is a scarcity of docs that would assist one in manipulating it.  Thus, certain customizations may be difficult or impossible to implement.

 

* Monopoly: unaware of any other BPEL-based Enterprise Application Providers utilizing “brokered peer-to-peer” architecture.  Tifosi ESB is a predecessor if Fiorano, as John Streiff of Secure Software pointed out.  If Fiorano goes out of business or ceases support for some products, this could spell trouble.  Customizations may not be readily portable.

 

Note: Fiorano vs. ALF is not a “fair fight”.  Fiorano is designed for an Enterprise Bus, while ALF is to be used on individual desktops.  Intuitively, the broker in a desktop application integrator should expect at least an order of magnitude less messages/sec than what is required for the broker supporting an entire “enterprise”.

 

The above views are solely my own and not that of Segue Software or the ALF project.  I thank Mr. Srinivas Tati of Fiorano for reviewing these comments before the post.

 

 

`


Back to the top