Re: Rawlins Comments on R&R Info Model and Services Spec

[Mike Rawlins <rawlins@metronet.com>]

re:
    Line Range: 399-402, table
    Type: Technical
    Issue or Rationale: No valid case for including support for
    Object_Type_Software_Component in this specification
    Suggested Change: Remove

From the few who have participated in this discussion, I'm the only one lining
up behind *my* viewpoint so I think it's time to bow to consensus, especially
since this is a somewhat minor part of the registry's functionality.

I do want to clarify a point, though, perhaps primarily for Scott's benefit.
It's not that I don't understand your architectural vision (of downloadable
components linked to business process models) or think that it might not be
nifty if it worked.  I see no huge technical obstacles to making it work, and
think it would be very nice if it did.  My concerns are and always have been
related to feasibility.   Those concerns center on whether or not there will be
a sufficiently small number of business process models for application vendors
to cost effectively support them.  My experience in EDI suggests that this will
not be the case without a great deal of normalization of both business practices
as well as how organizations choose to use application software.   I personally
don't see either happening any time soon.  If you have analysis and data to
support a case for a relatively small number of business process models, I would
be quite willing to review them and be convinced otherwise.  However, failing
that I must rely on my own experience.  There are also issues related to
software vendor cost models, release practices, and security (to name just a
few), but these are secondary.

At any rate, if a few folks can implement your vision and benefit from it, I
suppose it's worthwhile to support it.  I'm just not holding my breath for it to
become commonplace.

Cheers,

Mike


"Nieman, Scott" wrote:

