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.
`