[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] FW: Comment on the Reference Architecture Foundation for SOA
Sorry to intervene here as a process hound but I think this statement is necessary to consider: "We have not formulated a plan as to how CoreTalk could work with OASIS besides observing that the …". Since it is unclear in terms of context of contributions (OASIS member vs. ???) and IPR of contributions; and witnessing that CoreTalk has not (to my knowledge) been contributed to OASIS, we cannot consider it. This also means that they have no concrete proposal's. Peter's observations are correct. The two comments on the RAF are considered and IMO should be rejected since they are not actionable. They are simply observations of a problem with implementation. Note that no alternative architecture is actually proposed and he acknowledges this. What I would recommend:
My $0.02 CAD (now worth slightly more than $0.02 USD). Duane From: Peter F Brown <peter@peterfbrown.com> Date: Tue, 20 Sep 2011 10:06:56 -0700 To: "soa-rm-ra@lists.oasis-open.org" <soa-rm-ra@lists.oasis-open.org> Subject: [soa-rm-ra] FW: Comment on the Reference Architecture Foundation for SOA Hi, We received the comment below in response to the public review. Here is my summary assessment: -
In his own words, “ this comment introduces an alternative architecture” and does not, therefore fulfil the aim of the comment process; -
On the RAF itself, the only comments are “…the 120 page SOA draft document is far from simple or optimal”; and is “a gallant effort…[which]…leaves
open many degrees of freedom for interpretation and implementations” -
Most of the comment is concerned with promoting the “alternative architecture” and it is not our place to comment on or judge that. As such, I would conclude that the comment is out of scope as it promotes a specific solution architecture rather than addressing issues within the RAF itself.
I would suggest that this is the committee’s response to the submitter Regards, Peter Peter F Brown Independent Consultant P.O. Box 49719, Los Angeles, CA 90049, USA Tel: +1.310.694.2278 From: Peter F Brown
Ok, received properly, we'll follow up now... From:
klausner@ 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]