|
I
understand that a consensus process is occurring, and that maybe over time this
process may produce deep and satisfactory demonstrations of a SOA paradigm that
is now several years old.
The
evidence is, however, that essential natural principles related to response
to novelty are simply ignored, and that the CIO Council lead consensus is
not directed at building the highest quality SOA demonstration, but rather in
supporting IT vendors' marketing of outdated technology.
The
problem is in regards to the assertions and assumptions of that <small>
part of the social world.
This
small part of the social world are those IT vendors that are able to
participate in the consensus process that you are referring to.
I have
made the case, as have others, that the CIO Council mediated consensus is not
truly open due to pragmatic issues related to expenditure of time and
resources. Not everyone has the over head budgets to support
efforts. Small innovators are excluded, and large IT vendors are vested in
the status quo.
Again,
the notion that vendors using the current IT procurement models are the only one
that are in a position to follow and participate in the current US Federal CIO
Council endorsed SOA demo developments.
The
alternative is that the government, say the CIO Council, would NOT require
that this process of evaluation of the SOA paradigm be made by volunteers, who
come only from the IT vendor community. One could have a National Project
to reground IT in natural science:
or
one of
the national labs could easily take on the development of SOA infrastructure
that was more richly informed by disciplines such as social network theory and
human computer interface design.
Some
claim that IF the government would regard web-service infrastructure development
as a responsibility, then huge savings would occur over what is now
expected. I am willing to lead a (funded) process that investigates this
claim.
A
web-service infrastructure developed by deep innovation and simplification of
the current mess could be compared to the buzzing confusion that has developed
because for example:
1) the
W3C continuing insistence on RDF/OWL over Topic Maps creates deep barriers to
actually using ontology as a means to meditate the service discovery and service
fulfillment orchestration processes. The non-development of "n"-ary
ontology representation is placed in concrete as long as the IT vendors will not
even allow reasonable Topic Map development.
2) in
spite of language that promises open data interoperability, government IT
contractors are vested in competitive advantages that are directly related to
the degree in which IT contractors are able to make web-services
non-interoperable. So we have a structural problem seen in terms of
motivation and re-enforcement; we re-enforce non-solutions.
3) the
deeper elements of a second school of information science (www.secondschool.net) cannot be brought
into a vendor produced SOA infrastructure, simply because the notion (as you
mention) of "basic functionality" actually builds protection to a failed and
failing government IT procurement process, that has been instituted as a matter
of federal law.
4)
because it is in the self interest of the IT vendor community, the IT vendor
community build a business centric orientation, not a event centric
orientation.
Lines
of Business (LOB) and social activity supporting good government are not even
closely aligned, as as a result the exclusion of emerging social activity in
emergency response is being forced away from the event space. This
instrumentation of LOB and the exclusion of social response to crisis has to be
questioned, (as it has been in the recent hurricane responses) now or in the
future when the political axis moves away from the assertions of the current
Administration.
The
issue just raised over the past several days of "core" service definitions and
"fluid edge" is one that is not addressed in any of the current demos.
The
question that needs to be examined, for the Congressional record, is the degree
to which current activities have been rightfully questioned and government
responses made to ignore these rightful questions. This process of
ignoring has legal consequences.
Dr
Paul S Prueitt
Paul,
Based on the
consensus reached the demo we are focusing on is a line-of-business
integration between HR, Finance and program management to track human
resources costs for projects. The consensus is to get this basic
functionality up and running. Once done there are various additional
capabilities and scenarios that could be put against it – for example one
where an LOB service center is wiped out or one where project resources had to
be reallocated due to an emergency. Other examples could be bringing a
new service on line that utilizes the existing ones (perhaps an emergent or
dynamically defined service) – the options are endless. >From the
perspective on enabling the federal transition framework the current
direction shows a lot of value – the integration of loosely coupled
organizations to achieve shared business services. The way to actually
do a LOB architecture is still up in the air, so we think it is a very viable
starting point to showcase SOA.
As far as I know
there is no further development being done on Rex’s emergency response demo –
but perhaps you should contact that group to find
out.
-Cory
From:
soa-demo-bounces@xxxxxxxxxxxxxx [mailto:soa-demo-bounces@xxxxxxxxxxxxxx]
On Behalf Of Paul S
Prueitt
Sent: Saturday,
September 23, 2006 1:00 PM
To: [planning for soa-demo]
Cc: Thomas Erl; David RR Webber (XML);
Niemann. Brand
Subject: Re:
[soa-demo] Ourcome metics on the SOA demos
Is there a wiki page
for the Emergency Response Demo, particularily a page or number of pages that
gives the kind of detail that one would expect eventually would be
developed?
In particular, there
may be a detailed scenario description and the list of all services, with
standard formate for convaying specificdata objects between processes.
There may be a
published standard for core data objects, a registry and repository of service
definitions, as well as demonstration of service discovery and the
orchestration of service responses.
I have to admit that
I have not followed the demo development for months. The demo
discussions and processes started (May,
2006?)
What I was
interested in was how service discovery would be
developed. If, in an emergency, required services are not
available from a standard set of data objects and interfaces, how would a
required service (one that was not in the standard core but absolutely
necessary in the emergery response) be
identified/measured.
The OASIS BCM
(business centric methdology) and SOA Blueprints specifications have a process
model for the aggregation of new service defintion in real time. Was
this process model used in the Emergency Response demo, and if not how are the
issue of novelty addressed?
I approach the
modeling of event space using the notion of natural category. As
recently suggested, there are two types of natural category, natural category
that is stable and natural category that emerges as part of natural
processes.
Services may be
defined as transactions in a natural category space, where the transactions
have charaterisitic event chains. Web-services and "natural
services" then are reflections of each other; sometimes these reflections have
high fidality and sometimes they do not.
Does any of the demos
specifically address the issue of fidality, or of outcome metrics on the
usefulness of a service specification?
-----Original
Message-----
From:
soa-demo-bounces@xxxxxxxxxxxxxx
[mailto:soa-demo-bounces@xxxxxxxxxxxxxx]On Behalf Of Cory Casanave
Sent: Saturday, September 23, 2006 7:19
AM
To:
soa-demo@xxxxxxxxxxxxxx
Subject: [soa-demo] Writing the SOA
demo spec
SOA Demo
Team,
I have started writing into the
SOA demo spec located here: http://colab.cim3.net/cgi-bin/wiki.pl?SoaLobDemoSpec
Please take a look at it and
consider contributing along the lines we have discussed. We should be
able to develop a good deal of the specification on the Wiki – all you need
do is register for the wiki and make updates. If there are open
questions or controversial parts please discuss it on the mail list prior to
changing the spec.
We also need to start work on
the technical considerations – registry and web service details. Lets
try and get “hello world” running very soon.
Regards,
Cory
Casanave
|