RE: Common Business Objects

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

I am now catching up with emails haven been locked up in a hotel room for three days, and I uncovered this disturbing message. 

 

The message clearly illustrates that there is a complete misunderstanding of what a common business object is about.  Perhaps its about communication of the definition of CBOs, or perhaps it is about mental blockages/ resistance to understand what software developers have embraced for years already.  I don't have an answer to that.

 

It is very unlikely that an object would be "sent" to a trading partner without engaging in a "conversation" within an established communications session (post whatever security clearances) - only a few programming environments allow that capability today.   Typically, a CBO is specialized for an industry/company (whatever), and runtime instances will reside completely within the bounds of the corporate enterprise.  CBO are NOT sent to another, however, their instances may be interacted with.  It is NOT JUST about the data, but the operations or behaviour assigned to them.  For example, a "date" CBO may have a specific data structure to it, but more importantly it will have behaviour.  One example that comes to mind for the date CBO is the "addMonth" operation which I have seen on several versions of CBOs out there.  From an XML messaging point of view, I could send simply <addMonth/> within the ebXML TRP enveloping scheme, and the date object (within WHATEVER context it is placed) would be adjusted by one month.  No "data" is sent at all.  This is NOT a virus.

 

I apologize if the reg-rep document stated what it did, but it has complete relevance to reg-rep, as the interactions with reg-rep instances will be similar to this form.   In our registry information model  we need a party CBO with the behavior assigned (to identify who owns the submitted object, etc.).  If CC cannot deliver this to us, we'll just have to adopt something from SF Project or other CBO initiatives.

 

Scott

 

 

 

 

 -----Original Message-----
From: Lisa M. Shreve [mailto:lms@wwnet.com]
Sent: Monday, September 11, 2000 4:03 PM
To: Nieman, Scott
Cc: 'mblantz@LTVSteel.com'; ebxml-stc@lists.ebxml.org
Subject: Common Business Objects

Scott,

Thank you for distributing the updated r&r document, I'm sure Mary Kay is pleased with your prompt response.

Frankly, I am stunned that it still contains references to common business objects!  We have been discussing this since May, and I thought that this had been resolved.  Apparently not.  Let me start with:
 

It is the opinion of the Core Components Project Team, which consists of 60 members and is the largest project team in ebXML, that CBO's are not what we are producing. Core Components, referred sometimes to Smart Core Components, take on specific meanings, elements and refinements, based on Context [such as industry, geographic region, product type, etc.]  The sensitivity to context makes the Core Components smart.  Core Components do not have behaviors, which is why these are not objects.  In the eyes of the business community, receiving an object would be equivalent to receiving a virus.  Obviously, this would not be desirable!
 

Core Components are specifically designed to meet the PT's cross industry interoperability goals of Electronic Commerce.  These requirements are driving the need for the use of context and extension methodology, combined with the core.  This maximizes our opportunity for reuse, and supports the need for concise and semantically significant content.

With us now in the delivery phase, we cannot afford to continue to argue the PT's overall approach. We did an hour presentation in Brussels, we presented jointly with the BP project team at the San Jose closing plenary, we have answered this question on numerous occasions.  What steps do we need to take to bring closure to this issue?

Thank you,

lms
 
 

Nieman, Scott wrote:

here you go:

http://www.ebxml.org/project_teams/registry/private/P1Comments.html

Scott

-----Original Message-----
From: mblantz@LTVSteel.com [mailto:mblantz@LTVSteel.com]
Sent: Friday, September 08, 2000 1:08 PM
To: ebxml-stc@lists.ebxml.org
Subject: Re: UDDI, ebXML, and ecoFramework

Mike,

Much as I would like you to have the last word, I must ask a question.

You indicated a knowledge of the R&R that is more than I know.  I trust you
have found the documentation somewhere.

Please share.

Mary Kay

Mike Rawlins <rawlins@metronet.com> on 09/08/2000 01:37:39 PM

Please respond to rawlins@metronet.com

To:   ebxml-stc <ebxml-stc@lists.ebxml.org>
cc:    (bcc: Mary K Blantz/CLGO/LTV)
Subject:  Re: UDDI, ebXML, and ecoFramework

Rik,

Since only you and I seem to care much about this ;^), and we've both stated
our
opinions, I don't see much to be gained by continuing this dialogue.
However,
I'm sure you'll agree with me that there's a big difference between the BP
metamodel using parts of the eCo framework, and ebXML adopting it wholesale
with
all of its interfaces, schemas, and implementation details.   Those are
beyond
the scope of the BP work.  They also don't fall within R&R, since R&R is
only
working on means to host any generic artifact, and not working on the
details of
the kinds of TP information needed for discovery.  The details of trading
partner discovery logically fall within the responsibility of the TP team,
but
that team has not yet even reached a consensus that trading partner
discovery is
within its scope.  In fact, the last time it was discussed the consensus was
that discovery was *not* within the team's scope.

So, there you have it.  You going to give me the last word???  Have a good
weekend.

Mike

rik drummond wrote:

> since it specified layer i would say it means uses..... best regards, rik
>
> -----Original Message-----
> From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Friday, September 08, 2000 12:07 PM
> To: ebxml-stc
> Subject: Re: UDDI, ebXML, and ecoFramework
>
> Thanks, Rik, but there are only two specific references to eCO in the BP
> metamodel document v2.
> They say:
>
> 126 -129
>
> 2. Markets and Parties
> This is the part of the model that allows organizations to register
> themselves relative to the markets they perform in and the types of
services
> they offer. This aligns with the first four of the seven layers of the eCO
> framework.
>
> 679 - 680 "an eCO style self-registration on your own site might be
> workable'"
>
> I assume that the first reference is the most significant.  I'm not
familiar
> enough with eCo or the BP work effort to know whether "aligns" means just
> "corresponds to" or "is based on".  In either case, I still think that
> making a generalization about planning to use eCo is still an
overstatement.
>
> rik drummond wrote:
>
> > mike the references are in the bp documents.... and were there before we
> > read them at the tmwg meeting.... rik
> >
> > -----Original Message-----
> > From: Mike Rawlins [mailto:rawlins@metronet.com]
> > Sent: Friday, September 08, 2000 11:02 AM
> > To: ebxml-stc
> > Subject: re: UDDI, ebXML, and ecoFramework
> >
> > All,
> >
> > I appreciate Klaus' prompt action in addressing the issues UDDI raises
> > with his note yesterday.  However, I think that there's a
> > misrepresentation in that our plans for using the eCo Framework were
> > stated in a stronger fashion than they actually are.   To my knowledge,
> > no team has yet developed or approved at the team level even high level,
> > informal requirements for trading partner discovery, much less come out
> > with a firm position that we plan to use a specific approach such as
> > eCo.  It is certainly the opinion of several of us that ebXML will end
> > up specifying eCo, but giving the impression now that ebXML has already
> > made that decision is premature and inaccurate.  Such representations
> > can only have negative consequences, and I request that Klaus and the
> > rest of the Executive Committee be a little more careful in the future
> > with their statements about such technical matters.
> >
> > Regards,
> > --
> > Michael C. Rawlins, Rawlins EC Consulting
> > http://www.metronet.com/~rawlins/
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/