Long term , the proper vision is to make
an standards adoption that offers forward thinking transformation of the IT
capability to respond to GENERIC and DYNAMIC human to human transaction spaces.
I feel that human markup language standard
(OASIS) on which Rex has been working for many years should become essential to
SOA implementations before the year is out (prediction).
Farrukh, I am personally
appreciative of the note that you have sent below, I agree
completely, UDDI might be simpler when used by itself in specific transactions
spaces? If so, then an interoperability wrapper (designed as Joe is
suggesting) seems to be straight forward. But true natural SOA has a long
way to go in terms of re-use, agility, composition and usability, and for this –
at least one would like to know if ebXML is completely sufficient.
The demo might test this “hypothesis”?
But how?
Your work, and other’s work, on the
dual notions of registry and repository provides an authority over such a
hypothesis.
See for example the wiki at
http://ebxmlrr.sourceforge.net/wiki/index.php/Overview
My sense is that methodology is needed
that identifies a small set of data definitions and process models – in a
specific historical and transaction context. This should be
contract driven, so that human’s can simplify the details.
In my opinion, OASIS BCM moves us (me) in
that direction… and here is where SOA functions (that are non-IT centric)
might be demonstrated.
I have studied the BCM spec, and am
interested in developing a demonstration of how SOA and BCM might work together
to reflect the concerns of my last message..
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On
Behalf Of Farrukh Najmi
Sent: Monday, March 27, 2006 7:06
AM
To: Service-Oriented
Architecture CoP
Subject: Re: [soa-forum] The
purpose of a SOA demo
Paul Prueitt (ontologystream) wrote:
Joe,
Excellent
article at
http://www.ebxmlforum.net/articles/ebFor_20030824.html
It
would seem that you, Cory, Andrew, Farrukh and Rex have positions (regarding
registry and repository) that are very close and saying (for various good
reasons) that ebXML should interoperate with UDDI because it can and because of
the previous market adoption of UDDI. You are also saying (I
conjecture) that there is no other “registry/data definition”
standard that needs to be considered?
....
Is
this fair and proper to say? Do all concur?
Hi Paul,
I suspect that what I am about to say is not all that critical to our demo but...
I wanted to offer a clarification on my position on interop between UDDI and
ebXML Registry since it is not quite what is in this paper:
http://www.ebxmlforum.net/articles/ebFor_20030824.html
First interop of any kind is a "good thing (TM)". That said, I feel
that organizations SHOULD NOT deploy both a UDDI and an ebXML Registry if they
can help it. Instead they should deploy a single registry that:
a) Only supports ebXML Registry standard, or
b) Support ebXML Registry standard at its core and offers a UDDI interface as
an option to the native ebXML Registry
The reason is that managing two registries and two registry standards, is
architecturally messy, costly and more importantly, unnecessary.
The one reason I can think of for an organization to have 2 kinds of registries
is that they have a legacy UDDI registry that is in production use but is not
enough to meet their requirements and they are therefor transitioning to an
ebXML Registry and need to have both for an interim period until the legacy
UDDI registry can be retired.
In summary, I understand the need for two kinds of registries and limited
interop between them for legacy reasons. I do not advice that as an architecture
that is consciously planned and designed. Also, for the record I want to
predict that heterogeneous federation of UDDI and ebXML Registry's is never
likely to happen, as described in the paper.
So respectfully, and for the record, I must say that while Joe and I have many
years of fruitful collaboration on many fronts, much of the "UDDI and
ebXML Registries: Three-Tier Vision" is not a vision that I have *ever*
shared. Joe and I have remained good friends and colleagues despite the
difference of opinion over this paper.
Thanks.
--
Regards,
Farrukh