Hello Martin, thanks for your comments.
I outline below, a position in favor of standard business vocabulary
and document level integration.
<Martin Bryan April 04>
> Todd Boyle asked,
> > COARSE OR FINE, guys. What is the answer. What are the reasons?
>
> Black and white are not useful colours to obtain the whole picture -
> you need something in between to convey detail. Think on the
> following scenarios:
>
> 1) Thin documents, where most of the information is "pre-agreed" and
> only changes are transmitted
> 2) Fat RPC, where you try to activate as many processes as possible
> in a single transmission
> 3) Using SOAP to manage the interchange of thin documents
> 4) Moving intelligence from the server to the client using XSLT and
> related techniques (not Java)
>
> >Question: what XML standard should these hundreds of dotcoms adopt,
> considering their own self interest, to establish interoperability
> between and among themselves?
>
> No XML "standard" (except the "XML standard") will ever meet all the
> needs of all users. First define the needs of the specific business
> process you want to undertake. Then identify how the process can be
> modularized. Then look for the closest existing matching structure to
> your needs. Then be prepared to extend/restrict your use of that to
> meet the needs of the trading partners you need to interoperate with.
>
> >Is it even possible, today, for BSPs to pursue interoperability?
> Individual BSPs can interoperate today using tools/mehtodologies of
> the type you list, but a generalized mechnaism will have to await the
> outcome of the ebXML initiative.
>
</Martin Bryan>
Recapping the original question, how should Business Service Providers
on the internet design their interfaces among themselves to provide
a seamless and integrated software experience for the subscriber who
uses multiple BSPs.
I understand you're recommending that BSPs on the internet look first
at the immediate requirements, process, and modules and then look for
existing matching structures. Do you mean, business XML schema vocabularies?
or the whole universe of structures such as SOAP?
I understand that you believe no standard vocabulary will
ever exist, ergo, each BSP should build custom integrations with each
of their integration partners. Since there will be repositories
and registries like biztalk, or future ebxml servers, to assist us
mapping our synonyms with our partners, or executing objects for
adapters, it is not critical to pursue any common vocabulary and
semantics at this time.
Maybe you're right.
But I reject that conclusion based on 20+ years experience with
hundreds of small and medium scale accounting and business systems.
I promise you, there is a collection of elements which is universal
and which will end up being expressed in a vocabulary to "get the
job done". This is fairly widely recognized in SMEs and participants
in standards bodies. For example, there is a "Standard Purchase Order"
initiative within the OAG right now, and a metadata project.
The broad success of the two BASDA EBIS documents, Purchase Order
and Invoice, are another example http://basda.org/schema/index.htm.
There will be many optional fields but there will be a common core.
Eventually I expect these "universal PO standards" will converge, and
more documents will emerge for the surrounding choreography, and for
other transaction types: payments, bids, offers, etc.
I reject the advice that small BSPs should develop XML interfaces
optimized only for their immediate integration project, and
particularly, the idea that individual developers should define and
discover the level of modularity for business exchanges on an ad-hoc
basis. This will cause the classic N-squared problem and an excessive
logic requirement in mapping these wonderfully diverse module interfaces.
The most practical approach today, by systems developers is to expand
the scope of their interface project beyond the first 1 or 2 partners.
* First, look at every practical standard XML schema or DTD that
could plausably transport the transaction or data you're sending, and
* If standard XML schema exist for part of your conversation or
workflow, then, implement that first to get a foundation set of
vocabulary, and a picture of the level of modularity it defines.
* If no standard XML schema exists, create a mini-standards process.
Pencil in your 5 or 10 other theoretical types of partners. Pick up
the phone and call one or two of each type of partner. Budget 5
minutes for establishing personal chemistry then email the guy a copy
of your draft XML interface schema, give them 48 hours to comment.
For example, if the target BSP is a hosted construction software
provider, and they want to integrate someday with general ledger
backends, or a full-featured payroll service, then they will quite
likely fax you their DTD and start arguing loudly that you should
include fifty different codes for project, phase, and so forth. Out
of this messy confrontation will probably emerge some blueprint for 5
or 10 things that might be necessary in the future, for which some
structure will be reserved in the current interface project. This
does NOT need to take a long time because it is a unilateral planning
process by the developer.
The developer will review the element names chosen by diverse, potential
partners and the definitions of those words to maximize the use
of direct synonyms in application logic. Personally I've also got
a fetish for identical vocabulary. If ten other partners call
something a <Customer>, do us all a favor and don't call yours
a <Client> or <User> in your XML for back end integration. Use
whatever you like on the user interface.
An appropriate level of modularity for the message payload, for
A2A integration between BSPs is the business document level (taking a
clue from BASDA,OAG,CBL,cXML,etc). Developers should be circumspect
about publishing an interface for B2B or A2A based on fragments of
documents like adding a header then adding a line to a PO.
---
(wild and irresponsible comments follow: skip this if you want.)
The present standards bodies are in my view, avoiding the vocabulary
issue out of expediency. Industrial companies and their software
vendors send paid delegates to these meetings. Look at the ebXML
lists. They get real quiet at 5pm when everybody goes home.
Asking them to agree on vocabulary and semantics when they have
billions of dollars at stake is like asking washington lobbyists to
agree on something. It's just not how things work, and you would get
gridlock in the standards bodies. However, this gridlock phenomenon
is only a process problem. It creates an illusion that common
vocabulary doesn't exist in the problem space, when it actually
does. Somehow, lawyers have managed to codify commercial law, and
accountants have codified GAAP definitions.
Developers need to realize that the large software and consulting
company employees who are designing standards, are not primarily
interested in practical A2A interoperability for SMEs. They are solving
problems for the fortune 100, or trying to sell a lot of middleware
servers, or whatever. Since SMEs aren't at the meetings, their
interests are simply not reflected in the process.
Certain software vendors are determined to see generalized XML parsers
and technology installed in every SME computer. These segments
of the XML industry eschew common business vocabulary which will
of course, be parsed 100 times faster by dedicated string parsers,
as soon as a standard vocabulary exists. You will load mod_eBISinvoice
on your Apache webserver, or whatever, it might be a little 20K
executable. If there are 41 required variables in an eBIS Invoice
and 100 optional ones, and you know all the datatypes and rules,
it may be possible to avoid XML Schema and the whole validating
parser, etc. and costly hardware and software platforms.
ebXML will probably provide a standard, manageable transport framework
which will be terrific for SME's based on the HTTP/MIME they're talking
about. But ebXML does not seem disposed to defining payload elements
like "AddressLine1". They're not a vocabulary provider. Anyway, I
seem to detect that the vocabulary providers want ebXML to
"stay out of their turf".
Thanks for listening. Any and all comments are welcome.
* Todd F. Boyle CPA http://www.GLDialtone.com/ [EMAIL PROTECTED]
* [EMAIL PROTECTED] Kirkland WA 98033 (425) 827-3107
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
