To fight the criticism of SOA complexity, the IT industry standards body OASIS has responded in a strange way: they’ve created six new technical committees (TCs) to go off and hammer out more specifications. The world of SOA is already floating in a sea of complex specifications. There are even web sites dedicated to trying to map the relationships between the many specs. OASIS defends their approach by noting that splitting up into the smaller highly-specialialized committees will enable quick progress on the individual topics because they are being addressed by small groups comprised of topic experts.
The new groups created by OASIS include:
- SCA-Assembly, to define a core composition model.
- SCA-Policy, to define a policy framework for SCA and specific reliable messaging, security, and transaction policies.
- SCA-Bindings, to standardize bindings for SCA services and references to communications protocols.
- SCA-BPEL, specifying how SCA component implementations can be written using Web Services Business Process Execution Language.
- SCA-C-C++, to develop specifications that standardize the use of C and C++ technologies.
- SCA-J, developing specifications that standardize use of Java technologies.
Members of the OASIS initiative include BEA, Oracle, Progress Software, Hitachi, IBM, SAP, and Sun Microsystems.
Standards can be good things, but the danger is that complex standards can inhibit adoption. Rather than the approach that OASIS is taking, it might be better to create a single initiative that tries to unify and simplify something that is already very complex.
[...] OASIS took its share of razzing for this move, and I think Dick Weisinger aptly summed up reactions up in his latest post: “To fight the criticism of SOA complexity, the IT industry standards body OASIS has responded in a strange way: they’ve created six new technical committees (TCs) to go off and hammer out more specifications. The world of SOA is already floating in a sea of complex specifications. There are even Web sites dedicated to trying to map the relationships between the many specs. OASIS defends their approach by noting that splitting up into the smaller highly-specialized committees will enable quick progress on the individual topics because they are being addressed by small groups comprised of topic experts.” [...]
[...] I am sort of on an SCA kick here. I just saw this post from Dick Weisinger of Formtek. In it he questions the approach OASIS is taking with the SCA family of specifications. Dick implies that SOA is already too complex for most people, and creating six new standards isn’t going to simplify anything. I would take that one further and question the very structure of SCA itself. It seems that there are a couple of loosely-related technology areas covered in the SCA specs, why are they all smashed together? Why isn’t the portable communications API for Java being specified in the JCP, where such things are “supposed to’ be specified? Why is that portable API combined in a single spec with a description language for composite artifacts (SCDL)? This post originated from and is provided by the MSDN Blogs RSS feed. The original post of the article can be found here. [...]
[...] Commentary: OASIS is on the wrong path with the SCA standardization effort I am sort of on an SCA kick here. I just saw this post from Dick Weisinger of Formtek. In it he questions the approach OASIS is taking with the SCA family of specifications. Dick implies that SOA is already too complex for most people, and creating six new standards isn’t going to simplify anything. I would take that one further and question the very structure of SCA itself. It seems that there are a couple of loosely-related technology areas covered in the SCA specs, why are they all smashed together? Why isn’t the portable communications API for Java being specified in the JCP, where such things are “supposed to’ be specified? Why is that portable API combined in a single spec with a description language for composite artifacts (SCDL)? Filed under: Interop, SOA [...]