RE: [soa-rm] Re: [ebsoa] RE: [fwsi] RE: [soa-rm] RE: [ebsoa] The real SOA challenge?

Rex,

 

I believe this highlights another difference - one based on
engineering bits-and-bytes and technical "build it and they will come",
as opposed to one based on business functional requirements that provide
top down vision and leadership.  The former hopes that it will meet
the latter - and hence the realization that the devil is in the details
in trying to assertain if it does and what the gaps are...

 

There is a better way of engineering - but unfortunately that tends
to cut across those VP Sales and Marketings quarterly sales projections
by not explicitly including their pet product... and that's the beauty
of SOA - since noone has a clear picture of what it really is - any can
sell anything as SOA enabled.

 

; -)

 

DW

-------- Original Message --------
Subject:
[soa-rm] Re: [ebsoa] RE: [fwsi] RE: [soa-rm] RE: [ebsoa] The
real
SOA challenge?
From: Rex Brooks <>
Date:
Tue, February 14, 2006 8:46 am
To: John Hardin
<>, Goran
Zugic
<>
Cc: "Hungenahally,
Suresh" <>, "David
Webber
(XML)" <>, Duane Nickull
<>,
"Jones, Steve"
<>,
,
,
, "'ebSOA
OASIS TC'"
<>,
, James
Bryce Clark
<>,
,


The SOA Reference Model will be
in public review for a while, and I 
believe it provides a basic,
non-specific framework to guide this 
discussion. The SOA RM TC is
standing up an Reference Architecture 
(RA) Subcommittee (SOA-RA
SC), embarking on a Reference Architecture 
effort.

This is
of obvious interest to me as I head up a federal CIO Council

Semantic Interoperability Community of Practice (SICoP) Semantic

Interoperability Architecture (SIA) Pilot Project that currently

fields 12-16 companies. We just demonstrated our network at the

Fourth Semantic Interoperabiity for E-Government Conference last

Thursday and Friday.

I agree with John, on this very brief
overview.

