Thank you for the free (as in beer, which was also supplied :-)) workshop on Oracle Service Bus.
Thanks to Campbell James and Jon Gooding. Much appreciated, guys!
In these dire economic times, it is good to be able to keep abreast of the latest and greatest without having to put a mortgage on the cat.
It also makes good sense for Oracle, of course: "getting the word out" must be much harder in times of tight budgets.
I now have a clearer understanding of OSB's capabilities (I knew it when it was just "Liquid Data", all those years ago) and how to work with it in Weblogic Workshop. It is a powerful tool, that one can be quickly productive with.
What's not clear to me, however, is the future for the product, and indeed of much of Oracle's middleware product set.
Despite the best efforts of James and Jon I can't shake the feeling that now is not the time to jump into the Oracle waters. It seems to me that it would be best to wait until the various Oracle and BEA offerings have been merged into a
coherent product set, with a clear direction.
I'm still wating for the axe to fall on JDeveloper (to take one example). I know that Oracle says it will 'always' be there but I can't help shake the feeling that they will eventually "jump ship" for Eclipse; they have the technology and experience, so it all comes down to money and supporting one (merged) product is cheaper than supporting two same-but-different ones.
On another (but related) topic: I am conflicted!
I am well aware of the persistent comparison between 'real' engineers, who use diagrams as a matter of course, and software 'engineers' who (it is often said) wouldn't know an engineering diagram if one got wrapped around their
knees.
I too was once seduced by the idea of "drawing software" and even had a mild flirtation with CASE tools many years back.
Thus, part of me says: "Great! This is the way to move the industry forward; all those VB programmers will take to this like ducks to water and we'll be churning out bug-free software Real Soon Now."
The other part of me says: "Do I really need GUI tools. I mean what do they actually add to the equation? And what about the risks of RSI, I ask you!"
Case in point. What does this:
Add over this:
...
if (condition)
{
params = getParams();
results = serviceCallout(params, request, response);
handleResults(results);
}
else
doSomethingElse();
...
(yes. I know this is vague!)
I think that there is a difference between what the 'real' engineers need and our requirements: circuit layout diagrams, architectural drawings, etc. are inherently dimensional. Software is not. Visualiation is an extremely
useful tool (take GUARD, for instance; or this little beauty)
but I'm not sure that visualisation is what it is all about, here.
The cynic in me mutters "pretty pictures for pretty dumb managers", but I try and stifle that little voice…
[edit]
My (sadly only for a brief time) ex-colleague 'K' makes the following very valid points:
One other thing to consider is that it throws two fingers up to object
orientedness (is that a word?). And that is what bothers me the most.
Also, how you track and manage change will be a nightmare. If you
change the type of variable, you have to dig deep into the diagram to
see it.
I didn't say it, but testing is also something that gnawed on my worry-bone…