|
Thanks Ken,
I appreciate having the report to substantiate my position, which
is, as the report notes, that both SOAP and REST are here to stay, In
fact, I spoke up at last week's Collaborative Expedition Workshop to
note that the EDXL-DE and other standards in Emergency Management are
transport independent, and support either SOAP or REST even if the
focus is more on SOAP-based systems. That's why I explicitly supplied
an example of where I think a REST approach is more appropriate than
SOAP, and noted that all of the things that are enabled in a
systematic approach with SOAP-based systems can be done now with
existing tools and protocols.
We have a tendency to be in agreement on this stuff. I'm sure
we'll eventually find something we disagree about, but I won't go
looking for it. ;-)
Cheers,
Rex
Rex,
re the REST/SOAP debate, I'd suggest you
take a look at the workshop report (http://www.w3.org/2007/04/wsec_report) for the W3C workshop on
the Web of Services for Enterprise Computing. The overwhelming
conclusions are that neither REST nor SOAP is going away, each has
strengths and limitations, and our challenge is to stop arguing and
make the sucker work. This has as much to do (if not more) with
cleaning up the current pieces rather than pushing forward for more
pieces. The report has some specifics.
I was one of the co-chairs of the
workshop and I presented an early summary (but one that turned out to
be 99% on target) at the last SOA eGov Conference. The workshop
report has been issued since then.
Ken
On Jun 28, 2007, at 11:23 AM, Rex Brooks
wrote:
Thanks for the forward,
Brand,
I didn't have the time to join the
teleconference Monday, and I have not been active in this group since
the early days, but since then, it has become apparent that the SIA
(Semantic Interoperability Architecture) Pilot Group I led is likely
to be ready to demonstrate the ongoing evolution of a more mature
"operational" SOA collaboration, implementing the principles
of NIEM (National Information Exchange Model) and JIEM (Justice
Information Exchange Model) as well as the operational implementation
of the Emergency Data Exchange Language Distribution Element (EDXL-DE)
in a more robust national network and it fits the use case for
Internet-Centric Emergency and Stability operations. This grows out of
both the OASIS Emergency Management Technical Committee (EM TC) and
the OASIS SOA Reference Model TC (SOA-RM TC). This set of capabilities
supports the work to develop the mandated Integrated Public Alert and
Warning System http://www.whitehouse.gov/news/releases/2006/06/20060626.html
However, that may be moot since a quick
glance at the proposed agenda shows that there is not likely to be a
call for presentation proposals for demonstrations. The tutorials
appear to be unconfirmed, but I'm not sure that our approach would be
welcomed given the appearance that the agenda presents of established
interests settling into established niches. I sincerely hope that this
is appearance only since I heartily disagree with the single most
important architectural principle for boundary-crossing aggregations
of services, namely REST for Internet-Centric SOA.
I'm not spoiling for a conflict over REST
v. SOAP and our collaboration is WSDL/SOAP-based.
My opinion is that REST is extremely
limited and unlikely to prove out as the principle on which a workable
web services SOA platform evolves. That doesn't mean that I don't
think it is viable, just that it is limited and would quickly become
tedious and cost-ineffective when ease of replication and ease of
aggregation become the determinant factors.
That doesn't mean that the necessary
infrastructure of IT standards for implementing SOAP/WSDL-based web
services rapidly and effectively is yet in place. Some standards are
in place and too many others are dwindling for lack of support.
However, I expect that this is a temporary stall due to the fact that
SOA web services have not "exploded" as the next big thing
in the way that we all came to expect following the initial explosion
of the web itself. We are only now understanding that the
infrastructures for the Semantic Web and for SOAP-based SOA need to be
built and it is not going to magically happen all by itself. However,
in the meantime we have a spectrum of methods from AJAX to REST which
can be assembled now using JSP, ASP, PHP, etc.
Where REST is clearly superior is in the
aggregation of services that are expected to be combined in a singular
set of usages between enterprises that are not also contemplating or
planning to make their services available to a wide variety of
possible partners, e.g. between a research university and private
enterprise for a single purpose project or study or set of projects or
studies.
For our part, the community building
WSDL/SOAP-based standards for services are still slogging along in the
trenches. This is difficult and sometimes aggravating
work.
The work cycles for developing standards
to enable an effective SOAP-based web services architecture are
proving, perhaps fatally, susceptible to the "Second System
Syndrome." We turned out v1.0 of SAML, WSS, WSRP, etc
fairly quickly, got those standards to work, but did not put in the
effort to stimulate adoption. The follow up work has since bogged down
because as we all know, the devil is in the details and choosing which
of the many details were expeditiously left out of v1.0s is proving
tiresome. WSRP v1.0 took two years. 2.0 is just now going into its
60-day public review and it is three plus years later.
Yet, some progress on SOA has also been
made.
I expect that with the advent of the
Global Justice Reference Architecture http://www.it.ojp.gov/topic.jsp?topic_id=242 which is based on the the OASIS SOA Reference Model http://www.oasis-open.org/home/index.php ,
and with the SOA-RM TC's upcoming "Reference Architecture"
specification, following up the SOA Reference Model established last
year, I think that the conceptual toolkit will be complete. This will
allow fitting existing standards into that toolkit of Reference Model
with Reference Architecture for SOA and will eventually prove out to
be the most sensible set of SOA principles.
Cheers,
Rex
Please see below and provide comments to
Bob Marcus directly in preparation for the 4th SOA for E-Government
Conference.
Thanks, Brand
-----Forwarded by
Brand Niemann/DC/USEPA/US on 06/28/2007 08:02AM -----
To: Brand Niemann/DC/USEPA/US@EPA
From: "Bob Marcus" <bobmarcus1@xxxxxxxxxxx>
Date: 06/27/2007 04:14PM
Subject: Re: Draft Recommendations
Brand:
I believe that it will be possible to present
the content of the draft at the 4th SOA for E-Government
Conference. While the draft is going through the approval
process, I think it would be worthwhile to get input on the
approach for creating recommendations. The attached document is an
focused extract that can be widely circulated. I would be interested
in any feedback from the SOA COP. Thanks.
FYI: I divide interoperability architectures into
three categories (Intranet-Centric, Extranet-Centric, and
Internet-Centric) based on collaboration patterns. This enables me to
tailor the recommendations rather than having a single standard for
every situation. (e.g. closer collaborations enable more tightly
coupled standards.)
Bob Marcus
======================================================
----- Original Message -----
From: Niemann.Brand@xxxxxxxxxxxxxxx
To: Bob
Marcus
Sent: Monday, June 25, 2007 5:32 PM
Subject: Re:Draft Recommendations
Bob, Thanks for sharing this with me and hopefully it will
be approved in time for presentation at the 4th SOA for E-Government
Conference.
Brand
-----"Bob Marcus"
< bobmarcus1@xxxxxxxxxxx > wrote: -----
To: Brand Niemann/DC/USEPA/US@EPA
From: "Bob Marcus" < bobmarcus1@xxxxxxxxxxx
>
Date: 06/18/2007 03:40PM
Subject: Draft Recommendations
Brand:
I created the attached draft report in response to a
request for information on "Industry Standards for C2
Common Core Data Model & Framework" . I thought it would be
valuable to get your input.
Please don't circulate since it is just a draft.
Thanks
One of the key ideas in the report is that recommended standards
should be tailored to specific use cases e.g. Intranet-Centric,
Extranet-Centric, and Internet-Centric. For example, in general the
report recommends RESTful services for Internet-Centric, SOAP-based
Web Services for Extranet-Centric, and ESB middleware services for
Intranet-Centric. I would be interested in your feedback on this
approach. Thanks.
Bob Marcus
720-352-0784
FYI: I am proposing a Customer Engagement Process based on operational
scenarios and interoperability use cases. See below. I think that it
will also be useful in general enterprise consulting e.g. for REST
vs.SOA decisions and data integration solutions.
The steps in this process include:
* Creation of Engagement Teams to interact with specific customers
(e.g. to develop and manage deliverable planning and related
activities)
* Documentation of customer operational scenarios and missions that
will drive interoperability requirements and constraints for
deliverables
* Mapping of operational scenarios to interoperability use cases that
are the basis of the deliverable.
* Development of interoperability demonstrations to validate
specific recommendations for standards in deliverables.
[attachment "JFCOM CRADA Deliverable Draft.doc" removed by
Brand Niemann/DC/USEPA/US]
[attachment "Operational Scenarios and Use Cases.ppt"
removed by Brand Niemann/DC/USEPA/US]
=
Attachment converted: Macintosh HD:Interoperability Use Cases.doc
(WDBN/«IC») (002BC43D)
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7515 Colshire
Drive fax:
703-983-1379
McLean VA 22102-7508
_________________________________________________________________
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (01)
|