OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing over 600 organizations and individual members in 100 countries.

Although JBoss is not involved in all of the technical committees under the OASIS umbrella, the following are worthy of note.

The Business Transactions Technical Committee

The purpose of the Business Transactions TC is to develop technology for business transactions on the Internet. Long lasting business transactions spanning multiple enterprises pose a unique challenge to B2B systems. The interdependent workflows managed among multiple trading partners, which drive business transactions, need to be coordinated to ensure that the outcome of the transaction is reliable. As an initial input, BEA intends to offer a specification for our Business Transaction Protocol (BTP), which provides this functionality and is implemented in our Weblogic Collaborate product. BTP is an eXtensible Markup Language (XML)-based protocol for representing and seamlessly managing complex, multi-step business-to-business (B2B) transactions over the Internet. The protocol allows complex XML message exchanges to be tracked and managed as loosely coupled "conversations" between and among businesses. BTP goes beyond the problem domain currently being addressed by ebXML and is independent of transport protocols and messaging frameworks. We believe that it can be layered on any underlying transport mechanism including ebXML Messaging, RosettaNet, or XML-PC (SOAP).

The Web Services Business Process Execution Language Technical Committee

The purpose of the Web Services Business Process Execution Language TC is to continue work on the business process language published in the Business Process Execution Language for Web Services (BPEL4WS) specification in August 2002. Continuing the approach and design used in BPEL4WS, the work of the BPEL TC will focus on specifying the common concepts for a business process execution language which form the necessary technical foundation for multiple usage patterns including both the process interface descriptions required for business protocols and executable process models. It is explicitly not a goal of the TC to specify bindings to specific hardware/software platforms and other mechanisms required for a complete runtime environment for process implementation.

The Web Services Composite Application Framework Technical Committee

The purpose of the OASIS Web Services Composite Application Framework TC is to define a generic and open framework for applications that contain multiple services used in combination (composite applications). Multiple web services combined in composite applications require interoperable mechanisms to set the boundaries of an activity (such as start/end, or success/failure), to create, access and manage context information, and to inform participants of changes to an activity. Composite applications might also need to work with a range of transaction models, including simple activity scoping, single and two phase commit ACID transactions, and recoverable long running activities. The goal of this TC is to define a set of royalty-free related, interoperable and modular specifications that will enable development of composite applications, ranging from simple to complex combinations of web services and encompassing a useful range of transaction and coordination requirements.

WS-CAF actually comprises three separate standardization efforts: WS-Context, WS-Coordination Framework and WS-Transaction Management. WS-Context has only just gone to Committee Draft (for public community review).

The Web Services Distributed Management Technical Committee

The purpose of the Web Services Distributed Management TC is to define Web services management. This includes using web services architecture and technology to manage distributed resources. This TC will also develop the model of a web service as a manageable resource. This TC will collaborate with various evolving activities within other standards groups, including, but not limited to, DMTF (working with its technical work groups regarding relevant CIM Schema), GGF (on the OGSA common resource model and OGSI regarding infrastructure), and W3C (the web services architecture committee).

Web Services Remote Portlet Technical Committee

The role of this TC is to create an XML and web services standard that will allow for the "plug-n-play" of portals, other intermediary web applications that aggregate content, and applications from disparate sources. These so-called remote portlet web services will be designed to enable businesses to provide content or applications in a form that does not require any manual content or application-specific adaptation by consuming applications. It will harmonize WSRP as far as practical with existing web application programming models (e.g. Portals/Portlets, Macromedia Flash, ...), with the work of the Java Community Process (e.g. JSR 168 Portlet Specification), with the programming model of .NET, with the work of the W3C (e.g. XForms, DOM, XML Events, XPath, XLink, XML Component API task force), emerging web services standards (e.g. SOAP, WSDL, WSBPEL) and with the work of other appropriate business information bodies.

The Web Services Transaction Technical Committee

The TC will accept as input version 1.0 of the WS-Coordination, WS-AT and WS-BA specifications as published by Arjuna Technologies, BEA Systems, Hitachi, IBM, IONA Technologies and Microsoft. Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter.

The scope of the TC's work is to continue further refinement and finalization of the input documents to produce as output modular specifications that standardize the concepts, WSDL documents and XML schema renderings required to coordinate actions of distributed applications that conform to the specifications.

The Web Services Reliable Exchange Technical Committee