The devil, of course, is in the details, where we will
need to 
specify how one puts together the Trust Network and the
Federated 
Registry/Repository System. For our my pilot's purposes
the Trust 
Network plans to start by incorporating XACML in the
ebXML registry 
portion of our registries component. Overall, our
Trust Network and 
Registries will employ the OASIS triumvirate of
specifications, SAML, 
XACML and WSS, and we will be creating both
ebXML and UDDI Registries 
for the two areas on which we focus. One
area is Emergency 
Management--using the Common Alerting Protocol
(CAP) and the 
Emergency Data Exchange Language (EDXL) Distribution
Element 
(EDXL_DE) that is soon to be released for public comment.
The other 
area is Health Informatics, which will require a major
effort to 
align with existing and developing health standards. I
plan to work 
that effort through the OASIS International Health
Continuum TC and 
the National Center for Ontological Research's
(NCOR's) Committee on 
Ontology for Health Informatics to bring
practical interoperability 
to this area.

I go into such
details simply to make the point that the Devil really 
IS in these
details, and interoperability where the rubber meets the 
road
depends on it, and not on marketing hype or the battle to own a

bigger share of the public mind, so to speak. Unfortunately, the
race 
to market plays by its own rules, and the best we can hope to
do is 
to bring a better, better-thought-out, and more inherently
stable and 
adaptable structured alternative to the largely ad hoc
efforts in the 
wild and wooly weed patch of SOA as we see it
today.

Cheers,
Rex

At 2:07 PM -0500 11/16/05, John
Hardin wrote:
>It's all very simple from my
standpoint:
>
>Federated Trust Network
>Federated
Registry / Repository
>Customized Executable Business Process
which operate on those 
>federated
networks.....
>
>Goran Zugic wrote:
>>David, I do
not want to argue about the history. SOA (Web Services,

>>ebXML, and many other SOA related concepts, standards,
etc.) has 
>>not suddenly emerged from nowhere.
>>
 Suresh, if I understand correctly your point, you think that the

>>business process modeling, grouping and taxonomy of
processes are 
>>important SOA enablers. I completely agree
with you. It is very 
>>important but not the only aspect of
the entire SOA picture. What I 
>>am also interested in is the
SOA enterprise architecture and real 
>>alignment between the
business and technology. No marketing hype 
>>but real stuff.
These are my questions. Not only for you but for 
>>everybody
on this thread. I am just using these questions to 
>>continue
with discussion. Do not worry I will provide my answers

>>later and I hope that you will keep adding new questions as
well. 
>>The more questions and the more discussions trying to
form answers 
>>the better. I am sure we will not change the
world but at least we 
>>can start to communicate more often
and exchange ideas.   1. How do 
>>we integrate business
processes we model as services and 
>>technology? Here I mean
a real automatic integration without army 
>>of developers
working on the "SOA Enterprise Architecture"  to

>>implement processes just modeled or to implement changes
just 
>>introduced. To me that kind of architecture is not
SOA. That is old 
>>school which we shortly talked about in
our history introduction.
>>  2. How do we make SOA
agile? Again automatic implementation of 
>>changes without
coding and both static and dynamic.  3. How do we

>>model and support business process semantics? Not just
message 
>>exchanges and message routing.
>>  4.
How do we use standards and support standard convergence?
>>
 5. What is our SOA Reference Model?
>>  6. What is
our complete SOA reference architecture?
>>  7. Do we
have an SOA methodology and what the SOA methodology is all
about?
>>  8. What are our SOA best
practices?
>>  9. What are the most critical SOA missing
points and failures so 
>>far and how to fix them or not
repeat them?
>>  10. What is the overall OASIS plan with
regards to SOA, SOA TCs 
>>related work and their
relationship?
>>  11. How can we start to work together
and use each others "products"?
>>  12. How can we (TCs
and OASIS) convince more leading vendors to be 
>>involved in
the SOA specs development and start using SOA specs we 
>>are
working on?
>>   I think that we should keep the entire
original content of the 
>>messages for the completeness of
the thread.
>>  Goran
>>
>>  
  ----- Original Message -----
>>     *From:*
Hungenahally, Suresh
<mailto:>
>>  
  *To:* David Webber (XML) <mailto:>
;
>>     
<mailto:> ; Duane
>>  
  Nickull <mailto:> ; John
Hardin
>>     <mailto:> ;
Jones, Steve
>>    
<mailto:>
>>    
*Cc:* 
>>    
<mailto:> ;

>>    
<mailto:> ;

>>    
<mailto:> ;

>>    
<mailto:> ;
>>    

>>    
<mailto:> ;
>>  
  
<mailto:> ;
>>    

>>    
<mailto:> ;
>>  
  
>>    
<mailto:>
>>  
  *Sent:* Tuesday, November 15, 2005 11:06 PM
>>  
  *Subject:* RE: [ebsoa] RE: [fwsi] RE: [soa-rm] RE: [ebsoa] The
real
>>     SOA challenge?
>>
>>
    Hi,
>>     
>>    
I am new to the group.  Please bear with me if I do not
understand
>>     how this works.
>>  
  
>>     Agree 100% with David Webber, the key
is in this point that David
>>     makes  "So
much for history - no need to dwell there - the challenge
>>
    now is to bring *real business enabled XML-driven
processes and SOA
>>     to fruition."*
>>
    **     Which means we need to clearly
address:
>>     
>>     1. SOA
and processes integration by broad domains (Finance, Telco,
>>
    Transport, Defence, Government etc.) We could use models
such as the
>>     eTOM as a starting
point.
>>     2. Establish a standard grouping of
processes within the business
>>    
domains
>>     3. Then look at which of these can be
enabled using XML.
>>     4. In Australia the DOMEDI
group did similar work in the Transport
>>    
domain (thouogh for a different purpose)
>>     5.
Finally a taxonomy of the business, processes, enablers and
XML
>>     transactions
>>    

>>     Regards.  Suresh
>>  
  
>>    
________________________________________________
>>  
  
>>     Dr. Suresh Hungenahally| *Capgemini*
| Melbourne
>>     Senior Manager
>>  
  477 Collin St. Melbourne 3000 Australia
>>    
T.  + 61 3 9613 3343 | M. + 61 402 408 816| F. + 61 3 9613

>>3333.     E.

>>    
<mailto:>   |  
www.capgemini.com
>>    
<http://www.capgemini.com>
>>     
>>
    *Join the Collaborative Business Experience*
>>
   
________________________________________________________
>>
    
>>
>>    
------------------------------------------------------------------------
>>
    *From:* David Webber (XML)
[mailto:]
>>     *Sent:* Wednesday,
16 November 2005 2:55 PM
>>     *To:*

<mailto:>;
>>    
Duane Nickull; John Hardin; Jones, Steve
>>    
*Cc:* ;
;
>>    
; ;
>>
    ;
;
>>    
;
>>    
; 
>>
    *Subject:* Re: [ebsoa] RE: [fwsi] RE: [soa-rm] RE:
[ebsoa] The real
>>     SOA
challenge?
>>
>>     Goran,
>>
    
>>     While I like what you say vis
SOA here - I have to take you to task
>>     on
history ; -)
>>     
>>     The
ebXML foundation came out of the work of the XML/edi Group
>>
    aligned with the work of CEFACT on ooEDI.
