Everyone claims to be #1, but we at SearchSOA.com believe that matter isn’t official until we make it official with our products of the year awards. The nomination form is now live.

We have eight product categories, spanning the whole of the service-oriented architecture marketplace. They are:

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
6. SOA security (including identity management)
7. SOA governance (including registry/repository)
8. Composite application assembly (portal, Ajax)

Products must have been released or significantly upgraded between Dec. 1, 2006 and Nov. 30, 2007. The deadline for submissions is January 25. Winners will be announced in late February. Vendors may enter in multiple categories, but each individual product may only be entered into a single category.

Criteria for judging includes:

• Innovation
• Performance
• Ease of integration into environment
• Ease of use and manageability
• Functionality
• Pricing/value
• Service and support

Most importantly, products should enable the basic principles of service orientation. Submissions should highlight what exactly makes the product service-oriented.

Once again, here’s the nomination form. Only complete entries will be considered.

The purpose of service-oriented architecture is to better marry IT to business initiatives … or at least that’s what SOA proponents keep telling us. Yet what are the technologies that enable that? John Rymer, vice president and principal analyst at Forrester Research Inc., has laid out what he calls B3, the essential ingredients for creating dynamic business applications. B3 includes business process management (BPM), business rules and business intelligence (BI).

He recently sat down for a podcast to describe the architectural underpinnings of dynamic business applications.

Topics covered include:

• How SOA supports BPM efforts
• What kind of data BI needs to provide in order to enable real-time business agility
• What kinds of business rules need to be prioritized
• How BPM, BI and business rules can work together
• A sensible starting place for those looking to create dynamic business applications

Anyone interested in finding out more about this subject can get a free copy of Rymer’s report on Dynamic Business Applications from Forrester.

In a recent survey, our readers reported security is the top organizational requirement for SOA. All of the agility in the world doesn’t matter if you can’t provide it in a secure fashion.

Yet traditional security isn’t sufficient to lock down a services infrastructure. Applications aren’t being housed on single servers in a static network. Changes in the application domain necessitate changes in the security domain and it is incumbent upon the application architects to plan for the different types of security that service-oriented architecture will require.

With that in mind, we’ve launched our new security lesson inside our Service Orientation for Architects School. It provides essential resources for architects looking to bake in the security that is essential for a proper SOA.

Burton Group’s Anne Thomas Manes offers up a Webcast on a holistic approach to SOA security. It deals with network options, end point intelligence and identity management practices. Steve Craggs of Lustratus Research identifies the top 5 SOA security traps in a podcast.

Craggs also has a written tip on the flexibility-security tradeoff.

It is no secret SOA is creating new vulnerabilities. It will be the users who educate themselves about how to protect against those new vulnerabilities, the ones who don’t expect someone else in the organization to find the holes, who make the most successful switch to service orientation.

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.

It’s probably a sign of our times that we view BEA Systems Inc. as a little fish unable to defend itself against larger predators in the software industry ocean. According to its 3rd quarter financial report, BEA is on track to rake in $1.5 billion this year. It still needs to prove in the 4th quarter it hasn’t been crippled by Oracle Corp.’s $6.7 billion October takeover bid, which it rejected, but a conversation I had last week with a BEA customer proved enlightening.

The customer in question, a CTO whom I contacted on a totally separate matter and wished to remain anonymous, believes BEA’s approach to technology can help it weather this storm.

“They adhere to standards and their tooling is open enough that we see no reason to stay away,” he said. “If a change we didn’t like occured after a takeover, we don’t feel like we’d be locked in with BEA. They get loose coupling. We could unplug from them if we had to.”

His basic argument was that BEA has become open enough and embraced heterogeneity to the extent that it can continue to compete for customers based on functionality. It’s got a service-oriented defense system.

“We need technology that works,” he said. “This takeover drama might be interesting to Wall St., but it has nothing to do with my projects. From a user standpoint, BEA was in more trouble four or five years ago when we weren’t sure if they were going to embrace more open systems. They did and because of that we’ll continue to look at them.”

He reinforced what we already know, BEA has proven successful at selling software during the past decade and it shouldn’t be taken for granted that users will stay away from a vendor that has delivered for them in the past. This isn’t some overly leveraged wannabe without the means to support itself. BEA has been a viable player in the app dev space.

Here’s something I wrote in October about why Oracle might want BEA:

While there’s massive overlap between BEA’s offering and Oracle’s Fusion line, BEA does have three particular strengths that Oracle might be looking to leverage: data services, internal portals and external transactions. Those were the three most popular types of service-based applications our users reported they are either working on or plan on undertaking in the next year. Even more importantly, the demand for these types of applications increased sharply with respondents who reported their companies had achieved some measure of architectural maturity. In other words, the farther along users are with SOA, the more important those projects are likely to become.

BEA has its AquaLogic Data Services Platform, it has its WebLogic Portal product as well as the portal functionality it acquired when it bought Plumtree Software in 2005, and it has the Tuxedo transactional business on which it built itself. So the BEA goose might be sitting on a few golden eggs … and that’s not a bad pet for a would-be giant to have.

Yet if that’s a good set strengths for Oracle to buy, then it’s also a good set of strengths for BEA to have. If a user has a data services, portal or transactional project in the works, then BEA (which reports that more than 60% of its revenues are derived from services) stands to be a player.

While the Oracle bid surely staggered BEA, don’t be surprised to see BEA do a fair job of fighting back this quarter. The fact that it has enough going for it to be a takeover target also means it might have enough going for it to fend off Oracle’s advances.