RE: Comment on the Reference Architecture Foundation for SOA

[Peter F Brown <peter@peterfbrown.com>]

Hi,

I am replying to you on behalf of the OASIS SOA Reference Model Technical Committee, in reference to your comment posted against the Public Review of the SOA Reference Architecture Foundation (SOA-RAF)

 

Your comment was discussed at the sub-committee meeting yesterday and we came to the following unanimous conclusions:

 

The comments consist mainly of the promotion of an alternative architecture and cannot be properly considered to be comments on the work currently under review and are, as such, deemed not applicable. Furthermore, the specific alternative that you reference and promote consists largely of a proprietary solution architecture, something that goes beyond the scope of the SOA-RAF (which, by definition and design, remains solution independent). As such, the comments are considered out of scope. The only specific comments to the SOA-RAF are very general and not actionable by the committee.

 

On behalf of the committee, I would like to thank you nonetheless for the time and effort that you have given to reading our work and I wish you all success in your endeavours.

 

Best regards,

Peter Brown

Co-Editor, SOA-RAF

 

Peter F Brown

Independent Consultant

www.peterfbrown.com

P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.310.694.2278

 

From: klausner@ [mailto:coretalk.net klausner@coretalk.net]
Sent: Monday, 05 September, 2011 07:02
To: soa-rm-comment@lists.oasis-open.org
Subject: Comment on the Reference Architecture Foundation for SOA

 

CoreTalk's comment on the

Reference Architecture Foundation for Service Oriented Architecture (Version 1.0)

 

As much as we laud the efforts of OASIS to bring order to SOA through the standardization process, widespread industry usage remains hindered due to the sheer complexity for uniform encoding the governance, interaction, and management dimensions of the problem space.  Einstein is quoted on page 41, "Make everything as simple as possible, but no simpler."  Unfortunately, the 120 page SOA draft document is far from simple or optimal.  Perhaps a different Einstein quote might be heeded at this juncture, "Insanity: doing the same thing over and over again and expecting different result."  This comment introduces an alternative architecture that might lead to a more effective result.

 

I was an invited speaker at the MITRE XML for Binary Interchange Conference and submitted this presentation abstract.  Our Cubicon architecture has greatly evolved since September, 2004, to where SOA is now one of many of its infrastructure capabilities.  The expanse of the architecture spans from high level governance issues down through a bit-level set of blueprints, codified in ANSI C as a context-aware virtual machine (VM).

 

From this broad and deep understanding of the problem space, we read the OASIS architecture document as a gallant effort to convey the relationships between many complex abstractions of system interactions.  It leaves open many degrees of freedom for interpretations and implementations, all of which expand complexity that further retards effort to standardize.  Cubicon brings two key elements to the SOA solution space, a converged architecture and use of extensive automation.  Taming general systems complexity was accomplished by specifying Cubicon in itself, a graphical executable design language.

 

Our focus is to address the architectural challenges for the National Strategy for Trusted Identities in Cyberspace (NSTIC) initiative.  We attended the first two workshops hosted by NIST and submitted a whitepaper (8-Cubicon (CoreTalk)) in response to the Notice of Inquiry (NOI).  We note that Oasis also submitted a comment.  Of the 56 submissions, Cubicon was the only comment that addressed the architectural challenges that could help transform NSTIC's vision for a scalable Identity Ecosystem into an actionable strategy.  By providing technology-based governance mechanisms that support evolving legislative policies, Cubicon can further assure the NSTIC objective is accomplished.  Another way that Cubicon addresses the objective is to provide a service layer that automates the interactions between identity providers and relying parties.  This layer forms the foundation for a Trusted Infrastructure for the Ambient Cloud of which SOA is an integrated capability.

 

A referenced animation on Cubicon illuminates two slivers of the architecture.*  The first sliver introduces the concept of community that has the same meaning as a social structure.  The second sliver is a dialog service that today would be represented by a XML schema and a Document Object Model (DOM).  The difference is that the RosettaNet PIP 3A1 example schema expressed in Cubicon will execute in binary without parsing, thus allowing for deep packet inspection, while always remaining in semantic context to the community.  Community automation maintains the integrity of the dialog service through ongoing revisions, guaranteeing synchronization of usage between community members in a natively distributed topology across the Internet, all without writing a single line of code or script.

 

We have not formulated a plan as to how CoreTalk could work with OASIS besides observing that the adoption of Cubicon architecture would greatly accelerate the global usage of electronic services across business and IT.  In the larger context, Cubicon is a meta-standard technology, quite effective at managing the full life cycle of standards across the spectrum of electronic information exchange.  While the Cubicon technology is proprietary to CoreTalk, we recognize the need for open licensing to assure its broad adoption across cyberspace.

 

Respectfully submitted,

 

Sandy Klausner

Founder & CEO

CoreTalk Corporation

www.CoreTalk.net

408.621.4709

 

 

*The Cubicon Primer2 animation may be downloaded from the CoreTalk FTP site using User: Cubist1 and Password: Sandy2.  The movie requires the Shockwave player to execute. This particular movie scenario does not have a sound track, but you may pause to read the dialog boxes that provide initial explanation of the community architecture.  The remainder of the scenario navigates through the IDE, providing the following depictions:

 

1) Community window highlights the Language Element directory that inventories the core components used by members to represent shared executable designs.  All communities use the same recombinant language element types, enabling absolute design reuse in and between communities of practice.

 

2) Composition window graphically depicts the RosettaNet PIP 3A1, replacing XML schema elements with blocks in a part-of schema. A particular block is opened, revealing its typed attribute slots.  Attributes and even units of measure (linked to NIST's System of Units (SI)) are also sharable core components.

 

3) Genealogy window depicts the source for the blocks as templates (similar to O-O classes) represented in is-a schemata.  A change in a template's attribute slot structure would automatically update the blocks represented in multiple composition schemata. This updating capability extends into the instructions that are automatically downloaded into particular VMs for processing instances of a particular dialog service type.

 

4) Behavior window depicts the RosettaNet PIP 3A1 as a nested set of collection structures that contain the actual data, akin to a DOM.  The difference in Cubicon is that a binary dialog service does not require parsing, is highly optimized, and intrinsically secure.  Community automation creates and maintains both input and output manifest API calls, used by developers to interface to host applications.