RE: Why not object oriented?

[Ed Ouellette <ed.ouellette@tiecommerce.com>]

Mike wrote:
"
I think you need to do a bit more reading and homework.  Most of what you
propose is exactly the direction in which ebXML intended to go, and is the
direction in which UN/CEFACT is continuing the work.  More comments below
"

I agree that most of what I suggest is already being done in the ebXML
standard. I'm more concerned with taking it to the next step and employing
the inheritance and polymorphism. Reusability and extendibility are met by
the current standard, what I'm trying to say is that it's not to the fullest
extent it could be. It seems the current core component system has already
been done.

Page 10 Context and Re-Usability of Core Components v1.04
"
Although UML modeling of business processes is discussed as if it is a
completely new approach, it is not. Earlier development of EDI messages was
done by identifying business processes. Typically the underlying process was
defined in some generic way, describing the specific data elements and codes
to be used, while leaving it to implementations to define the specific use
of the message. The Message Implementation Guides describe a subset of a
generic message, where specific elements qualified by codes express specific
data (semantics). The overall term for this expression of specific data is
what we define as context.
"   

From what I can tell the Core Components are not true objects, simply
definitions based on patterns in the mapping standards. Like a C structure
compared to a C++ object. At first glance they seem to share the same
effectiveness but when actually having to update them and maintain them
objects are a lot easier.

Mike Wrote:
"
You are correct that a lot of the core component analysis is using current
EDIFACT and X12 documents as sources, but it is not in any way trying to
create
an inheritance tree from these predefined documents.
"

I know this I was referring to the challenges related to actually using my
suggested (Object Oriented) approach, not what the current system does. I
think it would be impractical to try and break down the hundreds of
predefined documents into an inheritance tree. What I do think is prudent is
to do an inheritance tree for the Core Components. Which the standard
already identifies, but does not break down into an inheritance tree. 

If the up front work of doing this was done, then adding and maintaining the
core component list would be far easier. 

-Ed


-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Tuesday, August 28, 2001 2:47 PM
To: Ed Ouellette
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: Why not object oriented?


I think you need to do a bit more reading and homework.  Most of what you
propose is exactly the direction in which ebXML intended to go, and is the
direction in which UN/CEFACT is continuing the work.  More comments below.

Ed Ouellette wrote:

> I've been reading up (mostly white papers located on this site) about the
> current state of the ebXML standard. Something struck me as strange, one
of
> the many goals of the standard is reusability / extendibility. We have
> available to us a technical way to meet these goals and many more, as you
> should have guessed from my header I'm referring to object oriented
design.
> >From what I can currently tell (I am a bit new to the ebXML world) one of
> the main challenges to this suggested (OOD) approach would be finding
> patterns already existing in the current business transaction formats (X12
/
> EDIFACT). Creating an inheritance tree from the thousands of predefined
> documents would be a nightmare.

You are correct that a lot of the core component analysis is using current
EDIFACT and X12 documents as sources, but it is not in any way trying to
create
an inheritance tree from these predefined documents.


> A simpler method would be to just have a
> document based objects, built with the core component (objects).

That is exactly the approach that ebXML has proposed.
--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com



----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>