Find answers to these frequently asked questions on Open CSA.
Open CSA is an independent group that works under the open process of the OASIS international standards consortium. Open CSA members collaborate to advance open standards that simplify SOA application development.
Open CSA members represent all serious stakeholders in SOA application development. Software, hardware, and services providers, user companies, government agencies, systems integrators, and other interested parties are invited to participate in this work. Anyone is welcome to join, and anyone employed by an existing OASIS member may participate in Open CSA without additional dues or cost.
See Open CSA Members for a current list of organizations that support this work and Roster of Participants for a list of people who are involved.
Open CSA concentrates its intial work on the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications. The Member Section supports the process of:
As standards in this area mature, Open CSA also supports adoption and implementation efforts including development of:
Yes, everyone is welcome to participate in Open CSA's efforts to advance standards for simplifying SOA application development.
See Join Open CSA for instructions on how to get involved and Join OASIS for information on membership benefits, categories, and dues.
Documents and archives of mailing lists for Open CSA and for OASIS Committees are publicly accessible, and the community is invited to participate in public reviews and provide comments to the Committees.
Open CSA operates under the OASIS Open CSA Member Section Rules of Procedure. The Member Section is subject to the OASIS Bylaws, Member Section Policy, IPR Policy, Technical Committee Process and other policies and procedures.
Open CSA activities are managed by a Steering Committee that consists of seven members. Each member serves a two-year term. For consistency of management, terms are staggered so that four seats expire one year and the other three expire the following year.
Steering Committee representatives are nominated and elected by the Open CSA membership in an open process. The selection of the Steering Committee is based on individual merit and is not tied to financial contribution, corporate standing, or special appointment.
The SCA and SDO specifications both aim to provide elements of a programming model for building systems which use a service-oriented architecture.
SCA provides a way of describing the structure of service-oriented solutions. It uses service components as the basic building blocks, where a service component offers one or more services and optionally makes references to services supplied by others. One or more service components can be composed together using a composite which not only defines anc configures the components, but also wires together their references to services which resolve them. Composites can also apply specific bindings to wires (eg Web services) and also apply policies that determine how wires are used (eg applying encryption to messages flowing between a reference and a service).
SCA aims to encompass a wide range of technologies, including many programming languages that may be used to implement components and also many types of binding that may be used for communication.
SDO defines a programming model for accessing data in a service-oriented architecture. It provides a standard way for the programmer to deal with data whatever its source or target. For example, it can handle data from an XML document or it can handle data from a relational database. SDO also supports a disconnected data model, where data can be extracted from its source, manipulated by a client program and then updates sent back to the source, without the need to lock the source data. This is often a more satisfactory approach in handling serivce-oriented architectures.