RE: Software abstraction layer to ebXML core component objects

[Cory Casanave <cory-c@enterprise-component.com>]

The ability to have a reusable library of process components and integrate
these components into new collaborations is exactly the capability added by
the in-progress OMG-EDOC component architecture (a UML profile), which is
compatible with the ebXML business process specification. While this
specification is not yet adopted, it is in the final stages.  Here is a link
that will get you to the draft of the component part of the specification:
www.enterprise-component.com/Documents/Part IIIa CCA.pdf

Regards,
Cory Casanave
Data Access Technologies

-----Original Message-----
From: Todd Boyle
To: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
Sent: 5/7/01 8:33 PM
Subject: Software abstraction layer to ebXML core component objects

Suppose you were writing a business application.  Anything that creates 
or processes purchases, sales, settlements, etc.

Suppose you really wanted to avoid reinventing software objects for 
maintaining Party, Location, Product, etc. and in particular, designing 
"yet another" way to store them in databases.

The catalog of core components is pretty abstract.  In any case it only 
has a small and rather random sample of business objects.  So, right
now,
you can't just pick up a common horizontal set of objects from ebXML
CCs.

Couldn't the software developer implement some kind of abstraction 
layer, that could point to *any* core component?  This would let their 
software survive the changes in Core components.  CCmps have GUIDs in 
the registry.  The first time the application sees any GUID, it would 
pull the structure of the object out of the registry, spin up some 
quick/dirty screen for it, and also, create a storage structure.  You 
might end up with dozens of these ad hoc "data aggregate" tables. 
(let's call them Adcock tables :-)  

The multiple layouts for party, product etc. might not be a critical 
problem for some applications.  Only applications which had to perform 
some processes based on values in the elements within those aggregates, 
would have a problem.  Even those functions might be OK, for those  
aggregates containing the same atomic data elements.  You start wanting
to store all this data in a cloud of data elements, with the aggregate
and document levels just being indexes someplace.  Sheesh. why not 
store all these elements in the sky, i.e. a common public file space. 
Oh well. 

Viewed this way, tomorrow's transaction system consists of a sort of key

ring, or a "spike" on which you just stack up the transactions.  Every 
transaction would have a date and amount, plus some kind of party 
aggregate associated with it.  That is a common "header".  Beyond that, 
there is just an abstraction stub for any Core Component, i.e. data 
aggregates for product or service and other attributes.  A *really*
simple
core accounting system.

SMEs are not real hung up on the formats of these aggregates. Right now 
their paperbased systems have diverse layouts.  Most of them don't have 
sufficient volume to need machine intelligence for routing, logistics, 
CRM, etc.  The decision value of information is a key determinant in 
data mining - SMEs don't have big dollars waiting in their Quickbooks 
and AccPac etc. to be "discovered" by data analytics.  They already know

the customers and transactions, intimately.  What they want is a 
fundamental automation of 3rd party balances like bank/AR/AP and 
inventory quantities. duh.

We could be building transaction systems today, 2nd Qtr. 2001, that 
could store almost any SME's transactions in standard core components as

the data structures.  Developers would quickly get a grip on both of the

offsetting movements in any duality need to be captured.  For all 
practical purposes, whenever you transfer anything of value to/from a 
third party, there is an obligation or reciprocal movement in the 
opposite direction.  So the developer would store a key in every atomic 
movement, to associate it with any siblings, and with its reciprocal 
movement(s). (In a GL this key is called the transaction ID)

Further, these transactions seldom stand alone, and in my understanding 
they fall into transaction patterns such as order, fulfilment and 
settlement.  I call this a GroupId.  It is ubiquitous in small and 
midsized integrated accounting software by the way, and not a recent 
discovery here in ebXML.  Even in Quickbooks when you pull up a payment 
you can drill back to the related invoice and order--the separate 
transactions, at different points in time, are tied together.

That is as far as I go, with the business requirements.  I'm waiting for

ebXML to cough up some more core components and willing to lay odds that

the SMEs will just pick them up and start using them natively.  We're 
bearing an ongoing cost, from incompatible layouts for perfectly obvious

things like names and addresses.  From the viewpoint of SMEs, a single 
global address layout is the way to go.  I know some stuff about foreign

addresses and they are NOT that foreign.  You can write any of them on
3 or 4 lines of an envelope.

ebXML is a very civilized group otherwise you wouldn't be working on 
standards in the first place.  But let's admit that the common, 
horizontal aggregates for address, party, etc. are being held up by 
larger corps who need exceedingly precise data formats so they can apply

machine intelligence to locations for routing and logistics, and to 
party information for CRM etc. etc.  SMEs don't benefit from these and 
will quickly converge around a simple horizontal layout.  I guess the 
Global 100 companies imagine all the SMEs keypunching fine-grained data 
into tightly validated geographic-context input cells such as 5 x 4 
zipcodes, etc.  And our Party data in context-sensitive industry formats

that serve their CRM.  Before this is over, the Party record will have 
surveys and questionnaires built into it.  Just watch. 

Thus, the dreams of empire by the programmers in Global 100 companies 
are holding back our horizontal components.  Thus, 30 million SMEs in 
the US keep printing and mailing paper checks.  This is going to blow, 
real soon.  Look at the spasm towards specifically- named XML elements 
and document formats, on http://developer.intuit.com, www.eledger.com, 
www.netledger.com, etc. just in the last two months.

If ebXML hopes to influence these vocabularies, you better publish more 
horizontal components.  

This is not a question whether SMEs are going to adopt context-dependent

core components---they aren't, for now.  And this is not a question 
whether data elements will be created in registries.  That will happen 
anyway, and it's going to happen in other competing registries as well
as XML vocabularies.

The question is which Core Component aggregates SMEs will converge 
around. And perhaps, how sticky their adoption will be.  I think it will

be pretty darn sticky, a few years from now.  So, the question is 
whether the ebXML and EWG have any influence on the shape of those core 
data aggregates, or whether the core data aggregages are designed in 
formats suitable for certain large U.S. shrinkwrap software vendors.

Meanwhile--small developers I suppose, should write an abstraction layer

to interoperate with these diverse, new, ever-changing core component 
objects, to play in this fascinating new game.  And make the code path 
as short as possible because there might be fixed formats, pretty soon.
Hard-code the thing to a single GUID for party, address, etc. if 
the application cannot work on multiple record formats.  But don't 
build without an abstraction layer. 

The SME has never had a software application that could send a bill
or an order, that could be universally understood.  ebXML is tempting
fate, by not contributing core components for this inevitable
development,

Respectfully,
Todd Boyle CPA 
www.gldialtone.com


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org