Lots of announcements have come out of BEA World today. I'd like to draw attention to the microService architecture. This is my own analysis, I work at BEA in Canada but do not speak for them in my personal blog.
MSA is the most exciting thing I've seen at BEA since I've joined in 2004, which was partially driven by seeing an early demo of Quicksilver, which became the AquaLogic Service Bus. I've been following MSA since early in the year, and want to say that it's real, it's not vapour, it's being adopted widely internally, and for architecture nuts like me it's a fabulous development.
To understand the implications, take a look at Eclipse's plug-in framework and the innovation happening there. Eclipse effectively has transcended the IDE and has become a general-purpose client application environment. The basis of this is the OSGI framework and Equinox implementation.
In comparison, BEA's microService Architecture starts with a backplane that enables a variety of frameworks and services through standard interfaces & contracts. These can be infrastructure (messaging, monitoring, management, security, etc.), or application activities in a container (SCA, Java EE, or even other langauges that bind to a JVM, such as PHP). MCA is also based on OSGI. These interfaces can be in-process, out-of-process, networked, etc., and are independent of protocol. And I mean protocol in the big picture sense of the term - language bindings, network protocols, etc. The MSA effectively is a general-purpose networked infrastructure environment.
There will be some pre-requisites, of course (a JVM likely will always run the backplane, for example), but besides this, one gains a lot of freedom to evolve parts of their infrastructure with some autonomy. Now one can mix, match & blend components, services or frameworks from a variety of sources. Instead of a monolithic "application server", or "integration broker", BEA can deploy a small number of capabilities in a small footprint catered to a particular situation.
This is, in a way, a culmination of the "blended" open source strategy. For example, one can take some of BEA's proprietary features, such as the BEA Security Framework (which IMHO is the industry's leader in terms of capability), and blend it with the open source Jetty container, for example. Or take some of the AquaLogic services and blend them with the Tuxedo ORB container.
Arguments about WebLogic or AquaLogic being "heavyweight" melt away under this approach. I have no idea what implications this will have on BEA's product structure or business model, but the possibilities are huge, not to mention the potential agility benefits.
BEA is doing three things that strike me as significant (so far): First, they're decoupling their products into a modular, services-oriented approach, thus reinforcing the company's commitment and expertise in the "A" of SOA -- architecture, while retaining three independent product lines with different target audiences. One might claim that BEA is just making up for its acquisition spree & disparity between technology stacks, which is partially true, and at least they're doing something about it, instead of performing integration by brand-name-only. The other side of this is that BEA purposely doesn't want to force customers down a specific infrastructure lock-in route -- it's trying to be Switzerland.
Secondly, BEA is creating an architecture that could beat the "open source stack" companies at their game, by enabling a blending of open source and proprietary components, centralized & decentralized services in a flexible solution that retains the scale & reliability that BEA is known for. I think Peter Yared may have to wait a bit longer before grabbing BEA's 5 billion dollar market cap.
Thirdly, it's a recognition that SOA is independent of web services or any specific technology. Listen to Jon Udell's podcast with Paul Patrick from July 2006 to underscore this vision, which I think is a fairly unique one among vendors.