Might as well post this up here too.

The most important strategic question for any ASP or BSP* in designing 
its XML interfaces to the rest of the world is whether to adopt a very 
coarse dialog based on exchange of documents like Purchase Orders and 
Journal Entries, or, to expose its own custom set of properies and 
methods which remote applications may view and invoke 
programmatically.

Examples of "coarse" -- OAGIS, cXML, xCBL, Rosetta, BASDA EBIS smbXML,
and other document based schema.  These prescribed documents are almost 
always defined as components within "conversations", "choreographies", 
"PIPs", "Integration Scenarios" etc. providing a coarse call and 
response capability.

Examples of "fine" -- SOAP and XML-RPC. 

Examples of "dead in the water" -- Java RMI, MS DCom, Corba rpc.

** I WOULD GREATLY APPRECIATE YOUR DIRECT COMMENTS on this question, 
or links to further research!  COARSE OR FINE, guys.  What is the
answer.  What are the reasons?

There are hundreds of business applications running on the web. I been 
listing some of them http://www.gldialtone.com/links.htm and there are 
search engines listing *thousands* of these BSPs and ASPs on 
AspNews.com, webharbor.com, and so forth. 

When you conduct business over the internet using these DotComs, they 
are actually what we used to call modules in our business software.  
Obviously they're going to be a LOT more useful, since they can talk to 
each other. You will send and receive invoices, orders, and payments
over the internet instead of printing and mailing.

Question: what XML standard should these hundreds of dotcoms adopt, 
considering their own self interest, to establish interoperability 
between and among themselves?  Name any two DotComs, and there are 
integration scenarios:

- a web storefront maintains inventory.  it transmits receivables to 
the SME's general ledger. The SME transmits inventory adjustments up 
to the webstore, whenever it purchases, or sells locally.

- a web payroll processor receives timesheets, overtime and other 
instructions from the SME, in XML.  It transmits payments to the SME's 
bank, detailed journal entries to the SME's general ledger, and 
maintains complex reports on the data, accessible by XML queries.

- a web expense report engine manages the travel expense of hundreds 
of employes inputted thru web forms, and transmits accounts payable 
postings to the SME, generates payment requests in XML for the SME's 
bank, and maintains complex reports on the data, accessible by XML 
queries.

Here is a web interface showing what this might look like, on the 
SME's computer http://www.rosehill.net/webledger.htm

Stream of questions:

Is it even possible, today, for BSPs to pursue interoperability?  
There is no transport or protocol standard.  ebXML will define a spec 
based on HTTP/MIME to provide authentication, logging, nonrepudiation, 
digital signatures, guaranteed delivery, etc. but the earliest 
prototype is not due until June.  It will be largely based on the 
transport mechanism of Rosetta.  

You can implement Rosetta HTTP/Mime transport today, turnkey.

Or you can buy MQSeries or other middleware.  Obviously the internet 
BSPs are not going to standardize around any commercial product.  
MQSeries is around $800 for the NT platform (probably slower than 
bejesus, having so many functions and being on NT itself)

Or you can wait for BizTalk server which support massive numbers of 
incompatible XML schemas and elements, providing tools for mapping and 
inserting objects to translate between all those elements.  This will
enable millions of developers to create cool web-based modules! and
provides an upgrade for all those VB and VC developers.

Or you can read the whole tpaML and implement THAT.  A good project 
for a saturday morning.

Here is a whitepaper on topic:  http://www.GLDialtone.com/A2AforBSPs.htm

Obviously the XML and EAI middleware platforms are taking this whole 
market, one website at a time.  Maybe this XML argument is academic.
There have been a series of articles in various mags.  See Business20
June 13th page 90 for example.  IBM MQ Series, webmethods, bowstreet,
extricity, BEA weblogic, netfish, XML Connect, Saga, Bluestone, Glotech,
excelon, NEON, etc. etc. etc. etc.  Why on earth would any of thse
companies support standard XML vocabularies?  That would be like an
electric company supporting canal projects, to drain the lake
behind their hydroelectric project.

--

BSPs are asking, how important is interoperability anyway.  Maybe it's 
better to have custom links between powerful BSPs making it harder for 
new BSPs to enter the market.  Reasonable people disagree.

Maybe a BSP who is the leader in "Application X" should define its own 
XML interface schema knowing full well that hardly anybody is willing 
to learn it, other than other deep pocket BSPs.  Even so, the question 
remains, should they make it RPC/SOAP?  or document based?

