We've been hearing about the Service Component Architecture (SCA) standard for some time, a product of the Open SOA Collaboration group. Rogue Wave Software, a division of Quovadx, Inc. (QVDX), announced the release of Rogue Wave HydraSCA, a service grid for deploying high performance SOA applications based on the SCA specification released on March 21st. "HydraSCA is the latest release in the Rogue Wave Hydra S We’ve been hearing about the Service Component Architecture (SCA) standard for some time, a product of the Open SOA Collaboration group. Rogue Wave Software, a division of Quovadx, Inc. (QVDX), announced the release of Rogue Wave HydraSCA, a service grid for deploying high performance SOA applications based on the SCA specification released on March 21st. “HydraSCA is the latest release in the Rogue Wave Hydra Suite and is the first high performance service grid based on SCA specification. The completion of the SCA 1.0 specification was announced in March 2007 by the Open SOA Collaboration (www.osoa.org), an informal group of industry leaders, which includes Rogue Wave Software. SCA significantly reduces the complexity commonly associated with SOA by simplifying the creation and composition of services regardless of programming languages, including Java, C++ and BPEL. Rogue Wave HydraSCA enables application developers to quickly increase performance and scalability of an individual service or a globally distributed application by employing concurrently running services – all without requiring special expertise in multi-threaded programming.” The objective of this product is not only to support the standard, but do so in a scalable and reliable way, leveraging grid architecture. Thus, while you never hear “high performance” and “SOA” used in the same sentence, perhaps that is now changing. We can only hope. Rogue Wave has been doing connectivity middleware for years, so this is a natural progression for them. They have other products in the Hydra suite as well, including HydraSDO supporting the Service Data Object (SDO) standard. My take on SCA is that the specification seems to be blurry in many respects, however it is maturing rapidly and has evolved into something very interesting and something we should track. The specifications provides for the decoupling of service implementation and of service assembly from the details of infrastructure capabilities, and should be able to work with multitude of languages including C++, Java, COBOL, and PHP as well as XML, BPEL, and XSLT. The core advantage is that the components designed using SCA should be easily reused. What’s more, local calls to services should be more tightly coupled, thus reducing the overhead of creating and parsing messages. I’m going to keep an eye on HydraSCA as well as SCA in general. Software Development