Lists Home |
Date Index |
"Bullard, Claude L (Len)" wrote:
> I like the emphasis on composability in that overview.
> As Tim Bray noted, many started this odyssey as document
> geeks. Some do other forms of composition, but composability
> is a tenet that one should contrast to interoperability and
> ask if the common understanding of interoperability is
> correct. Composability assumes that portable
> data requires interoperability first because each part of
> the message assumes a reliable, working service which
> shares definitions if not sharing implementations. One
> can compose nonsense quite easily with portable data
> if one composes statements the system can't reliably
> process. But the web is NOT one system. It is lots
> of little systems all in different lifecycles and
> the chaotic behaviors arise because of that.
> Is the Emperor naked? No. Parts of the WS polyglot
> work reliably. Is he stylishly attired? Do we care?
> Probably not. Is he overdressed? Possibly. So I
> ask about the WS-I and the basic profile. One does
> expect the major companies to get beyond 'basics'
> ahead of the standards. The king and the peasant dress
> differently and the tailors charge accordingly
> and schedules a production run accordingly.
> The emperor was naked because the tailors were dishonest,
> the emperor was gullible, and his subjects were
> politically correct. That isn't a problem here. :-)
> In short, the basics work. WS are following the
> pattern of car manufacturing based on common parts.
> We may not get reliable power brakes as composable parts
> until one or two manufacturers assemble and sell
> them for awhile. So even if slow, the web services
> industry appears to be on track.
Completely agree. This supports my earlier view of looking at the Web
Services landscape in "Waves".
> Again, in this period, we should emphasize specification with an
> eye to standardization.
> A question of interest is when does composition
> create an insecure and unreliable service?
By that I assume you mean, when composing Web Services together (as in a
service-oriented architecture), at what point might one attempt to
include in this composition a service that is insecure (rendering the
composition insecure) and unreliable (rendering the composition
unreliable). I touched on this in a Sept. 2003 thread that I started on
"Web Services and Quality":
For the security piece, I think that much of it comes down to use of
mechanisms such as SAML (to authenticate Web Services to other Web
Services) and WS-Security (once it becomes an OASIS standard). Some of
this will be solved by use of registries (such as UDDI and ebXML), in
which the registry "authorities" are held accountable for the security
and reliability of the services that are registered there. The UDDI TC
is in the process of creating a Technical Note called "Representing Web
Services Quality of Service Information in UDDI" that covers this
concept. The ebXML Registry specifications also have this capability as
well, but a Technical Note has not (yet) been created for it.
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
> one should choose their tailors wisely and if they
> promise magic, be dubious. Once again, the web
> hypeMonster bites.
> From: Dare Obasanjo [mailto:firstname.lastname@example.org]
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
Booz | Allen | Hamilton