SOA Magazine IV 01.2015

design time for BPEL are
vastly improved
The adoption of WLS as the
flagship application server by
Oracle, makes BPEL a lot
more powerful than it was
before,
especially
performance-wise.
in SOA Suite
Oracle Service Bus (OSB)
leverages the former
ALSB and is positioned
immediately as a fullfledged
ESB with lots of
capabilities.
The design-time tool for
OSB is Eclipse-based
(OEPE)
2014 + Oracle BPEL PM and OSB have finally converged into an integrated
developer environment (JDev) with the release of SOA Suite 12c
The concepts of Industrial SOA, Developer Productivity, Mobility
and Cloud Integration drive the improvements in the products,
and have been equally applied to both tools, making them more
compatible and complimentary than ever.
Looking at this timeline, one can easily see where a lot of confusion could have arisen despite
Oracle’s best efforts, especially before 12c:
BPEL Developers that have been working with the tool for a long time just love it, and
have seen the product grow and evolve in an orderly and standardized fashion, with a
constant IDE. This as opposed to an ESB that has suffered many changes so far and has
not been as easy to get familiarized with. This can lead to radical opinions that are not at
all uncommon like: “BPEL is unquestionably better than the Service Bus”, where a sound
product like OSB ends up being disqualified for all the wrong reasons.
SOA Professionals that were already used to work with BEA WebLogic Server, WLS
Workbench, Aqua Logic, Fuego etc., are much more prone to like OSB and understand
its potential and capabilities. They may even find it easier and more dynamic than BPEL
PM due to familiarity with the IDE and web-console. “OSB is just friendlier than BPEL and
Eclipse is a much better IDE than JDev”. It wouldn’t be strange to hear an assessment
like this one from an accomplished developer with a background in BEA technology.
People that are newer to Oracle FMW’s stack, always seem to be wondering which one
of the products is the best alternative, if they are making the right choice and even if
they are over-utilizing or sub-utilizing one of them. In this case, rather than
understanding the products as complimentary to each other, we would be unnecessarily
stressing out and questioning ourselves over which one to choose.
Architects and programmers that used to work with the tools from a different vendor
(IBM, Software AG, TIBCO, etc.) and are now working with Oracle FMW, usually have
trouble identifying the stack at first glance, so they tend to gravitate towards the
product which seems to be more familiar and less problematic to them and stay away
Copyright © 2015 | All Rights Reserved SOA Magazine IV 7