Inter-BSP transaction batch submission
|Posted: Fri, May 19, 2000 at 19:57:58 (EDT)|
|Subject: Re: Security for ASPs|
|Posted by: Todd Boyle|
|Email Address: email@example.com|
Message: BSPs should submit transactions to each other and to the
as unposted tranasaction batches rather than slamming them straight into the
destination system in ways the user cannot verify.
Realtime interfacing is definitely happening
in 2Q2000, for particular functions. For example webstores are
interfacing inventory realtime, allover the internet and EBPP billing
and other payments services are getting integrated, sporadically with
subscribers' accounting systems. I seem to recall there are over a
million people doing bill payment on Quicken/Intuit website alone.
I think the broader market of BSPs should plan on realtime interfaces in the next 12-24 months, and that they will be based on middleware (MQ Series, Extricity, Netfish, webmethods, there are fifty of these server platforms)
BSPS should go forward at full speed, with XML based transaction batches anticipating those interfaces. smbXML is a great place to start. You can build most of your platform without any real delivery platform, by storing transaction batches in XML.
The principle of reviewing and approving batches manually can be applied by users to *any kind of batch* that has arrived at their general ledger, without incurring much additional work. Account balance and inventory counts can be allowed to run ahead unapproved for certain purposes, which supports your interface to 3rd parties for realtime commerce without much risk of theft.
Most of my clients are comfortable enough today, with the completely insecure postal mail in which they might receive bills from a perfect stranger, any time. They just throw away such bills. All SMEs are like this. They know their own business!
What they need is the tools to review detailed reports to their hearts' content on the originating BSP, including aggregates or totals, in a way that facilitates their approving them or posting them later, into the destination system. Here are design suggestions: http://www.gldialtone.com/A2AforBSPs.htm#levels
3rd party e-services are emerging -- transaction archives, internal
control monitoring firms, etc.- and temporary data stores. Just as EAI
vendors provide a 'Hub' that saves each party from maintaining N-squared
interfaces, temporary hosts would enable users to stuff their XML
batches onto the hub, and exit from the originating BSP service. Then
they would login to their general ledger service (or other destination)
and query the 'Hub' for all their batches.
Todd Boyle CPA www.gldialtone.com/webledger.htm