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

Re: architecture question

From: Tim Coote <tim@coote.org>
Date: Wed, 20 Mar 2002 18:42:28 -0000
Message-ID: <00e501c1d03e$fc7b3fd0$801fa8c0@homebox>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
Cc: <www-ws-arch@w3.org>
Thanks Roger.
I don't know that you aren't doing everything, but I couldn't find what I
was looking for. I think that some of it *is* in the OASIS stuff. I'll check
it out some more. But, I must say, this is an horrendously complex set of
standards and some of the models look a long way beyond your average
programmer, which, given that the world is already short of IT staff, could
make it difficult to meet expectations.

tc
----- Original Message -----
From: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
To: "'Tim Coote'" <tim@coote.org>
Cc: <www-ws-arch@w3.org>
Sent: Wednesday, March 20, 2002 4:53 PM
Subject: RE: architecture question


> 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
>
http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/att-0043/01-ws-desc-
> 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
> relevant.
>
> -----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
>
>
> Hullo
>
> 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
> forum.
>
> 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?
>
> tia
>
> Tim
>
>
>
Received on Wednesday, 20 March 2002 13:42:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT