I went to the Oracle Developer Day in Austin today. My goal was to get a developer level introduction to the Oracle JEE and SOA stack, and the material and instructor, Lynn Munsinger (I believe), did a good job. The goal wasn’t to cover Oracle the database, but the Java tooling around the database. Thanks to the staff for putting it on ;>
Along with a room full of other people, my former BMC co-worker, Jon Christiansen and I were walked through a tour of EJB 3.0, JSF, BPEL, and Oracle’s involvement in all of the above.
Barriers & Eclipse
Being a RedMonkey, I was most interested in low barriers to entry and signs for Oracle tools migrating to Eclipse.
While installing Oracle apps is always more tedious than it needs to be, the majority (if not all of them) are free to download and play with. Effectively — neverminding paying attention to the reams of licenses you click through — payment is needed until you roll out into production.
When it comes to Eclipse, it turns out the JDeveloper team is in the process of porting several JDeveloper components (EJB 3.0 and JSF/Oracle ADF) to Eclipse plugins. These aren’t available yet, but the fact that they’re working on them is (a.) great for the Eclipse ecosystem, and, (b.) hopefully telling of the direction of Oracle tools, that is, moving closer towards being Eclipse based.
Right-click Coding
I’ve never been one for model, tool, or drag-and-drop based development. Oracle development, at least as presented to us and as illustrated in the hands-on-lab (where we actually coded up EJBs and Web Services) is all three of those to the extreme. I call it “Right-click Coding,” because you’re always right clicking on things to configure different wizards and properties instead of writing the code.
While right-click coding can certainly be a development accelerator, my problem with it is that it allows coders to be ignorant about the underlying, generated, hidden code. Of course, I don’t write in assembly or binary, so that sentiment is somewhat relative. More importantly, if you’re just writing UIs and services on top of a database and simple workflow, you usually don’t need much more than the right-click coding style offered by Oracle tools. The misalign often comes from conflated the two types of coders out there: “application developers” who create software to sell (the type of coder I am) vs. “corporate developers” who write applications for use behind-the-firewall or for one customer. Developing for one customer vs. 100’s to millions require quite different coding styles and practices.
But, back to my code-fetish thinking: the more important trap is that a heavy emphasis on tools results in bloated specs and configuration. If you’re just going to right click to code something, there isn’t much emphasis on making your code and configuration as lean as possible: you just rely on the machine to spit out and deal with all that complexity.
RAD!
In general, my rule of thumb is that you should run away screaming from any vendor that uses the phrase “drag and drop” when
talking about programming. The same is true for the idea of
abstracting away stuff like HTML into layers like JSF. As Bill pointed out, you always need
to know your medium and audience. So, when you abstract away HTML, you
just end up replicating all the features in HTML. What you want
instead is a micro-formats approach that constrains itself to HTML,
but introduces conventions for how to use HTML. Otherwise, you’ve just
got yet another XML DSL.
If you’re in the Rapid Application Development camp, though, JDeveloper and Oracle development has a lot to offer. The tools are tightly integrated together, and wrapping EJBs in Web Services is snappy. Of course, I’m not sure how well things will go when you start having to debug and track down problems. I’m not sure there was a right-click option for “Fix all broken things.”
SOA, BPEL, and XML DSLs
Coding style wars aside, the SOA and BPEL overviews were quite solid. Oracle did a good job of presenting the whys and even hows of creating a WS-* based SOA with BPEL. I’m at first dismissive of BPEL because it’s implemented as an XML DSL (why not just use an existing scripting language like JavaScript), but since we have it, part of me thinks that we should just use it and stop coming up with new workflow standards. We definitely need to stop coming up with XML DSLs: those are just way too much.
On the other hand, all that XML seems like way too much code and config. Much of it seems to stem from the desire to create a standard that’s “language independent” and, thus, cross-platform. The problem becomes that you end up inventing a whole new language because, ultimately, you need to express all the same things in the new XML standard that you can do in the code that implements it.
To my mind, it seems like we need to cut out this middle-layer, and just agree on a scripting language to use instead, as I’ve been saying, a Domain Specific Language. JavaScript seems like a good contender to me as it’s relatively complete, politically neutral (can you imagine the Ruby, Java, Python, and Perl people getting along?), easy to learn, and (to my mind, with Rhino and the C based engine) widely available.
I’ll be curious to see what the open source world’s answer to workflow/BPEL is. I always look towards open source to provide the most pragmatic, simple solution. It’s thanks to Hibernate and Spring, after all, that we have the simplicity goals of JEE 5.
Disclaimer: BMC and Sun are clients.
Technorati Tags: bpel, oracle, programming, xml, System z, ws
From one perspective, I would say that the open source world has come to the table on BPEL already — there are several open source BPEL projects, with multiple “commercial quality” implementations (e.g., Intalio|BPMS and ActiveEndpoints) available for download and a collaborative project under incubation at Apache (“ODE”).
That said, just like alternate languages for the JVM, it will be interesting to see what people come up with in terms of tools for working with high-level artifacts (e.g., BPMN or an event-condition-action specficiation) that compile to BPEL, management capabilities, adjuncts (e.g., BPEL4People), and even alternative syntaxes (e.g., non-XML) for the base language. That is, one way to look at BPEL is as a good-enough concurrent, XML message-oriented language for writing some kinds of software, and it’s now all about the tooling.