>>
    
>>     It completely breaks the mold
on EDI.  Yes - things like ebMS are
>>    
founded on EDI+ communications - but the core of the ebXMl stack
-
>>     registry-centric XML-driven collaboration -
and the notion of the
>>     "Fusion of Five" is
designed to sweep away the old EDI 
>>practices.    
Unfortunately XML as implemented today is nothing 
>>more than
a
>>     slightly better EDI.  The whole XML
revolution is yet to truely take
>>    
hold.
>>     
>>     As for web
services - this was a shameless grab by IBM and Microsoft
>>
    - attempting to be first to market ahead of ebXML with
concepts that
>>     in essence are nothing more
than "real-time EDI" - with all the same
>>    
strengths and weaknesses of the
>>     original
real-time EDI implementations - just using XML and the
>>
    internet instead of EDI and private networks.
>>
    
>>     So much for history - no need
to dwell there - the challenge now is
>>     to
bring real business enabled XML-driven processes and SOA to
fruition.
>>     
>>     Cheers,
DW
>>
>>         ----- Original
Message -----
>>          For
example, Web Services are initiated with an idea of
>>  
      services introduced by Microsoft 6-7 years ago and
this idea has
>>         been formed from
distributed computing and component-based
>>    
    computing ideas and "learn on mistakes" lessons from
many
>>         organizations in 80s and
90s; ebXML is mostly based on EDI ideas
>>    
    and "learn on mistakes" lessons,
etc.
>>
>>     This message contains
information that may be privileged or
>>    
confidential and is the property of the Capgemini Group. It
is
>>     intended only for the person to whom it is
addressed. If you are not
>>     the intended
recipient, you are not authorized to read, print,
>>  
  retain, copy, disseminate, distribute, or use this message or
any
>>     part thereof. If you receive this message
in error, please notify
>>     the sender immediately
and delete all copies of this
message.
>>
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>|
 john c hardin
>|  Chief Technology Officer
>|
 http://www.maphin.net
>|  606.598.7353 office
>|
 606.813.4316 cell
>|
 mailto:
>|
>|  Chair - OASIS
ebSOA Technical Committee
>|
 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
>|
>|
>|
 "The new electronic interdependence recreates the world in
the
>|   image of a global village."
>|
>|
   Marshall McLuhan, "Gutenberg Galaxy",
1962
>|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--

Rex Brooks
President, CEO
Starbourne Communications
Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel:
510-849-2309