Last week we got flooded with requests to extend the deadline for our Products of the Year Awards submissions. Normally we’d have taken a “no soup for you” stance on this, but when the requests topped the dozen mark we figured we should grant an extension.

Now you’ve got until February 15 to fill out the nomination form. It will push back the announcement of winners until March, but we believe this will be the most comprehensive set of awards handed out in the SOA space and we wanted to make sure absolutely everyone gets a chance to submit.

For those of you who don’t know, we have eight categories:

1. Service design and modeling (including BPM)
2. Service assembly and integration (ESB, orchestration)
3. Service performance (testing, QA)
4. SOA runtime management
5. Data services/integration (including BI)
6. SOA security
7. SOA governance (including registry/repository)
8. Composite application assembly (portal, Ajax, RIA)

Products need to have been released between Dec. 1, 2006 and Nov. 30, 2007. You can check the nomination form for more details, though we highly recommend you explain how the product enables SOA and adheres to the principles of service orientation in your entry.

Oracle Corp. finally came up with an offer BEA Systems Inc. couldn’t refuse, but the sale is merely a prelude to a pile of “now what?” questions.

The next year in the application development software space will be shaped by this deal. How will BEA fit underneath the Oracle umbrella? What does this mean for open vs. proprietary tooling? Will BEA open new SOA arenas to Oracle or will this create an opportunity for competitors to win business as the Oracle-BEA assimilation takes place? Will SAP react? Will Microsoft react? Will IBM react?

I could go on all day, but I suspect you get the point: Oracle has agreed to buy BEA and the fallout promises to be massive.

Even though this deal has seemed imminent for months, the media and analyst community is trying to sort out the rationale behind it. Over at ZDNet, Larry Dignan’s blog entry notes “Ellison added that BEA will allow Oracle to instantly become a leader in messaging and ‘adds scale to our middleware business.’”

The Eye on Oracle blog from SearchOracle.com speaks with Forrester analyst Ray Wang, who says, “We expect accelerated consolidation along key battle grounds of middleware platforms such as Master Data Management, business intelligence, portals, business process management, and other information management tools. Don’t expect the competitors of BEA to sit still.”

Matt Asay at CNET flogs the conventional wisdom and asks if Oracle’s platform play will drive users toward open source offerings.

On his blog at SpringSource, Rod Johnson speculates that “the Oracle application server, OC4J, is history and Oracle will focus on driving WebLogic Server.” Yet that’s only the tip of the iceberg.

Here’s some of the other seemingly competitive products that need to be rationalized:

• Oracle Enterprise Service Bus, BEA AquaLogic Service Bus
• Oracle BPA Suite, BEA AquaLogic BPM
• Oracle Portal, BEA WebLogic Portal
• Oracle Web Services Manager, BEA AquaLogic SOA Management
• Orace Data Integrator, BEA AquaLogic Data Services Platform
• Oracle JDeveloper 10g, BEA Workshop

That last one is a real sticky wicket in that BEA built Workshop on the open source Eclipse IDE, while JDeveloper is still a fully proprietary offering. Where does the tooling go? Since Oracle bought BEA, you’d have to think this doesn’t bode well for BEA’s open tooling approach. If so, maybe Asay is onto something, maybe this is the end of the “commercial open source” path BEA was trying to navigate.

How well Oracle assimilates BEA and what decisions it makes about mixing and matching the two product lines could either give rise to an application development titan or send customer scurrying for alternatives. One thing it probably can’t afford to do is repeat what it’s done with the 2007 Hyperion acquisition, namely make a big money purchase and then remain mum on how it will fit long term into the Oracle Fusion product line. Hyperion was a complimentary acquisition, bringing business intelligence into the Oracle family. It can stand alone for a while. There’s too much redundancy with BEA for Oracle not to produce a fairly clear roadmap of how it all fits together.

We spend a lot of time these days talking about governance and management when it comes to SOA. There’s a good reason to take that macro view, because far too many people get lost in the trees and fail to see the forest when it comes to service orientation. We are talking about enterprise architecture after all, so an enterprise-level view would be appropriate.

That said, you can put the perfect governance model in place and it won’t mean a thing if you don’t understand messaging. SOA requires a lot of integration work and integration, more often than not, requires messaging. With that in mind we created a messaging lesson in our Service Orientation for Architects School. It features a Webcast with WSO2’s Paul Fremantle on service-oriented messaging, in which he breaks down a slew of messaging alternatives, including JMS, HTTP, REST, SOAP, WS-Addressing, WS-ReliableMessaging and traditional message queues.

Yet more than that, Fremantle delves into messaging practices that will aid you on the SOA front. It’s one thing to boil up a big pot of integration spaghetti, quite another to architect a reliable messaging infrastructure. The lesson is focused on the latter.

Fremantle has also penned a tip on service mediation. As part of the Apache Synapse project, Fremantle has been instrumental in defining service mediation best practices.

The goal of mediation is to help create a flexible messaging backbone for your company. The tip covers a host of mediation techniques, including Web Caching, load balancing and message-based routing.

It’s an ideal chance to catch up on the architectural underpinnings of messaging as they apply to SOA. Even for those of you who feel fairly confident about your messaging skills, this lesson is sure to give you a few pointers to hone your skills.