[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: 2.4.1 requirements document
<peterk> I have a question with regard to section 2.4.1 of the document that makes reference to maintaining two apis, one for machines and another for people. This seems to me to be extroardinarily inefficient. It seems to me that there should be only one API to the system. If somebody wants to write a gui to the system, then they are welcome to do it. I think it will be highly impractical to try and develop and maintain two apis. I have made these thoughts known within the architecture group, but am not aware that we came to any kind of conclusion on the topic. </peterk> Peter: The two API's are absolutely necessary. In an ideal world where everyone has $250,000 to invest in a fully automated system and there are no errors, ever, the machnine API may be able to be justified (I am not sure that anyone could convince me). Think of SME's. They need a human window to the repository. A lightweight (read *simple*) human interface, maybe CGI based, will give them the flexability to find the business objects they need without complex infrastructure. The human and Machnie API's are just that - API's. They do not require any extra overhead. It is the application that provide the functionality. There is also the concept of logic processing. If the logic used is in any way flawed, you will not find the obejcts you need. Imagine a case where A->C is not available yet A->B and B->C exist. This allows a mechanism with Logic to now do A->C. IF the logic is flawed, the system will not work. The API's are simplistic, lightweight and necessary. We cannot exclude SME's (or corporate Sweden <g>)from the ebXML infrastructure. Duane Nickull
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC