[
Lists Home |
Date Index |
Thread Index
]
On Feb 26, 2004, at 9:19 AM, Chiusano Joseph wrote:
>
> Stepping away from REST for a second (but acknowledging that REST was
> your main intent), this is the essence of service-oriented
> architectures
> (SOAs) - shared (non-redundant) business logic encapsulated as shared
> services that can be published, discovered, and bound/invoked (at
> design
> time and/or run time)
I think this is a crucial point! It's not clear who inspired what, or
when one idea emerged in which subculture, but the Web and Web services
worlds have converged on a lot of the same ideas about coarse grained,
loosely coupled, document-driven services. I had drafted language for
the Web Services Architecture Note to the effect that the Web *is* an
SOA designed to deliver the service of transferring resource
representations around, but that got left on the cutting room floor.
Maybe I just didn't explain it well; Joe seems to be making a very
similar point.
> The coordination aspects you discuss above are
> covered by emerging specifications such as IBM/Microsoft/BEA's
> WS-Coordination/WS-Transaction (WS-Transaction is now segmented into 2
> specs, WS-AtomicTransaction and WS-BusinessActivity) [1][2],
> WS-Resource
> Framework (WSRF) [3] from the Globus Alliance/IBM/HP, and OASIS
> Composite Application Framework [4]. References [1][2][4] involve the
> specification of a "coordinator" that coordinates the actions of
> multiple Web services for requirements such as 2-phase commits, error
> notification, etc. Reference [3] addresses interations of Web services
> with stateful resources.
There are an immense number of good ideas floating around in that stew
of specs, and I'm pretty sure that some of them are usable in a RESTful
way. I'm also pretty sure that the whole WS-* stack is overkill for
the vast majority of Web developers (although perhaps not for
enterprise integration developers). On the other hand, the enterprise
integrators often have secure, centralized, transactional middleware
and DBMS software they can leverage for this purpose and I'm not at all
sure they need WS-level standards just yet in order to get serious work
done. I would like to see a longer period of experimentation to find
out which combinations of existing infrastructure, which
enterprise-scale implementations of existing XML specs (such as
XPath/XSLT), and which pieces of the SOAP/WSDL/UDDI/WS-* really can be
put together in a way that solves real business problems before we
worry too much about standardizing the new stuff, or baking it into the
core of operating systems ;-)
>
> It is important to note that none of these specifications are "open
> standards" (in OASIS and W3C-"like" terms) - the one closest to
> becoming
> an open standards at this point is WS-CAF.
>
Ahem. Indeed. Not necessarily wanting to fan the flames in the
XUL/XAML permathread, but I'm very uncomfortable with the way the
dominant vendors are trying to keep this under control and steer it in
the direction they think will be most profitable. We all known what
computer science by committee leads to (e.g. W3C Schema and XQuery --
years later than expected, massively more complex than minimally
necessary, and probably without fully interoperable implementations for
years to come). It's not clear to me that design by invitation-only
committee will work all that much better than design by committee in
a (relatively) open process. Lots of people want to believe that the
WS-* process will work because it keeps the riff-raff who ask annoying
questions away while the Big Guys decide our future. Nice theory, but
a) the riff-raff will eventually be the ones voting with their feet for
or against it, and b) if you think the collaboration of Microsoft and
IBM will set the standard, so you should stop worrying and learn to
love the bandwagon effect, you are not old enough to remember OS/2.
<duck>
|