> Mike, 3.7.1 of the Requirements document, bullet under "related data",
> includes "executable code".  A software component is executable code.
>
> I apologize for not pointing this out sooner, but your argument is moot at
> this point.  This will likely be the official response to your concern.
>
> As far as my "basis", it is purely based on the "history" of this
> discussion, whether it be in X12, or other bodies, that some people just do
> not like this approach for reasons unclear to me.  No matter HOW information
> is integrated, tools and components are based on executable software code.
> "good" tools are based upon solid models.  "perhaps" some tools vendors
> charging >$100K are threatened by the "plug-in integration architecture" -
> if I were them or a consultant relying on services around these tools - I
> would would be too.
>
> It has been my belief for the 15 years of my EDI experience that integration
> SHOULD NOT be the biggest problem of the technical world, BUT IT IS because
> software companies like to build "islands" and "bridges" to these islands
> only to perpetuate their existance and build more tools.  Well, there are
> certainly BIGGER problems on this planet than integration (it isn't as
> difficult as we make it) --> such as sharing information assets, and
> providing intelligent analytic based solutions such as helping doctors
> PROPERLY diagnosis patients.  I vote to move on and solve these problems!
>
> This is not a personal attack by any means, but a level of frustration on my
> part still having to talk about it versus making it happen.
>
> Scott
>
> -----Original Message-----
> From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Saturday, February 17, 2001 4:50 PM
> To: Nieman, Scott
> Cc: ''ebxml-regrep@lists.ebxml.org' '
> Subject: Re: Rawlins Comments on R&R Info Model and Services Spec
>
> Scott,
>
> Either you entirely misunderstand me, or your statement does not reflect
> what
> you actually intended to say.  In either case, your misrepresentation of my
> understanding is unfortunate at best and patronizing at worst.   I am
> surprised
> that I need to point out to you that there is a significant difference
> between
> understanding your architectural vision, which I feel I do, and thinking
> that it
> is feasible, which I don't.   You also say that I don't understand "the
> business
> need for low cost or FREE software that allows B2B integration."  May I ask
> on
> what basis you make that accusation?  If you would take even a trivial look
> at
> the ebXML Requirements Spec, you would know that statement is patently
> false.
> May we please refrain from such personal characterizations and focus on the
> issues?
>
> I am glad to hear of your commitment to work with Core Components.  Although
> the
> joint meetings this past week were helpful, I understand there are still
> major
> concerns about the registry's level of support for core components.  I hope
> that
> the issues can be ironed out.
>
> Regards,
>
> "Nieman, Scott" wrote:
>
> > Mike, I am sorry that you don't understand the architecture, or the
> business
> > need for low cost or FREE software that allows B2B integration into their
> > business applications.  The inclusion of the software component reference
> is
> > trivial by nature, and I don't feel it is a major concern.  I need to wear
> > the TMWG hat on a regular basis, as it is a basis for the initiation of
> the
> > collaboration between OASIS and UN/CEFACT.  If we missed something in the
> > requirements, we failed to document them -- even though I felt we did in
> > Orlando, but perhaps it was removed and I did not catch it.
> >
> > As far as Core Components are concerned, we will continue to work with
> them
> > to ensure the RIM satisfies their needs.  It is a critical piece of the
> > ebXML work.  In Tokyo, we looked at their models, and modified the RIM to
> > handle context and mapped many of their concepts to the ManagedObject
> > concept (which will change terminology as a result of the Vancouver
> meeting
> > I understand).  CC did not have available information on the core
> components
> > at the time we developed the specification, despite our requests for this
> > nine months ago.  We would be glad to incorporate what is relevent to the
> > RIM.
> >
> > Regards,
> >
> > Scott
> >
> > -----Original Message-----
> > From: Mike Rawlins
> > To: Nieman, Scott
> > Cc: 'ebxml-regrep@lists.ebxml.org'
> > Sent: 2/15/01 5:37 PM
> > Subject: Re: Rawlins Comments on R&R Info Model and Services Spec
> >
> > Scott,
> >
> > Even if I accepted the feasibility of your architectural vision (which
> > I don't), we are still left with three major issues:
> >
> > 1)  Feature creep - Your references to X12X/SITG and UN/CEFACT/TMWG in
> > this
> > discussion are totally irrelevant.  The governing authority is the ebXML
> > Requirements Spec, which has no mention of any such requirements in the
> > section
> > detailing R&R requirements.  The fact that you did talk about them in
> > your
> > business domain document, where I also objected to them,  still does not
> > validate the requirements since that document was never voted on by the
> > full
> > membership.  If I were in QRT, I would recommend rejecting the RIM on
> > this
> > basis.
> >
> > 2)  Appropriate forum - Hosting software components in the registry
> > implies to
> > me that they will be sold - either on a one-by-one basis or by
> > subscription.  I
> > have no problem with some interested group of vendors extending the R&R
> > spec to
> > provide such functionality, but I think it is inappropriate for us in
> > this forum
> > to be doing the design work for what is essentially a for-profit use of
> > the
> > registry.  I will not donate any of my time to such an effort, even for
> > review.
> >
> > 3)  Priorities - Even if our consensus holds against my first two points
> > here,
> > there is still a significant issue in that major required functionality,
> > such as
> > full support for ebXML Core Components, is still not achieved.  If we
> > are to
> > succeed in this enterprise we must fully support the core features of
> > ebXML
> > before we work on nice-to-haves.
> >
> > I will vote against any R&R specifications which do not adequately
> > support our
> > core features, especially if they also contain out of scope
> > functionality.
> >
> > Cheers,
> >
> > "Nieman, Scott" wrote:
> >
> > > >>Line Range: 399-402, table
> > > Type: Technical
> > > Issue or Rationale: No valid case for including support for
> > > Object_Type_Software_Component in this specification
> > > Suggested Change: Remove
> > >
> > > Mike, I will speak wearing two hats to address your comment.  Both
> > X12X/SITG
> > > and UN/CEFACT/TMWG recognized the need for the inclusion of software
> > > components.  A scenario by definition is a path through a use case, or
> > more
> > > specifically as the use case is realized, a path through a state
> > machine.  A
> > > software component that implements this state machine when operated
> > with the
> > > ebXML Messaging Service allows the ability to integrate XML messages
> > > directly into business applications; including custom applications,
> > > commercial off the shelf packages, and legacy apps.  Integration is
> > the key
> > > rational for this statement, and it does not have to be done with an
> > > expensive tool like traditional EDI mapping tools.  It ties back to
> > the
> > > basic business requirements, of creating low cost solutions for the
> > SME.
> > >
> > > I have sent several messages to various listservs on this topic.
> > While one
> > > ebXML Registry stores specifications, another may store company
> > profiles,
> > > and another may store software components that bridge between business
> > > applications and XML interfaces.  Some of this is alluded to in the TA
> > spec
> > > (lines 303-304 and 324-326).  So, as a trading partner discovers
> > another
> > > trading partner (its capabilities, its business processes ->
> > represented as
> > > scenarios) it may also discover that software component is available
> > at the
> > > software component registry (through an association to an external
> > object)
> > > that allows it to interact with the discovered trading partner for the
> > > scenario in their CPP.    In the case of the commerical off the shelf
> > > package, such as QuickBooks, this software component would be provided
> > by
> > > the software vendor (Quicken or its assigns).  Its no different than
> > your
> > > browser downloading a Shockwave plug-in, installing, and wa-la, ready
> > for
> > > prime time (in this case B2B).
> > >
> > > So help me out, why is this NOT a valid case?
> > >
> > > I would like to stress that software component registries do already
> > exist,
> > > and could be adapted to this business case.
> > > http://www.componentregistry.com/
> > >
> > > Regards,
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > > From: Mike Rawlins [mailto:rawlins@metronet.com]
> > > Sent: Sunday, February 11, 2001 2:07 PM
> > > To: ebxml-regrep@lists.ebxml.org
> > > Subject: Rawlins Comments on R&R Info Model and Services Spec
> > >
> > > Please find my comments attached below.
> > >
> > > --
> > > Michael C. Rawlins, Rawlins EC Consulting
> > > http://www.metronet.com/~rawlins/
> >
> > --
> > Michael C. Rawlins, Rawlins EC Consulting
> > http://www.metronet.com/~rawlins/
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org

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