Saturday, April 08, 2006
Community Centric Service Methodology Glass Bead Games
"SOA
does not stand alone, nor can it be managed that way. If treated in isolation, Web services will only exacerbate
organizational complexity. Any attempt
to manage Web services in isolation is a grave mistake. From (URL)
Communication from Paul Prueitt
First, I do not wish to presume that the BCNGroup Roadmap has laid out the issues perfectly, but this "Roadmap" is something that seems to reflect both a pragmatic and anticipatory nature... while placing semantic representation into the proper context.
The need for REST or REST-like architecture
One aspect that the Road map is missing is provided by REST (Roy Fielding's work). CoreTalk provides an alternative authorship of the REST principles (with some differences).
REST is not seen (by some) as a truly peer to peer architecture (at least in the 2000 dissertation by Fielding); but ontology Cashe (which is proposed in the Roadmap) could be specified in a OASIS specification.
Andrew, you seem to have the REST principle of a uniform interface down pat... and this is an essential element to the imposition of interoperability "higher" up on a URI / FTP stack.
Controversial statement: The REST stack is different from what TBL proposed (does not get exclusively tied up in RDF). (Replace RDF with nary and we have a go.) John (Sowa) is this how you see it? A degree of interoperability is seen in the development of RDF vocabulary extended to OWL Full. But interoperability could also be ontologically mediated used non-RDF standards… (when they come to exist). The general representational form of an n-ary
< r, a(1), a(2), . . . , a(n) >
is more general that the RDF triple.
I have personally come to see that OWL Full ontology (arranged as an ontology hub - with a minimal "upper abstract ontology" as discussed in the Roadmap) will be an important part of the Pragmatic and Anticipatory Web language. REST can be used to specify cashed ontology "information structure" resources as part of hard wiring some level of semantic interoperability for service webs. In any case, reading and knowing about the REST (representational state transfer) concepts is useful in developing a new specification about ontology mediated SOA.
We also feel that the 2006 OASIS SOA-RM (reference model) is useful both because it is short and because the SOA-RM technical committee established some language and concepts common to any SOA specification.
Definition: Service Oriented Architecture
(SOA) is a paradigm for organizing and utilizing distributed capabilities that
may be under the control of different ownership domains. (First sentence, section 2, SOA-RM (2006)).
To be clear here, it is not "REST" that we are interested in - but in the correct development of software architecture on which to layer specifications like (and I will just name my favorite)
SOA RM
SOA CS
SOA IM
ebSOA
(ebXML as an viable alternative to ebSOA)
BCM
The OASIS BCM may be possibly modified to include (more) pragmatic and anticipatory mechanisms related to choice point and "marshaling" of blueprints for human decision making –
In this context, we use "blueprint marshaling" not to mean XML - although XML marshaling and unmarshaling as part of semantic interoperability is "required". Blueprint marshaling involves a formative process that has a real time component to the formation of choices.
SUN's work on something like ebXML plus REST-type hardware is important to me.
Just to summarize the effort to bring KM practices (but not necessarily all of KM) into a SOA methodology is laded out in the recent conversations with Cory, Joe, and Andrew.
I have had email with Verna Allee and she is excited by the possibilities - but there is a lot of work that my group needs to do to make something that she, and other leaders in the KM community, can interface with. Her huge sucess in the KM space is due in some part to how she values her personal time.
She and Dr Murray (co-founder of the BCNGroup) have recently started a join venture involving GWU and the KM Institute. The key here is putting up a wiki-plus (showing that we have the actual capability to instrument the individual conceptual layer - and the community layer of the OASIS BCM.)
This provides the steps, near term BCM type SOA projects. Second step, pragmatic and anticipatory demonstration.
We will synthesis this effort while revealing principles consistent with a flow diagram that realizes some of the "project justification" work that Ralph has show us .... and with the notion that a higher level of complexity exists within the organization than outside the organization . In other language, the pragmatic and anticiaptory mechanisms are stronger at the individual level that within the organizational layers. This observation is constrained by observations in a world where social organization may not have the type of control that individual intelligence has (ie no front lobe in social organization). (But this is a longer story..)
Both of the flow diagram and the distinction between organizational complexity and environmental complexity are novel, . . and yet reflect real phenomenon impacting the use of the OASIS BCM .....