Re: Of Bank Tellers...

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by Christopher Ferris
> 
David,

I don't see this as being a function of ebXML per se.

This seems to me to be a portal model which might
have ebXML exchanges out the back end as a result
of user interactions with the portal via a browser
or some other client device (PDA, WAP device, etc.)

ebXML is about business to business automated exchange
of information in fulfillment of some business process
between peers, not client server interaction (IMHO).
It should be, for the most part, transparent to the
end user, not something that s/he interacts with directly.

Maybe I'm missing your point.

<<<<<<<<<<<<<

Ariba would not agree - they call that B2B (ok - so they
may be wrong too!).  My concern is the element of time
critical responses.

The bottom line that I see is in dynamic systems (where XML
is probably most likely to find initial use) and reservation /
service driven systems - my business system is making
realtime decisions - and querying machine-to-machine - but
I cannot afford to wait while it crawls through some SMTP
based delivery that could come back hours or days later...

Maybe the bank-teller model was not the right analogy here!
Primarily because as part of your very nice and extended
response you got drawn into discussing the back-end
systems in the banking system!

My main focus was on the front-desk only.   In the mail-room 
system the front-desk was the model for the MIME/SMTP based
interchange.  A MIME Delivery package arrives, its put on the 
counter, and then 'Receiving' takes over and processes
it into the 'organization'.

In the bank teller situation - its requests and services, and they
require a response.   You put a 'request' on the front-desk of
the 'teller' and you expect a service and response to occur.

Let's consider a situation where a machine
is about to query a bunch of supplier systems to determine
stock availability, and then query the bank system to ensure
sufficient funds are available to meet that allocation, or to 
avoid penalties from the bank on minimum reserve levels.

I want to have this happen real-time, as the stock
level and funds available are highly time sensitive, and rather
than delivering some 'package' to it, the bank is actually 
supplying the content, in response to my query
function - hence verbs and parameters.

Anyway - it follows that I want to use shttp and XML here, 
not MIME and SMTP delivery.

Also strategically I'm concerned that if ebXML is not 
deliverying this technology then SOAP, eSpeak, BizTalk et al
could subsume this and invalidate what we're attempting to 
do here in the first place?  Therefore we want headers and
ebXML interaction systems that can be used in a vendor 
neutral way - regardless of the middleware delivery system,
to deliver cross-platform interoperable functionality.

Right now having a MIME/SMTP centric solution is OK - but we also
need a second model here to ensure that ebXML is not 
labelled as a limited and restricted - batch, synchronous only - solution.

Can 'service delivery' type of technology be used for B2C? 
Yeah - nothing I can do about that!  Comm's is inherently flexible
and clever people will extend whatever you design (we should be
anticipating that and managing that - not trying to restrict it), or
worse they will look elsewhere for the solution and then 
thereby potentially undermine the value of ebXML
interoperabilty.

Is 'service delivery' targetted solely at B2C - absolutely NOT.

DW.

=======================================================================
= This is ebxml-transport, the general mailing list for the ebXML     =
= Transport project team. The owner of this list is                   =
= owner-ebxml-transport@oasis-open.org                                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-transport                                    =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-transport myname@company.com                 =
=======================================================================