BEA Upgrades ESB, Announces SCA Runtime and Repository

BEA Systems has launched AquaLogic Service Bus 3.0, the next
version of its ESB platform. The new release adds several new
features, notably an Eclipse-based development environment and native
support for IBM MQ protocols and ERP software from Oracle, SAP, Siebel
and Peoplesoft. It isn't yet able to run natively on VMWare, though BEA
says this is still on the roadmap for next year.

ALSB 3.0 also includes new management capabilities, including
policy-based load balancing and QOS and grouping of services into
domains (called "neighborhoods") that make simplify a large, distributed
SOA. According to BEA, this doesn't affect its relationship with
AmberPoint, whose product it continues to resell as AquaLogic SOA

Management. Indeed, the new ESB even features some extra hooks for the
AmberPoint product, as well as better integration with BEA's own BPM and
Registry/Repository. However, there is already a large overlap between
the ESB and SOA Management spaces, meaning that some customers will
likely decide they don't need both --- and that BEA is in a better
position to go it alone.

BEA is also adding support for Service Component Architecture (SCA), a
standard that tries to make individual applications more like SOAs by breaking them down into modular
components. This will involve two separate products: a SCA runtime for
WebLogic Server and a registry/repository that can keep track of SCA
components. The runtime is available now, but the repository is not due
until H2 2008.

Whereas other vendors stress SCA's SOA-alignment or ability to spread
tasks across multiple processor cores, BEA is promoting it as a way to
develop applications without using code. This something echoes the sales
pitches for several other platforms such as Microsoft's Oslo and
numerous enterprise mashup technologies --- including BEA's own Pages
and Ensemble. The difference is that SCA is about much more complex
applications than mashups, envisaged as encompassing everything that
Java can do.

That means development will still require programming skill, even if not
actual development. Developing the individual components themselves
does still require coding, though the overall workload should be
greatly reduced: Many components are simply Web services APIs for legacy
applications, and one of the main motivations behind SCA (and SOA
generally) is to be able to reuse the same components or services in new
applications.