Dan,

Thanks for putting this discussion back on the standard track.

I do not think that we have done a satisfactory job in regards to presenting our solution to David, John and the individuals from OASIS BCM TC. I want to assure you that our FERA-based ebSOA architectural solution includes all aspects of the SOA architecture on the level of the specification details that can be used for enterprise SOA implementations:

- Collaborations (internal and external), - Security, - Messaging, - Protocol profiles and agreements, - Universal business documents formatting, - Registry and repository-based management of meta-data and business artifacts, - Business rules, - Agent frameworks

Using the Federated Enterprise Reference Architecture (FERA) reference model we produced the set of ebSOA specifications needed to provide full enterprise level SOA support from both a functional as well as implementational point of view. We think that the missing factor in the ebSOA architecture is the semantic integration which brings all of the above aspects together. We have fully defined the FERA-based ebSOA collaboration semantics that resolves this problem. Our ebSOA collaboration semantics is also based on the formally defined information model that can be stored in a standard registry like the OASIS ebXML Registry or OASIS UDDI Registry and used to take care of both context and content related to any business process. This is supported by a single open standard-based XML document we call the Collaborative Process Information Document (CPID) that can be generated from a business process definition in a visual modeling tool. Submitting the content of this document to a standard registry will generate the entire collaboration process information model that together with FERA-based ebSOA collaboration semantics already implemented via FERA-based ebSOA managers (remember all FERA-based managers in ebSOA architecture - Federation Manager, Agent Interface Manager, Event Manager, Activity Manager, etc.) enables full open standard-based support for the enterprise business collaboration processes of any complexity.

Another important aspect of our proposed solution is standard convergence. We very much believe that standard convergence is the future and in our architectural solution we reference the best "standard brands" available today. It does not matter which standard body they are coming from. What matters is the standard's value in the ebSOA functional offerings. For example, these are some of the standard components we reference in the FERA-based ebSOA: OASIS ebXML BP, OASIS WSBPEL, OASIS UBL, OASIS ebXML Registry, OASIS UDDI, W3C SOAP, OASIS ebXML Messaging, WS-Security, OASIS XACML, OASIS SAML, WS-Reliability and others.

We also want to mention that two important components of the FERA-based ebSOA architecture, Agent Framework and Business Rules, are not supported by any standard today. OMG has two pending Requests For Proposals related to business rules: Business Semantics of Business Rules and Production Rule Representation. Our definition of a standard is a specification produced and approved in a large recognizable standard body like OASIS, W3C, OMG, IEEE, etc.. Some specification components are coming from groups and programs like Java Community Process (JCP). While some of them achieved great success over last few years, we believe that ebSOA specification should reference standard components first. However, when the standard is not provided we recommend using other groups' specifications, but on the implementation level only. We believe that if some industry groups have valued specification offerings they should be encouraged to submit their spec proposals to standard bodies and speed up the process of developing very much needed standards that we do not have today.

I hope that this clarifies key aspects related to our FERA-based ebSOA proposal and our vision about enterprise SOA.

Regards, Goran