OSOA Home

Introduction

All of the Published SCA specifications to date, and the Published SDO non-Java specifications are being submitted to OASIS. (The SDO Java specification will be completed via the existing JSR 235 within the JCP). We also expect that Specifications currently being completed within the collaboration will be submitted to OASIS when they have reached the same level of maturity.

OASIS has created a new Member Section (MS), called the Open Composite Services Architecture (Open CSA) Member Section to manage the standardization activities as a coherent body of work. Several new OASIS Technical Committees (TCs) will commence in September 2007 to do the actual standardization work.

The OASIS Standards Development Organization

Why OASIS?

OASIS is known for its open process and its ability to attract a broad audience to work on its Specifications. Both individuals and corporations can be members of OASIS and the cost of membership encourages that sort of diversification. A large number of the companies participating in the collaboration are currently OASIS members, ensuring continuity during the transition process. OASIS recently completed an overhaul of its Intellectual Property Policy with the result that our pledge of providing these Specification royalty-free to the industry can continue as new companies join-in the standardization process. The OASIS standards process is also friendly to open source groups, ensuring that the open source work embraced by several of the collaboration companies will continue to have an influence in the final result.

What is an OASIS Member Section?

The Member Section (MS) is an organizational structure that OASIS provides to enable a group of Members to collaborate on a related body of work. It provides a "higher" level of organization than of a collection of TCs. In addition to providing a coordination point for technical work (via its affiliated TCs), a MS may also organize and facilitate a variety of marketing and adoption activities. Several different funding mechanisms are allowed under OASIS rules. The work of a Member Section is guided by a Steering Committee (SC). A MS is created by asking the OASIS Board of Directors to approve a document called a Rules of Procedure (RoP) which serves as the "constitution" for the MS. It defines such things as the makeup of the SC, the powers of the SC, and funding mechanisms.

Under OASIS rules companies may choose to "join" a MS. This gives them the right to run for the SC and to participate in elections of the SC. A portion of their regular OASIS member dues can also allocated to the use of the MS if that funding is being used for the MS. The Open-CSA MS we are creating does not currently plan to use member dues as a source of funding.

Any OASIS member company or individual may participate in an affiliated TC regardless whether it has chosen to be a member of the MS.

The OASIS OpenCSA Member Section

The specifics of the RoP for the OpenCSA Member Section (OpenCSA-MS) utilize the powers available to a SC to provide a focus for coordinating the program of work undertaken under its purview.

The SC consists of 7 members serving two year staggered terms. The initial four two year terms are filled by current employees of BEA, IBM, Oracle, and SAP. An election was held to fill the remaining three one-year initial terms soon after the creation of the new-MS, and representatives from Red Hat, Rogue Wave and TIBCO were duly elected.

The SC has to approve (via a 2/3 super-majority vote):

• TC Charters (content, scope, deliverables)
• Requests to advance a TC Committee Specification to OASIS Standard.
• Requests to submit TC Committee Specifications to de jure standards bodies for further processing.
• The ROP also contains requirements that TCs closely coordinate their work, define fairly stringent exit requirements, develop testing materials, and demonstrate interoperability/portability as appropriate before finalizing their specifications.  This is done by requiring that TC Charters include these provisions (as appropriate for their specific work). Because SC approval is required, TC proposers will have to satisfy the SC that the proposed work fits under the OpenCSA rubric.

The ROP also allows the SC to fund and implement a "marketing/adoption" program if it is so desired. This can be accomplished via chartering of separate "adoption TCs" (TCs focused on producing white papers, best practice documents, etc.), by maintenance and sponsorship of the OpenCSA MS portion of the OASIS website, by hosting interoperability workshops and demonstrations, and other related activities.

These features are all designed to facilitate a coordinated program of work to finish off and drive adoption of SDO and SCA. It is hard to see how such an objective could be accomplished without the "coordination point" of a SC and MS.

Planned OASIS Technical Committees

Several TCs have been chartered and affiliated with the new MS. Note: An OASIS member does NOT need to be a MS member to participate in any of these TCs.

The list of TCs can be found on the OASIS site

The Java Community Process (JCP)

SDO V2.1 for Java is the most mature of the specifications being submitted for standardization with this announcement. Initially developed in 2004, SDO has seen three major revisions as well as the most commercial implementations. During the last phase of the collaboration, a major focus was applied to make sure that consistency between the SDO Java specification and the SDO C++ specification was achieved. As a result of that work, we have concluded that allowing SDO V2.1 for Java to be completed in the JCP, where JSR 235 was established for that purpose earlier, is the best solution for our Java customers.

The SCA Java specifications, on the other hand, are now at the V1.0 level and implementations are in the very early part of the life-cycle. As a result, we feel that the best way to ensure consistency between the multiplicity of languages supported by SCA is to initiate all work in a single organization, namely within the OASIS OpenCSA Member Section. At a latter point in the cycle, we will consider which SCA Java specifications might be candidates to submit to the JCP. 

The Ongoing Role of the OSOA Collaboration and the www.osoa.org web site

Over the last few years, the OSOA Collaboration has worked together to rapidly innovate on technology associated with Service Data and Service Components. Both through an informality of process and ready access to customers and partners, the Collaboration has brought an initial series of specifications to market and made them available for implementation by the industry through this web site. Our focus has been on meeting the needs of our target audience (Architects & Developers) and in rapid innovation with the objective of a simple but powerful model for creating applications in an SOA style.

March 2007 sees a significant milestone for our collaborative work. Twelve Key Specifications representing the core functions of SCA (V1.0) and SDO (V2.1) are published and made available to the industry for implementation. A strong set of industry vendors are joint authors of these specifications and you should expect individual vendors to be competing with each other on the best implementations for their customers. We firmly believe that after an extraordinary 18-company collaborative effort, we have reached a milestone and call on the industry to implement the technologies (with the assurance of Royalty-Free rights for complete and compliant implementations.

Given the maturity of these key specifications, it is now time to turn over the stewardship and future development of them to a formal standards development organization: OASIS. SDO V2.1 for Java will be submitted to the Java Community Process (JCP) and be completed within the existing JSR 235.

Work continues under the stewardship of the OSOA Collaboration however. Although key specifications are now mature enough to submit to OASIS, we have a sequence of associated technologies that are not yet mature enough for formal standardization. We plan to continue the development of these specifications under this Collaboration and highlight their progress on this web site. Examples of ongoing projects include:

• A formal event model for SCA Assembly to broaden the applicability of the SCA Architecture,
• Further Policies Intents (e.g. Transactions) to add into our Published SCA Policy Framework Specification,
• Further Bindings (e.g. JCA) to ensure SCA Services can co-exist and "bind" with other key industry technologies,
• Improved integration into the Java EE platform,
• Additional Language Support for both SCA and SDO.