[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Common Business Objects
i still don't completely understand what bp and cc is doing on the cbos and
the ccs -- lack of time. however a thought... anything new is often disputed
at least until the idea is understood. if bp and cc are correct, and i think
a lot of anything paul supports, then we should give them a chance. however,
it is very important that we all understand this as soon as possible. Maybe
Mary could send out the presentation she did for the aiag and that would
help explain things to us.
very best regards, rik
-----Original Message-----
From: Paul R. Levine [mailto:plevine@telcordia.com]
Sent: Tuesday, September 12, 2000 10:33 AM
To: ebxml-stc
Subject: Re: Common Business Objects
It's time to stop disputing whether we are dealing with CBOs or CCs. We
must
recognize that both exist, they are both significant to on- going work, and
they
are in alignment. The alignment has been explained well by Mike Adcock in
his
2000-08-01 paper entitled "Core Component." He said "individual core
compoents
will be general match the 'data list' part of Common Business Objects
(CBOs).
Context will also be defined by the business process model (BPM) which
defines
the instancees in which the Common Business Object (and hence the matching
Core
Component) occurs." The concept of specializing CBOs to be business objects
and
core components to be 'smart core components' according to the context
determined from the BPM is the same. The centrality of CBOs to a UML BPM is
fundamental with many organizations I'm familiar with, i.e., UN/CEFACT, ITU,
ANSI T1, TM Forum, S.W.I.F.T., GCI. This cannot be ignored by ebXML if we
want
our work to be interoperable with other bodies. We have an opportunity to
show
the relationship between CBOs and CCs, and some of us ebXMLers in the
UN/CEFACT
TMWG are proposing to revise the N090 UMM document to show this relationship
up
front. An ebXML Repository that will accommodate UML BPMs must necessarily
accommodate CBOs as well as CCs that relate to the CBOs. One other thought:
don't be afraid of receiving a virus from an object. Business objects
aren't
sent or received, just information about them!
Regards,
Paul
"Lisa M. Shreve" <lms@wwnet.com> on 09/12/2000 09:20:59 AM
Please respond to lms@wwnet.com
To: Mary Kay Blantz <mblantz@LTVSteel.com>, ebxml-stc
<ebxml-stc@lists.ebxml.org>
cc: (bcc: Paul R. Levine/Telcordia)
Subject: Re: Common Business Objects
Rachel,
I think you are missing the point here. The CC PT, which is made up of
the largest concentration of Business experts represented in ebXML,
plus, significant representation from the vendor community [IBM,
CommerceOne, Oracle, Sun, etc.], says that Core Components are not
objects because they do not have behaviors. The project team has
provided on a number of occasions descriptions about the truely
innovative approach CC has taken to solving this difficult problem.
The business community in ebXML is becoming increasingly frustrated with
the ebXML steering committee because they are not being heard. They are
not being listened to.
Industry and vendor lead initiatives, which continue to be started even
today, are defining proprietary XML solutions which undermine the
business communities ability to achieve interoperability.
This is to the detriment of the business community.
And the ebXML leadership continues to argue over Common Business
Objects.
What has to happen in order for this to be resolved?
Cheers,
Lisa M. Shreve & Mary Kay Blantz, CC PT co-Leaders
Rachel Foerster wrote:
> Lisa,I don't agreement with this statement of yours: "In the eyes of
> the business community, receiving an object would be equivalent to
> receiving a virus. Obviously, this would not be desirable!"Component
> architectures AND distributed object computing are clearly and
> unequivocably where IT is going - and it's picking up speed. XML
> provides a clear capability for an entity to contain nonparsed data
> (From XML V1.0: An unparsed entity is a resource whose contents may or
> may not be text, and if text, may not be XML. Each unparsed entity has
> an associated notation, identified by name. Beyond a requirement that
> an XML processor make the identifiers for the entity and notation
> available to the application, XML places no constraints on the
> contents of unparsed entities.) Thus, it is clear that the developers
> of XML intended to provide the capability for non-textual data to be
> conveyed. This would, of course, include objects and by extension,
> common business objects.In my opinion it would be a major omission if
> the ebXML Framework specifications did not include a common set of
> objects. I believe you are mistaken in your assumption that the
> business community assumes that all objects are viruses. For ebXML to
> proceed under this assumption would not be good, and is ultimately in
> conflict with the concept of distributed object computing. I can
> certainly envision the need to be able to use an XML document to
> contain an object that would interact with another object on the
> receiver's side. ebXML simply cannot afford to not enable this
> capability with its framework specification.Hopefully you and the CC
> PT members will recognize the value of this concept and modify your
> thinking to accommodate it.Rachel
>
> -----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.e
> > xml.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/
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC