W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: architecture question

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Wed, 20 Mar 2002 08:53:29 -0800
Message-ID: <3B286631A9CFD1118D0700805F6F9F5A09D09CD2@hou281-msx1.chevron.com>
To: "'Tim Coote'" <tim@coote.org>
cc: "'www-ws-arch@w3.org'" <www-ws-arch@w3.org>
Have you seen the thread on "business infrastructure", for example
http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0269.html?  The
draft usage cases at
usecases.html?  The thrust of my interest in the "business infrastructure"
issues is to try to ensure that web services have the capability to take on
at least some of the functions served now by proprietary EDI VANs.

Can you help me understand better what you have in mind for us to be doing
here that we are not?  I'm honestly having trouble translating this into
specifics related to web services, even though you kindly include some
specific examples.

To some extent I suspect that the answer to your question may be that your
concerns are more likely to be addressed in OASIS, particularly in the ebXML
TC's, but if there is something in our scope here that we are missing I'd
like to try to address it.

I believe, incidentally, that part of the expectations for web services is
that they can provide wrappers for legacy applications that will
"web-enable" them.  One scenario, I suppose, might be to interface into the
"oldish" applications via adaptors like thos supplied by EAI systems and
then to expose these interfaces as web services. I think that there is
considerable scope for web services in this area, as well as EDI-like
operations, that really do not depend a real lot on actual runtime discovery
and description but where these functions are done up front in some sort of
business agreement.

The most obvious business applications for web services probably involve
purchasing transactions, but there are plenty of other possibilities.
Regulatory information, for example.  If you look at these examples it seems
to me that at least some of the information involved with your concerns may
be  carried by the "payloads" that are delivered by the web services, not
the web service itself.  That's why I suspect that OASIS and ebXML may be

-----Original Message-----
From: Tim Coote [mailto:tim@coote.org] 
Sent: Wednesday, March 20, 2002 6:50 AM
To: www-ws-arch@w3.org
Subject: architecture question


I appreciate that this may sound rather naive and I may have missed
something really obvious, but I've missed it and this looks like the correct

I'm used to large scale architectures for business applications. In my
experience, the biggest challenges are not very much to do with the
functional and data requirements of applications, they're bound up in higher
level assumptions around a few dimensions: such as time (eg
continuous/real-time vs discrete), consistency (all views of information
are/are not consistent), accuracy (eg numbers used for accounting that must
reconcile vs MIS information where approximate may be good enough - linked
to, but distinct from precision), currency (this value is the position in
the real world now, my current best guess or something else), error models
(eg ACID vs non-ACID), user populations (numbers, level of trust, skill
level, time available), scale, availability (eg regular downtime).  There
are others...

The biggest challenges tend to come from very old assumptions (~20 years
old) in line of business applications.

I'd expected that these would be the sorts of things that would be
considered by the architecture group, but I can't find them. Are they beyond
the scope of architecture in this context or are they considered elsewhere,
eg as an exercise for the implementation, but not part of the run-time
discovery/description process.

The stuff that I have seen looks like the focus areas for trying to get
ineroperation of newish applications in a reliable, robust environment,
which just feels unrealistic.

Have I missed something?


Received on Wednesday, 20 March 2002 11:54:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:55 UTC