[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Of Bank Tellers...
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.
I can see a case for portal service providers offering
value-added services which are ultimately fulfilled by
ebXML exchanges. Nick's prototype demonstrated this
concept quite well, I thought.
The user (a traveller) visits her portal service which
has a form-based interface (HTML, WML, CML or whatever)
for updating her profile. The portal server then
creates and distributes the update message to all interested
parties (airlines, hotels, car rental agencies, etc.) which
have either been authorized by the traveller (because she has an
established relationship with them such as frequent traveller
program) or because the portal server has some relationship with
them for sharing info and she has chosen to allow the
information to be shared, etc.
The portal service might offer some of the features you
describe (e.g. "safe deposit box" for storing her profile
information). It might also offer her an ebXML "mail box" service
which enabled her to exchange ebXML messages with her
business partners without requiring that she have an active
connection to the network at all times (ISP model).
Let us say that she has a catering business. She could model
her business process as:
- receive RFQ
- send Quote
- receive PO
- send Ack
- send Invoice
- receive ePayment Ack
She might also have a smart refridgerator/pantry which tracked
her "inventory" and (automatically) sent orders to her suppliers:
- send RFQ
- receive Quote(s)
- send PO
- receive Invoice
- receive Inventory update (from smart pantry)
- send ePayment (to bank)
Or, she might have an application running on her
laptop which was the intended recipient of the POs
and which initiates the second business process (RFQ, etc)
and automatically handled the decision making (pick the
least expensive quote received which matches her QOS
requirements as well).
She would register these business processes with her
portal service provider (or with the ebXML regrep) and
the portal service provider would handle the dirty work.
Her potential business partners/customers might interact
with her portal, or their own, or they might be sending
and receiving the ebXML messages directly. It is completely
orthogonal to the overall model where and how the messages
originated.
Of course, there's the whole synchronous vs asynchronous
angle which is touched on by your proposal. The bank
teller model assumes that the services are always up
and running, that there is always a live connection to
the network (at both ends) and this is further compounded
by multi-party interactions (such as the bank, the credit
authorization service, what have you). Requiring all of these
services to be always running to fulfill the business process
in a synchronous manner is an impediment to keeping the
business process functioning in the face of failures (which
are unfortunately inevitable!)
See below.
Chris
David RR Webber wrote:
>
> Question?
>
> The 'mail room' model I understand and the use of MIME in the
> context of supporting low-tech interfaces.
>
> However, this is not my interchange model (or not the one I'm
> wanting to use), so has any thought been given to the
> 'bank teller' model? If so - what's the schedule, and current
> executive strategy?
>
> Even though I'm calling it 'bank teller' don;t get misled - I'm
> seeing this primarily as a point-of-service for secure
> information interchange - not a money transaction model.
>
> Here's what I define properties of the bank teller model and
> consequently how it differs from the 'mail room'.
>
> 1) Face-to-face service in real time.
The web already has this in spades. It is enabled via any number
of standard or proprietary technologies and protocols.
>
> 2) Provision of service items, not just exchange of 'packages'.
What packages? ebXML message packages or physical packages
such as goods?
>
> 3) Channels - ie. depending on who I am, I get to do/see/go to
> different things.
See above. This is your typical portal such as yahoo, netscape,
aol, excite, etc.
>
> 4) Safe deposit model
see above
>
> 5) Sets of actors - employees, customers, new customers,
> trusted third parties (Brink et al).
see above
>
> 6) Direct connection via internet -
> i.e. http - server/server and client/server query response model.
See above. We have this in spades already. The portal server (or the
web master) throws up a web form, et voila!
You could also do this as XML with stylesheets for presentation, etc.
What am I missing?
>
> Now I realize that electronic money transfers are already
> covered by OTP and SWIFT - supplemental question -
> instead of re-inventing that wheel, do we just endorse OTP for
> e-money???
>
> OK - just to help clarify this further here's the sort of XML
> interchange model I'm after seeing for this bank teller model,
> where you have some Access authnetication and Verb (what do I
> want to do / service to provide?), then some Input criteria, and
> optionally some Output criteria. Both Input and Output may have
> a schema associated with them, and or, a driver process script.
> (simple URL suffices here to point to appropriate item).
>
> Thanks, DW.
> ================== Example XML =====================
> <!ELEMENT TellerXML (Access?, Input, Output)>
> <!ATTLIST TellerXML
> mode CDATA #REQUIRED
> lang CDATA #IMPLIED
> >
> <!ELEMENT Access (Auth?, Channel?, Action+)>
> <!ATTLIST Auth
> userid CDATA #IMPLIED
> passwd CDATA #IMPLIED
> session CDATA #IMPLIED
> >
> <!ATTLIST Channel
> name CDATA #IMPLIED
> code CDATA #IMPLIED
> >
> <!ATTLIST Action
> verb CDATA #REQUIRED
> noun CDATA #REQUIRED
> >
>
> <!ENTITY % in_schema "#PCDATA">
>
> <!ELEMENT Input (Schema?, Content?)>
> <!ELEMENT Content (%in_schema;)>
> <!ELEMENT Output (Schema?, PostProcess?)>
> <!ELEMENT Schema (#PCDATA)>
> <!ELEMENT PostProcess (#PCDATA)>
>
>
>
> =======================================================================
> = 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 =
> =======================================================================
--
_/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
=======================================================================
= 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 =
=======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC