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

[Todd Boyle <tboyle@rosehill.net>]

Mike Rawlins said:
> 1)  Feature creep

Fair enough.  But a technicality.  There are many precedents,
such as SOAP/UDDI.  And providing another (optional) storage in the 
repository is not complex.
 
> 2)  Appropriate forum - Hosting software components in the registry 
> implies to me that they will be sold... commercial use of the registry...

That doesn't necessarily follow.  But even if ebXML regrep operators sell
components, that is not evil, and is anyways outside the control of 
ebXML.  ebXML is anyways, full of obvious commercial plays.

> 3)  Priorities...significant issue in that major required 
> functionality, such as full support for ebXML Core Components, is still 
> not achieved. 

Another oblique point IMO

> 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.

Fair enough.  But I just don't get it.  I don't see any fundamental 
argument in your three points.

Scott Nieman had said:
>> the need for the inclusion of software components....
>> 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....a trading partner may discover that software component is 
>> available at the software component registry... In the case of 
>> commercial 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).

This would be a good thing.  I think software objects in the repository
are a very exciting idea.  Consider the possibilities! But security 
will be a huge problem :-(

Compared with the security challenges for SMEs on Internet, finding
plug-ins seems to me, a small problem.

In conclusion, ebXML should ensure that an unambiguous method exists
for pointing to necessary software components.  That will do the trick. 

Personally I like the Neiman suggestion because I'm fed up with DNS
and the Cisco/Telco internet, with 1024 wellknown ports and 65000 
other ones, with IPv4 itself.  I prefer a dedicated ebXML addressing 
scheme, such as pointers to the repository.  Once  you've gone to 
all the hassles securing your relationship with the repository, 
it seems safer than going out to some FTP site... 

--just 2c worth,
Todd BOyle CPA