RE: 2.4.1 requirements document

[Peter Kacandes <Peter.Kacandes@ebay.sun.com>]

Duane,

I believe that you are mixing a number of different issues. Let's be clear on the 
distinction between the api to the system and the application that interacts with 
the api.

Just because there is one api doesn't mean that you need to spend mucho $$ on some 
automated system to access it.

Let's take a particular example. Suppose the api has a call ServiceGetBusiness. 
This call returns all business that provide a particular service. Why should there 
be two versions of this call in the api depending on whether or not it is being 
called by another machine or by a person using some gui into the reg-rep?

In the case of a machine calling it, the automated system might then take the 
returned information and do further processing with it such as search eash business 
to also find out which ones support ofx for processing payment for the service.

In the case of the human, they might use the GUI to browse the list of returned 
businesses and decide to do something further.

The point being that it is the responsibility of the GUI to handle the interaction 
with the system so that a human, whether they are at mondo corp or mom&pop llc can 
do something with it, but the calls to the system (the api) is the same and there 
is only one of them.

If mondo corp wants to spend big bucks on a system which totally automates 
interaction with the api and integration into their back end systems, then they are 
more them welcome to do it.

If mom&pop llc wants to download some aplet that helps them to formulate queries 
and has some built in style sheets to format the output into whatever html, then 
that is there business.

The case of error handling is the same. The logic you refer to is all on the client 
side and is not part of the api. The system will report whatever errors it is going 
to report. The automated system will have the logic to do whatever it needs to do. 
In the case of the gui, it will report the error and its up to the human user to 
decide what to do next and the client application, depending on its sophistication, 
might have varying degrees of logic built into it to assist the user with error 
handling. In the most simplistic gui, the user might just get back a cryptic error 
message (not unlike a 404 page that you see in your prowser). If the user shells 
out for a more sophisticated client, it will have more capability to interpret the 
error and direct the user as to what they might want to do next.

Regardless, this is all independent of the api into the system.

There are all kinds of other reasons for the single api approach, also. Suppose, 
for example, you try to take a whack to doing the human api as part of the system 
itself, then people are stuck with that output even if it doesn't meet there needs 
so you are stifling the creativity of all of those people out there who would like 
to do all kinds of different things with it. Nobody will be happy with it and 
you'll be stuck with endless modifications trying to glom on different things to 
try and satisfy folks.

Much better to provide the data back in a consistent way and they let anybody who 
wants to do anything they want with it.

Perhaps I'm missing something fundamental here; I don't know. But the argument you 
present does not convince me. 

regards

pk

>From: "Duane Nickull" <duane@xmlglobal.com>
>To: "Peter Kacandes" <Peter.Kacandes@EBay.Sun.COM>, 
<ebXML-Requirements@lists.oasis-open.org>, 
<ebxml-architecture@lists.oasis-open.org>
>Subject: RE: 2.4.1 requirements document
>Date: Tue, 7 Mar 2000 13:30:42 -0800
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
>
><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
>

Peter Kacandes

Application Planning, Architecture & Strategy	phone number: 	X36529
WWOPS IT/Supply Chain Management		email:	peter.kacandes@ebay