I'm going to previous topic here…
I am currently working on a pretty simple systems integration task: read from a small bunch of database tables, munge the data and call a variety of webservices. Fundamentally a simpler integration problem than the exemplar for Spring
Integration I worked up before. Pretty simple with Java and a framework like Spring Integration or Apache Camel; undoubtedly even simpler if I could add Groovy into the mix.
Organisation says: "Thou Shalt Use Oracle Service Bus."
Ever heard the joke about regular expressions: Once upon a time a programmer had a problem. He decided to solve it using Regular Expressions. Then he had two problems.
Welcome to my world (with an OSB flavour) :-)
I'll try and capture a few thoughts and experiences below.
It is very rare that I react so strongly against a technology….can't really think of another example. I'm usually pretty gung-ho and even suffer from odd breakouts of evangelical fervour. I can even find a
place for UML in the nerd-ish pantheon :-) For this product all bets are off. I'm struggling to find a silver lining in the cloud.
I hope that if I break things up into small doses, you won't break down with sympathy tears…
Why choose OSB vs a BPEL implementation? BPEL has an OASIS standard behind it, is the richer language, is more mature and more expressive, has better
tooling, has multivendor support, can deal with state, timouts and long-running workflows…all the things that one needs in an integration setting. OSB does practically none of these things, so what's it all about, Larry?
Ahhhh…perhaps that little 'multivendor' word gives us a clue? "So young to be so cynical", I hear you say.
I have heard it said that OSB is "high level" and the alternatives like Apache Camel and Spring Integration are developers tools and as
such are too "low level" to be true solutions. Sigh. I thought that old argument for CASE was put to bed long ago. It's sad perhaps, but you still need
developers to do complex development. Don't believe me? Take a look at the average spreadsheet and then tell me how appropriate this "end-user engineering" idea is.
The task is not to find the most abstract or pretty tool but to put into the developers' sweaty hands the toolset capable of getting into the gnarly nooks and crannies of a problem space and still come out on top. Next time you hire a
carpenter or electrician or plumber, take a look into his/her toolbox. It won't be pretty but it will be varied and capable. I'll bet that it took the tradesperson quite a bit of training and experience to work effectively with everything
in it too…there is no magic bullet.
"Stored Procedures migrate to Session Beans" used to be the J2EE catch-call (for very good reasons, IMHO, YMMV). In my current OSB-oriented project, this
seems to have become "Let's do as much as possible in stored procedures because it's too darned painful to even consider otherwise."
This is really rubbing against the grain!
It's interesting that these days, discussions regarding Systems Integration always bring up the "VETRO pattern": Validate, Enhance,
Transform, Route, Operate. This is great, as far as it goes. In my experience however VETRO is by far the easy side of SI. Prising and cajoling the requisite data out from the various niches, repositories, formats, access methods, security
regimes, etc. tends to be much more tricky and is a necessary prerequisite. It's sad, but I can't think of a catchy management friendly phrase for all this nasty boring legwork. The term "Data Mining" is already taken, darn it! Regardless, I'm absolutely positive that no pretty picture is going to encapsulate the true reality of the SI task. I'm all for aspiring to
do better but hey…even in Star Trek they sometimes need to reverse the polarity of their polaron fields in new and untested ways, and when they do
they don't draw pretty pictures but rip off the access panel to their nearest Jeffries tube, get down on their hands and knees and crawl.
In the integration community these days, it is common to tip the hat to Gregor and Hopke's Enterprise Integration Patterns work. The book sits on every "Integration Architect"'s
shelf and provides a useful reference work. It's very tempting to imagine architects sitting around designing systems using Star Trek-style dialog: "We'll hook this Incoming Polling Consumer to this Aggregator, then to this Resequencer
before Routing the incoming message to the outgoing Messaging Gateway." Leaving aside the issue that this scenario and reality correspond to each other in roughly the same way that Star Trek corresponds to the NASA, let's take a look at
OSB's support for patterns.
There's a few: various species of polling consumer, a bit of routing, some basic message transformation and then…you're on your own.
It is extremely cumbersome to do anything other than broad brush-stroke flows…I feel that I am being forced to spatter stored procedures, triggers, DBMS_ALERT
calls and odd little support tables throughout my database, along with (as simple as possible) snippets of Java in the OSB application in a desperate attempt get OSB to do something useful.
I frequently repeat the following mantras: "OSB is just a dumb pipe" and "Let's keep OSB as dumb as possible."
I simply can't bring myself contemplate the effort needed to deal with all the callouts to all the Java objects needed to deal with any sort of sophisticated API or complex processing.
I'm pretty sure that I could replace much of the mess that has grown up as a result of OSB's pathetically limited capabilities with a couple of standard Java collection classes mixed in with a decent polling implementation such as in
Apache Camel or Spring Integration.
Compare and contrast with Camel, which has direct support for about 50 of these patterns. That previous link also provides links to a nifty library of icons for
them all, in various formats…very useful. Spring Integration also directly supports several of these patterns "out of the box."
Seems to me (cynic that I am) that OSB successfully implements just two patterns: the "sell copies of Weblogic" pattern and the "extract lots of money from customers" pattern.
What goes into OSB, stays in OSB. For all but the simplest bit of work one typically needs to develop additional helper tools/applications/scripts, etc. Tools like JPA and Camel are by design flexible and make it possible to create
these tools by reusing elements of the 'main' development path (a part of the object model, or a transformer, say). OSB does not…quite the reverse, in fact (it is very much [Oracle Weblogic] server-side-only, for example). Any
'investment'/effort put into OSB is in reality not going towards infrastructure development but is instead just bringing into existence another closed, siloed system. An instant legacy problem. The only investment that one does
with OSB is investing into Oracle's share price. This is unacceptable. It need not be this way. We have tools available that can be used to enhance our infrastructure, not fragment it, that can work with our Objects and APIs, not
make an all-out (but subtle) effort to supplant them.
OSB has an "everything is XML" approach (OK I acknowledge that it's slowly divesting itself of this, but there's a way to go yet before the alternatives are anything
approaching useable). I like XML as much as the next guy, probably more; it's a great interchange format, but requiring it for all internal channels as well is a bit much: one ends up touching the in-flight data
(translating/extracting/recomposing) too many times. With JPA and JAX-RPC, one can in essence and after a little housekeeping do:
The equivalent OSB (with Database JCA Adapters in place) is horrendous, simply horrendous!
Don't get me started on the Database JCA Adapters! They are supported in OSB but cannot (yet) be created via OSB's Eclipse-based tooling. This means that one is required to use JDeveloper 11g to create the adapter bindings appropriate
for the underlying databases and then manually copy the resulting batch of files (a group of up to 5 files for each table being used) into the Eclipse project. Automate those build steps, I challenge you!
It gets worse: an OSB proxy created to service a JCA adaptor is extremely fragile: changes to a database table requires a regeneration of the adapter files (or more like a recreation from scratch…manual click, click, clickety, click). Any slight change to an adapter forces a regeneration of the associated OSB proxy…which blows away any business logic (== pretty drawing) associated with the message flow.
One is then forced to recreate the flow from scratch by hand (more manual click, click, clickety, click). Ghastly. Tedious. Error prone. Nonsense. It's in the nature of the systems integration task that changes happen often. One gets tired
of (re)drawing OSB's pretty pictures very quickly, let me testify.
One gets around this by splitting a flow into upper and lower levels: the upper level simply forwards to the lower level with as little effort as possible. The lower level flow does all the real work and is unaffected by changes to the
adapter or upper level flow.
Some things might get cleaned up in the future (Oracle/BEA's XQuery implementation is curently only partial [no module support], for instance) but I'm not holding my breath.
There's even worse: OSB seems to confuse database polling frequency with database locking time: tell an adapter to poll every 10 secs and it seems to go away and lock all other processes out of the
database for the next 10 secs, polling away in splendid isolation. This can lead to performance issues and effectively ties all adapters to a very short polling cycle. That's a
bit of a surprise and can lead to some subtle 'issues' arising, let me tell you…
I a great fan of these adapters…I simply love the way that they get 'stuck' every now and then (often when the underlying database is itself under some load). They often get 'unstuck' as well. Usually…sometimes…. I love going into
production with systems that 'usually' work OK (that was sarcasm, in case you are sarcastically-challenged :-)).
OSB is completely stateless. To create something as simple as an "I have sent out a total of n messages" counter requires introducing a Java callout
with an absurd amount of glue coding. Some things simply aren't worth doing…
A good tool makes it easy to develop clear, relevant solutions close to the "problem space" without unnecessary obtuse 'ceremony' getting in the way. OSB is not such a tool, sadly.
You know the acronym DRY? Well, forget it!
One can try to apply a workaround and achieve a degree of DRY-ish-ness but the spaghetti flows that result aren't worth the hassle. Here's the issue: the process
of munging a solution to fit in with OSB's way of doing things results in a horrid unclear mess. Really. The cure ends up being worse than the disease: the resulting diagram becomes simply unintelligible…much less clear than the
equivalent plain-old-text representation in Java.
Not convinced? OK, Mr./Mrs. Smarty-Pants: what values are being assigned and logged here?
To find out, you have to engage in a storm of clicking through the pretty icons and juggling Eclipe's idiosyncratic idea of view focus control. After a while you will find that your wrists need to recover from their little workout,
giving you time reflect on the fact that you'd be able to find out instantly when perusing a textual source, no clickety-click investigation needed. There's a big difference between reading and scanning code;
oftentimes the latter is what we need to do…and quickly.
On a related note, it's hard to make the correspondence between trace logging output and the actual code. Consider, for illustration, that all service callouts have the same fixed label: "Service Callout." It can be slightly awkward to
pin down which "Service Callout" just logged something.
While it may be appealing to the naive or hopeful, Mouse-Hand Engineering…drawing pretty pictures…doesn't really ease the development task. That's just the nature of our complicated world…sad, but that's life.
(You know, I was going to use the phrase "Right-Hand Engineering" but felt it was slightly too risque ;-))
(And don't get me started [again] on UML, I've already thrown it a bone once in this posting :-))
Oh for the ability to "comment out" or bypass sections of a flow! It continually frustrates me that in most so-called modern languages, one cannot nest comments (something that Pascal had all worked out), but OSB drives me potty. Would
the industry (yes, even this fad-ridden, silver-bullet-seeking, flavour-of-the-month driven IT industry) accept a textual language without a commenting convention, I wonder? This issue also relates to testing (see below).
Here's a cute feature: every message that enters the system is given an unique message ID. Except that it isn't actually unique, darn it! As a message is passed between services, each service allocates it a brand new ID. This is dumb,
dumb, dumb! One is forced either to fiddle with and refer to header fields all the time, or do what I did and use a message's database-allocated synthtic (surrogate) primary key as the message ID. Way to make it easy for us, OSB!
Error handling is broken. I know I'm being picky but something a little more than "something bad happened somewhere in some downstream flow or
other" would be helpful. There are rumors of patches for this issue; good luck is all I can say.
One can't get at system parameters/classpath resources, etc. without falling back to Java. To do anything slightly out of OSB's (putative) "sweet spot", one falls back to Java…so why not use a Java-based framework?
Testing. Ha ha haaaah!
How does one go about testing a drawing? This is probably the #1 question on the OSB forum.
Yes, the OSB console web application allows one to "test drive" the various componentry. Surely we can do better than hand-driven integration testing, however. Tools like citrus
and SoapUI come close but don't ring the bell for me…
Mark Smith gives an overview of the ridiculous process of creating testing stubs/proxies and the associated rewiring required when testing a proxy
service's flow. If a flow must be progressively rewired in order to be 'tested', is the flow actually being tested, I ask (rhetorically)?
Unit testing XQuery transformations should be simple, but isn't…there's no doco and a closed implementation. Writing testing flows in OSB seems ridiculous to me. Unit tests shouldn't need a service bus and you shouldn't be forced into
integration-style testing for your atomic code units. Something smells quite wrong here.
I'll probably pontificate on this some another time…for now, its in my "tried and failed to do something of value for the project" basket.
It may be a little churlish of me to point this out, but the XQuery editor always has some reason or other why it won't let you do something…even dragging a dateTime onto a String:
The editor gets in the way many more times than it helps. As Roger van de Kimmenade also noted, it can get so completely messed up
that it can't do anything except show a blank screen. It can sometimes (usually when opening a file) even rewrite a transformation as it sees fit…blowing any hand-made changes away in the process. This is problematic 'cos (as I have just
pointed out) you have to do pretty much everything by hand. You Have Been Warned (hmmm…maybe Oracle should trademark this phrase. Hey: maybe I should…).
I particularly enjoy the fact that-although OSB is BEA Weblogic Server at its heart-OSB can't readily create HTML. "Hang On a min., " you say "isn't HTML just a variant of XML at heart? Surely OSB should be happy with HTML!" Surely.
After I asked roughly the same question on the OSB forums, Manoj Neelapu was kind enough to work up a way of doing it. The eventual solution requires a gnarly combination of two techniques, however.
Remember VETRO? In my current project, I have to process an incoming message which is defined by an XSD file included into an XSD file that is referenced by the service's WSDL. If you followed that chain without getting confused you are
doing better than OSB. Because of the include chain, OSB's validate step won't find the message type. The WSDL and XSDs are from a third-party vendor and so I'm loathe to touch/munge them.
This means that OSB is only capable of '…ETRO.' Quality stuff, this!
Deployment is 'strange' as well. Took me a while to find the up-to-date doco telling you how to script the creation of an OSB domain from scratch.
There are a few helpful posts out there telling you what to script after you get this beastie but so far this in in the same basket as XQuery unit testing. Seems to me that
"Thou shalt not apply your existing deployment plan to a new domain." Not if you want to keep your sanity, anyway.
In no particular order:
- Eclipse IDE console's "scroll lock" doesn't work. You search through a long log trace looking for something and then-just as the line appears-the console refreshes, leaving you staring at the latest line to be added. Good grief but this is frustrating! I like Eclipse, have used it lots over the years (by choice, note!) but in this incarnation it is simply hateful, darn it!
- From the sublime to the ridiculous: sometimes the console doesn't actually deign to show anything at all. Many times I hear: "Bob. A message has gone missing again." I now know that 9 times out of 10 what has actually happened is
that the Eclipse console is blocking the server as it is trying to send debugging to System.out (I'm not directly using System.out please note…I'm not that naive). A quick keypress into the window unfreezes everything and Lo! I
have miraculously found the missing message. It's strange but even miracles can get old, fast.
- JDeveloper periodically corrupts a project. One may work on a project for a week and then BAM! it fails to load up in the morning (this may be a local SOE issue but its still frustrating and I don't get hassles from any other
- There exists a fairly small user community. The Oracle forums are really not that active or useful. Apologies to those members out that that have tried their best
to help me out…this comment is not intended to be an indictment of you guys (I AM grateful, really, I AM!). I am just trying to identify issues caused by community size & experience.
- OSB's Eclipse tooling tries to deploy all the projects it can find…even if they are closed. This can lead to weird situations. You Have Been Warned…
- It's not just the older versions, either. In the latest update, Eclipse seems to take ages to realise that a change has happened and that a deployment refresh is needed…and then sometimes fails to see that a redeploy has
- …and what has happened to Weblogic? Even a simple change to a datasource's configuration now requires a reboot. Shocking!
- The weblogic log browser is…'idiosyncratic.' You can be eagerly following a chain of logging messages…clicking from one page to the next…homing in on the cause of all life's woes…feeling the expectation of a debugging session drawing
to a close welling up inside…and then bloody thing will decide to show page 0 again. Just for shits and giggles, it'll be so confused that you will have to start a new web
browser session. You quickly learn to munge the parameters displayed in the address bar, not that there's anything wrong with that, of course…
My colleague David has introduced me to a term that sums all this up nicely: complification. To complify something is "To dramatically increase the difficulty of something for no good or apparent reason."
Of course, I am an ingenious guy and I can pull some sort of solution to all of these things out of my expansive…err…mind. AFWSE is also my friend in many situations (but see my earlier comments
regarding the size and vitality of the user community).
I am sure that you, dear browser, also pride yourself on your ingenuity and proven ability to wrestle a recalcitrant universe into shape.
This, Of course, is also the trouble! Ego comes riding into town…
My (rhetorical) question is: should we have to be so ingenious? Especially when many of the 'issues' are those that OSB in and of itself causes?
So here we are: back to the title…I can't help but imagine that somewhere within Oracle there is a poor, downtrodden group afraid to tell King Larry that OSB just doesn't make sense.
Guys, let me try. I'll be the plucky little boy from the crowd (I hope that remember your Hans Christian Anderson fairy tale?) that doesn't understand he should be
following the party line…
Larry, listen up! In my (not-so-)humble-opinion there are much better ways to skin the integration cat that what I see here. OSB isn't a worthy member of your product lineup. Don't lead your
customers down this particular garden path. The last decade has seen some good steady quiet progress in areas such as testing, interoperability and frameworks (to name but a few), please don't set this industry back to the pre-2000s with
this regressive, locked-down, locked-in, half-baked 'thing.' Please!
Phew! Said it. I Feel much better now!
Lest you think that I am losing it, I'm not the only person saying this sort of thing.
You know…the story doesn't really say what happened to that plucky little boy from the crowd. Maybe he was showered in riches for saving the King's honor. More likely, he was beheaded for embarrasing the high-and-mighty.
Some almost immediate-and pretty much equally jaundiced and cynical (although slightly more generic)-reaction.
Thank you - a rather excellent way to start my day :-)
Now let me also share something. You may or may not agree. Oracle makes a lot (LOT) of money by sending in the consultants.
The consultants get called in when the local team comes up with zip because it's so damned hard to get the Oracle tools to work.
Consultants are charged out at $2k / day and become an on-going income stream as the client needs lots of refresh (code change) activity.
It serves the likes of the big consulting houses to have internally trained specialists who know nothing else but these ghastly tools.
In fact some outside consultants cash in big time by spending all their time focusing on nothing but - discovering all the tips and tricks from the Oracle paid guys.
I think this has been going on since I first entered the industry and it's a great model. Not for the industry nor the profession, but for money making monsters of which Oracle is one of the best.
There, my take…take it or leave it, but it's ultimate raison d'etre of the Closed source movement and some clients just gravitate to it…
I'll leave the sender anonymous…no sense in taking other people's career down alongside my own ;-)