- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Wed, 20 Mar 2002 08:53:29 -0800
- 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 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 11:54:26 UTC