Here’s a great post that states the obvious: Homegrown solutions: The good and the bad.

Gotta love an article that includes stuff like:

“…nontechnical management gets the heebie-jeebies when presented with a plan that includes homegrown, self-supported solutions. Many executives would rather have a passel of slightly technical folks and vendor support than highly skilled and highly paid technologists to keep the trains running on time. … you may be able to measure your savings in terms of the electrical bills and IT payroll, but the hidden costs can make those savings disappear. … When you need to “make things happen,” you simply can’t — you get stuck in months of apathetic meetings and general buffoonery from every angle. That’s not even touching the problems inherent with outsourcing help desk and general computing tasks.”

I wish this didn’t match my experiences so exactly, I really do!

This course is “Tiliting at Windmills 201.”

I’m your lecturer Don Quixote.

We will begin with a snap quiz.

You have two well-established computer systems A and B. In accordance with its original design system B makes use of a small but signifiant proportion of system A’s schema. It is proposed that system B should be enhanced, which will require accessing a few additional tables from system A’s schema.

Do you:

1. Go ahead and grab the data you need, along the lines of what is already being done?
2. First espouse the concept of a “common integration language” and then promote the idea of linking the two systems together via some to-be-announced-Real-Soon-Now “integration layer”?
3. Place a huge purchase order for the latest silver bullet product espoused in last month’s “What’s Next! A busy CIO’s guide to the latest trends in ICT” magazine, mandate that this product is now the “Enterprise Standard”, and require systems A & B should use this product for their new “Enterprise-level Interactions”?

I’ll give you a few seconds to think about it….

…time’s up.

Now: those of you who answered ‘A’…

Sigh. Did you learn nothing last year? Don’t you remember “Complification 101″? Don’t you remember the Three Principles: ‘Complicate’, ‘Obfuscate’, ‘Procrastinate’? I am disappointed in you…you’ll never get ahead in today’s enterprise with a can-do attitude like that.

OK. Who answered B?

That’s more like it! Glad to see you ‘B’s were paying attention in “Elementary Enterprise Operations 101″ last year. Remember that this alternative gives you the advantage of being able to wander around the whole organisation declaiming “Integration Layer” at every opportunity. This may not constitute a successful approach to building working software but it sure is a great way of building visibility with The Powers That Be…and what’s more important, after all, eh?

NO, Mr. “I answered ‘A’…I thought it was all about building software to do something useful”…it isn’t. Really! Maybe you should be rethinking your career path while the year is still young?

Did anybody answer C? Ah. you must be from the “Software and Sales” double degree. I see bright futures ahead for you guys. This is the way to go! Even you ‘B’s need to take notice here. Maybe even consider taking “Hype and Hysteria 204″? There’s always another silver bullet just around the corner and you don’t want to miss out on the opportunities.

Who’s left? You over there…you’re a “Software Law” student aren’t you? Kibitzing, I see…what are you looking so happy about? Wonderful, just wonderful: “Looking forward to all those failed implementations.” This, class, is what you should really be aspiring to if you really want to succeed! The software wrangling business is for mugs…why do you think that I am standing here in front of you and not sitting in front of a computer!

OK. With all this in mind, let’s begin, shall we?

Today’s lecture is entitled “A Picture Paints A Thousand Words. It Also Consumes Many Megabytes, Gives You RSI And Still Ends Up Less Useful Than A Single Line Of Code.” Please open your books to the chapter entitled “Oracle Service Bus”…

I’ve got to go now…some nice men in white coats have come to take me on holiday. How nice of them!

Seriously though…some 2004-vintage food for thought, entitled Jump off the bus, take a cab!:

…
A lot of companies have expressed the similarities between SOA and the concept of (hardware) Bus….I understand that a bus offers a “common interface infrastructure” and components can use the bus to communicate with each other, this is pretty much where the analogy stops for SOA. SOA requires very little in the middle (other than a standard communication infrastructure, that we already have for free) and is inherently point to point and asynchronous, unlike most bus architectures which require some centralized infrastructure and synchronous behavior. I would agree with the OASIS/BCM group that the only shared component in a SOA is a directory service.
…

Bear this quote in mind the next time some SOA-totin’ salesman attempts to bale up your checkbook with an order for their latest and greatest centralised server-based product.

Also worth an “honourable mention” is this oldie-but-a-goodie from InfoQ: ESB-Oriented Architectures considered harmful.

A final thought, as directed at the ‘real’ Don Quixote:

And you, Señor Don Quixote, your head is going to end up a stranger to your neck.

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…

Positioning

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.

Architectural

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

Development/Engineering

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:

WebService.doSomething(DBEntity.findByPrimaryKey(pk));

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.

Other

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 apps).
• 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 happened.
• …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.

[edit]
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 ;-)

WARNING! System error has occurred due to "%1". Disaster will result unless you "%2" IMMEDIATELY.

Consider this: Microsoft’s customers don’t buy into C# (regardless of what most techies will tell you), they buy the Visual Studio packaged, pre-canned development pathway to development nirvana. They take on a particular packaged view of the world. Then they pretty much sit back and go where Microsoft leads them. It’s a well-marketed, appealling, popular, putatively risk-free and well-trodden strategy.

(Dont’ kid yourself that the marketing is actually real, however. Script-kiddies will produce script-kiddy grade coding, regardless of the quality of the marketing, or the prettiness of the tool. Trust me, I’ve seen the code! The only way out of this is training and experience. There’s a cost there, both dollars and time, so the professional managers that now rule our world will do almost anything to avoid that cost.)

The Microsoft market is notoriously not innovation-driven. The customers and practitioners typically don’t care less about better ways of skinning the cat, as long as it gets skinned somehow.

On the surface, this seems fine and dandy but let’s look around our modern world to see if innovation actually is or is not needed…

• I am pretty happy that I don’t drive a Model-T Ford: love those modern innovations like anti-lock brakes, seatbelts, aircon, airbags pneumatic tyres and suspension systems. I am VERY happy that I don’t have to ride a horse…or a donkey.
• I’m grateful for penicillin.
• Being able to step into a Boeing 747 to travel half-way around the planet has certainly changed my life.
• Love the lidocaine that my dentist pumps into me before digging around inside one of my teeth’s root canals.
• I often remark at the way modern materials have changed the game of Tennis (sometimes for the worse but the actual rackets are indubitably superior to those of yore).
• Let’s not forget that ASP.Net is better because of the influence of JSP/JSF technology, and that JSP/JSP (especially JSF) is better because of ASP.Net…that raw competition has been good for all concerned.

Innovation does make a difference, it seems.

Oh well. That was then, this is now.

(It is interesting to note that Microsoft is finding it hard to add new features into C# nowadays: the customers are effectively saying “we dont’ need no stinkin’ innovation”…)

So: I see Java becoming Oracle’s C# analogue.

All Java’s best features…all those features that make it attractive to Oracle the tool vendor (a mature, stable, efficient, cross-platform execution environment with minimum cost of development and support but with maximum market penetration)…will be ‘deprecated’/no longer mentioned. They will still be there and still be relevant but they will be pushed under the covers. You won’t see them and Oracle will educate you to let you know that you don’t even need to see them. What you’ll ‘need’ is to buy their product set. The product set that has been carefully engineered and (especially) advertised to sit right in the sweet-spot of minimum effort to produce and maximum profitability…for Oracle.

You’ll be bombarded with marketing and other influences to ensure that you forget those Java communities and competitors out there (you know, the ones that have benefitted your world over the past 10-15 years); Oracle’s sales team will be happy to explain to you why you don’t need the likes of Apache.org, the JCP, Spring, JBoss, etc. any more.

As long as you cross their palms with copious quantities of gold, Oracle will show you the One True Way.

Hopefully, there will be some sort of convergence between what Oracle will feed you and what you actually need.

Just remember what happens to a drug addict when he/she can’t pay their dealer…

The current Java-based multi-vendor marketplace simply won’t be able to survive under such conditions.

Don’t believe me? Want proof? Answer me this, then: what’s the second-best selling C# IDE in the windows world? There pretty much isn’t one, is there! Or this: what’s the alternative framework to ASP.Net? Again, there ain’t no such animal…

It’s the end of the world, people!

Perhaps one day in 2025, some manager with an atavistic streak of innovation in his/her DNA will suddenly pause the “Oracle Charge-O-Meter” on his/her pay-per-cycle copy of “Oracle Developer Brain Enhancement Interface for the Enterprise 17.7c” and think: “You know, what we need is a way of building Open Systems and not being beholden to a single monopolistic vendor! Wonder why no-one ever thought of that before?” I’m assuming that about 100 cycles after detecting such a wayward and unprofitable thought, the “Oracle License Mangager” will take appropriate remedial action…

Whoops! There I go! Again with the Open Systems thing…

I’ve been known to say: “Don’t start a Java application without Spring. Ever.”

The primary reason for this is versatility. I can and have used Spring to:

• Develop various species of plain ‘ole web applications
• Develop webflow-based web applications
• Develop reporting applications incorporating eclipse BIRT
• Develop Swing-based desktop applications (using TeeChart)
• Develop batch processing systems
• Helped develop XML pipeline processing systems (alongside Stylus Studio‘s XML processing framework)
• Develop system integration processing flows
• …and probably a few more bits and pieces…

The Spring-oriented skills I have built up have let me work in a substantially standardized way regardless of the situation.

That’s pretty darned good, if you ask me!

Is this same story true of the obnoxious OSB? No.
Is it true for any implementation of the J(2)EE spec.? No. From any vendor? No.
Is it true for other frameworks like JBoss Seam. No.

Anyone know of any other framework out there offering similar flexibility, ‘cos I’m darned if I do.

The Spring framework isn’t standing still, either…it’s the foundation for both Grails and Griffon. As I have adopted these technologies, my productivity has increased greatly. I am “standing on the backs of Giants.” This is a Really Good Thing.

Let’s add a modicum of “Systems Thinking” here. Rather than wasting time training a multitude of staff in a multitude of (typically short-lived) siloed technologies…some of which are honestly horrid…it makes much more sense to build a solid core of experience with a solid core technology.

Whoops! Here I go advocating a standards-based ICT world…again.

‘Standards.’ “Systems Thinking.” How naive am I!

[...edit...]
Received an email from Manning the publishers a while back:

I know that this is not a scientific measure of ‘goodness’ (if one were even possible), but it speaks volumes to me…

I have pretty much said this before, but it won’t hurt to repeat it a bit more plainly (please excuse the non-MA nature of this posting…any percieved ‘crudity’ is not intentional): doing Continous Integration without proper associated testing is like having sex without going “all the way.”

Both seem great fun initially but with repetition become more and more unsatisfactory and pointless.

More: both practices ultimately hinder further evolution and improvement. Of your codebase in one case, and of the Human Race In the other.

Refer to the CI Maturity Model for more on how to do CI properly.

Normal child-safe programming will now resume…

Oracle was 100% bound to screw Java over. Bound to. never had a skerrick of doubt.

The first strike (not really Oracle’s fault but it is out there and needed proper management): a spooked community. Java devs are loyal beasties and really wanted some “warm fuzzies” from Oracle. They got squat. All those third-party organisations that based their products or enterprise strategies around the Java platform wanted assurance of a light touch. Did they get it…hah!

Instead, they got…

The second strike: Oracle suing Google. Anyone outside the legal community going to benefit from that, do you think?

The third strike has now arrived: Google backing out of JavaOne. Hear that sound? That’s the thunder of a community running away. Way to go, Oracle!

We all know that three strikes and you’re out…

Where to now?

Time to start polishing my C#?

Haven’t used Objective-C since the NeXT days, but maybe an iPhone betting game would be a winner: “What stupid thing will Oracle do next?” I envisage some neat graphics: an animated Larry sailing around on a ocean of lawyers, occasionally dumping assets overboard…The winner each week would get the major prize: a cup of cold instant coffee; all the other players would have to reboot their devices.

A graphic illustration that Australia’s Sen. Conroy doesn’t subscribe to (notice I don’t say “doesn’t understand”…he understands it well enough to reject it, I am sure…) the idea of free speech and democratic discussion:

The front page of Communications Minister Stephen Conroy’s official website displays a list of topics connected to his portfolio, along with links to more information about each one.

All the usual topics are there – cyber safety, the national broadband network, broadcasters ABC and SBS, digital television and so on.

All except one.

It was revealed today a script within the minister’s homepage deliberately removes references to internet filtering from the list.

In the function that creates the list, or “tag cloud”, there is a condition that if the words “ISP filtering” appear they should be skipped and not displayed.

Ridiculous…deliberately hiding a major (not un-concidentially really controversial) part of his portfolio to make it hard for interested parties to find out what he is doing.

Seriously: this guy is not fit to be a member of the nation’s governing body. I’ve said it before: Senator Steven Conroy should go. And soon.

Here’s the news.com.au source: Conroy’s website removes references to filter.

(Again…my opinion, YMMV).

There is definitielysomething wrong (with the product, please note) when the ‘pirated’ version of a product is actually better than the real thing.