There is a basic question of architecture.   Is RPC/SOAP suitable for 
a business infrastructure over internet requiring extensive logging 
and audit trail, low cost, and KISS?  Tracking RPC dialogs across the 
boundaries between numerous BSPs for security and audit trail seems 
almost nuts doesn't it?  Small businesses might have from 3 to 10 
different BSPs. 

---

My tentative conclusions are as follows:

1.  I believe the coarse and document based level is appropriate due 
to the incredible diversity of business functionality that will exist, 
and the fact that nobody has got time to learn high technology 
interface specifications let alone, read the manuals for every 
different dotcom with thier weird and idiosyncratic XML-RPC interface 
comprised of data objects that have no synonyms anyplace else.

2.  The best model for interoperability leaves detail and complexity 
on its original host.  The subscriber should use the native interface 
on the original host to view or edit business information.  Only a 
minimum necessary set of events and transactions should be transmitted 
to other BSPs, and data should not be duplicated all over the internet.
Thus why do you need RPC?

3.  There is no appropriate standard set of XML business documents or 
vocabulary at this time between BSPs; 

4.  The closest XML vocabulary at this time is SMBXML, followed by OAG.
however, BSP interoperability XML schema will be rather different from 
OAG schema, and must be richer in functionality and data than SMBXML.
Here read this http://www.GLDialtone.com/OAGReview.htm
and http://www.gldialtone.com/smbXMLreview.htm

5.  RPC/SOAP are appropriate for aggregating BSPs into tightly 
integrated partnerships. This scenario forclose the possibility that 
customers would choose best-of-breed business components, rather, it 
will predictably result in a few constellations who cannot talk with 
each other.

When a BSP implements RPC or SOAP for generic things like transmitting 
a journal entry, Purchase Order, etc., this suggests a strategic 
intent to form exclusive partnerships.  This achieves faster rollout, 
but leaves a lot of missing components.  One byproduct of SOAP/RPC is 
some degree of defacto lock-in, although not as extreme as the monolithic 
BSPs who plan to provide turnkey solution for every need (SAP, Intuit, 
MS and some of the new ambitious BSPs...)

6.  The interfaces to BSPs should be expressed in standard vocabularies 
because that is the only way to get participation by the domain experts
in the respective fields.

For example, financial transactions may be transmitted for posting to 
general ledgers by assembling them into coherent, double entry journal 
entries, as directed by accountants.  Interfaces to HR systems would be
established by HR domain specialists.  and so forth.   The design, by 1000
different developers, of unique RPC interfaces is a process having a
systematic weakness of not including experienced domain experts, or 
including other affected parties who are just separated in time or 
space from those BSPs. 

7.  If the stockholders and managers within the business community do 
not educate themselves and become more discriminating customers, the
software industry will proceed along its present course which is illustrated
by the profusion of XML middleware vendors, and loss of momentum in XML
standards processes.   The XML middleware vendors have the potential to
become major rent collectors and troublemakers in the ecommerce architecture.


* Todd F. Boyle CPA    http://www.GLDialtone.com/ 
* tboyle@rosehill.net  Kirkland WA 9803   (425) 827-3107
* XML accounting, WebLedgers, ASPs, GL dialtone, whatever it takes


Terms of reference

The Application Service Provider (ASP) industry provides enterprise-scale
applications under various outsourcing and rental contracts.  The applications
are offered based on the ERP vendors' web-based modules if possible, otherwise
thru Citrix-style remote session. Because clients are very large, the revenue
model is monthly fees within a whole TOS contract. The ASP industry emerged
large out of the inability of Fortune 100 companies to successfully implement
ERP inhouse, and has seen heavy investment by telcos and ASP hosting companies.

Business Services Providers (BSPs) are a segment of the ASP industry, who offer
functionality to subscribers which 

*almost always runs natively on webservers and other basic internet
infrastructure 
*usually optimized for speed and usability at all costs, rather than a mandate
for enterprise integration or data integrity.
*almost always runs over the public internet, on a browser,the functionality is
much more diverse than Enterprise/ERP software,
*the functionality is designed to conduct business over the internet,
*encompasses many narrowly focussed best-of-breed solutions for vertical or
horizontal functions,
*usually funded by transaction fees and/or "portal strategies" i.e. influence
over spending decisions of subscribers, as well as monthly subscription fees