The purpose of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee (TC) is to define a protocol for reliable message exchanges between two Web services, through continued development of the Web Services Reliable Messaging specifications from IBM and Microsoft, through which Web services express support for reliable messaging as well as other related useful parameters. This mechanism will be based upon the Web Services Reliable Messaging Policy Assertion ("WS-RM Policy") specification submitted to the TC.

Reliable messaging systems can generally be described using a four agent model. In this model there is an Application Source, a Reliable Messaging Source that acts on behalf of the Application Source, an Application Destination and a Reliable Messaging Destination that acts on behalf of the Application Destination. Message Transfer is the function of moving messages from a Reliable Message Source to a Reliable Messaging Destination. This TC will provide protocols for the reliable message transfers that occur between Reliable Messaging Sources and Reliable Messaging Destinations. The TC will not develop additional mechanisms by which a Reliable Messaging Source captures messages from an Application Source or mechanisms by which a Reliable Messaging Destination delivers messages to an Application Destination.

The SOA Reference Model Technical Committee

"Service Oriented Architecture" (SOA) as a term is being used in an increasing number of contexts and specific technology implementations, sometimes with differing - or worse, conflicting - understandings of implicit terminology and components. The proposal to establish a Reference Model is intended to encourage the continued growth of specific and different SOA implementations whilst preserving a common layer that can be shared and understood between those or future implementations.

The SOA-RM TC will deliver a Service Oriented Architecture Reference Model (SOA-RM). Once the SOA-RM has been delivered, the TC may consider appropriate follow-up, including the creation of sub-committees, promotional material, liaisons or other promulgation of the Technical Committee�s work, in order to promote the use of the SOA Reference Model in specific SOA implementations, in particular for vertical industries.

The SOA Adoption Blueprints Technical Committee

In planning and building Service Oriented Architectures (SOA), concrete examples often are useful. SOA designers, vendors and users can reference a wealth of abstract guidelines, descriptions of functional layers and sets of specific standards or software that fulfill SOA requirements.

However, often there is a shortage of clear, demonstrable examples of working implementations based on real needs and requirements that can be used as best practices reference, to kick start implementation projects and to compare implementations. One way to encourage these examples is to supply an archetypal "blueprint" set of business requirements and functions that can be fulfilled by SOA methods.

The SOA Adoption Blueprints TC will develop, circulate, maintain and update a set of example business profiles or "adoption blueprints" to illustrate the practical deployment of services using SOA methods. Each adoption blueprint will provide a (a) business problem statement, (b) a set of business requirements, and (c) a normative set of functions to be fulfilled, all on a vendor- and specification-neutral basis. The TC anticipates starting with the original "blueprint" scenario created by the project's host, The Middleware Company and its expert group, to be contributed to OASIS. This scenario, the "Generico" core application set, will serve as a basic Adoption Blueprint. It is expected that additional blueprints will be developed to address other business requirement sets. Additional Adoption Blueprints may interoperate with the basic Generico blueprint, or may describe a new separate scenario.

Identity In The Cloud Technical Committee

Red Hat was the champion in setting up of this TC to work on Cloud Identity. Other notable supporters in the TC formation include Microsoft, IBM and CA Technologies. The goal of this Technical Committee is to formalize use cases in cloud identity management, perform gap analysis with existing standards and then generate profiles for various notable areas of Cloud Identity Management.

Service Repository Artifact Model and Protocol (S-RAMP)

Repositories focused on the needs of SOA environments are typically used to publish, search for and retrieve a wide variety of technical documents which describe a customer's SOA environment.  This includes such things as schemas, service descriptions, business process design models, policy documents and so on.  These repositories and related tooling products are available from multiple vendors today. These products facilitate various activities across the life cycle of a SOA artifact, such as design, assembly, quality assurance, deployment, runtime operation and monitoring of SOA based applications and business processes.

The SOA Repository Artifact Model and Protocol (S-RAMP) TC defines a common data model for SOA repositories as well as an interaction protocol to facilitate the use of common tooling and sharing of data. The TC will define an ATOM binding which documents the syntax for interaction with a compliant repository for create, read, update, delete and query operations.

OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

The OASIS TOSCA TC works to enhance the portability of cloud applications and services. TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)--independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also make it possible for higher-level operational behavior to be associated with cloud infrastructure management.

By increasing service and application portability in a vendor-neutral ecosystem, TOSCA will enable:

1. Portable deployment to any compliant cloud
2. Smoother migration of existing applications to the cloud
3. Flexible bursting (consumer choice)
4. Dynamic, multi-cloud provider applications