OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: How is ebXML Implementation going?




Farrukh Najmi wrote:

> Here are the ebXML registry implementations that I am aware of:

> 4. XML Global http://www.xmlglobal.com (I could not find actual link this
> registry. Can someone from XMLG help?)
>>>>>>>>>>>>>>>


The XML Global ebXML implementations are not available to the outside 
web.  We have several smaller tools that perform functional components 
of ebXML.  They would likely mean almost nothing to someone unless they 
read the full gamut of documentation accompnaying the modules. 
Currently,  we have components for:

1. ebXML compliant Registry - moderatly complex to build so it scales. 
early attempts were not scalable.  XML Global had to employ lots of 
tricks we learned during the completion of our XML contextual Search 
Engine.  The ebXML Registry model still has some tough questions to 
answer with respect to enterprise scalability and the business use case 
for operating such registries.

2. Messaging Libraries for Registry endpoint - simple to build

3. Messaging for Registry Client/general TRP communications - simple to 
build.

4. Registry query builder - fairly simple.  This component must generate 
Registry Queries in response to business signals (either from a human 
actor using a GUI or an application wanting registry information).

5. CPP formation - very simple to build.  Someone can do this using HTML 
forms and a CGI script.  XMLG wrote ours in Java.

6. CPA negotiation (not 100% functional due to incomplete 
specifications.  The CPA formation must take in two CPP documents and 
one Business Process SPecification Schema as arguments and produce a CPA 
draft AND a Context Rules document.  The context rules document drives 
the contextual adaption of core components to configure the business 
message metadata at design time. IMHO - the Context Rules document 
written by the Core Component group violates the fundamental laws of 
mark up languages by mixing processing logic in an XML transaction 
message.  The Context Rules message should be a simple declaration of 
what rules were present out of the CPA negotiation process.  We 
simplified this message in our implementation to be as follows:

"<?xml version="1.0"?>
<ContextRules ID="com-xmlglobal-registry:80011:00001">
   <Condition type="BusinessProcess"
              name="procurement"
              value="com-xmlglobal-registry:90002"/>
   <Condition type="GeoPolitical" value="EU"/>
   <Condition type="Language" value="FR"/>
   <Condition type="INDUSTRY"
              classificationScheme="SIC"
              value="5139"
              label="Shoes - wholesale"/>
   <Condition type="Product"
              classificationScheme="UNSPSC"
              value="53.11.16.01.00"
              label="chaussures - hommes"/>
</ContextRules>
"

THis format allows for both logical ANDS and ORS in the similar 
declaration in the Core Components schema.

I am still aghast that the CPP does not contain the necessary 
infromation in XML format to generate this context rules message.  This 
is a shortcoming of the CPPA team and I have confidence that team will 
work hard to fix it as they have several smart people working for them.

7. Core Components engine - this component takes in (a) the context 
rules message and (b) the BPSS and makes calls both the Registry message 
generator and the TRP Client software to generate registry queries for 
each core component referenced via the assembly document.  XMLG discards 
the ebXML assembly rules doc and uses an aggregate core component to 
functionally delcare metadata for a particular business message.  We had 
several issues with the ebXML BPSS too and are still analyzing ways to 
make this piece of work usable.

The core components engine spits out a final instance of a business 
message metadata which now is contextually correct to the process and 
scope (context) in which it is being required.

8. GoXML Transform - we use our existing transformation engine to build 
the instance message from the metadata (form the core components 
engine).  GoXML Transform version 2.0 and above have ebXML built in 
functionality.  Release date is OCt 15 and will also offer support for 
EDIFACT, HL7 and X12 EDI formats as well as SQL.  It is downloadable as 
a eval (current version is 1.2 - no ebXML) at 
http://www.xmlglobal.com/prod/transform.


There are several other issues that plague implementors.  The new work 
in UN CEFACT Technical architecture will address some of these and also 
try to build a document explaining implementation as a series of web 
services.

I am also delivering an in depth 4 hour technical class on implementing 
ebXML in Orlando: 
http://www.xmlconference.org/xmlusa/2001/montutorialsafter.htm

and a one hour talk at XML Scandanavia OCt 5-8.

XML Global will also be launching a public ebXML Registry and offering 
some of the above mentioned technology to select customers in a series 
of ebXML pilot projects.  The pilot projects are aimed at both large and 
small companies, offered at our cost.  The pilot projects contact can be 
given upon request (please take offline).

I hope this sheds some light.

Duane Nickull
CTO , XML Global Technologies
http://www.xmlglobal.com




 
> 5. Stirling Commerce (private implementation at this point)
> 
> I am also aware of a few others in the works.
> 
> --
> Regards,
> Farrukh
> 
> 
> "Munter, Joel D" wrote:
> 
> 
>>farrukh, please list references to the 5 implementations mentioned below.
>>thanks, joel
>>
>>-----Original Message-----
>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
>>Sent: Tuesday, September 25, 2001 5:45 AM
>>To: Hyungjoon Kim
>>Cc: ebxml-dev@lists.ebxml.org
>>Subject: Re: How is ebXML Implementation going?
>>
>>Dear Hyungjoon,
>>
>>
>>>I want to know how it is going about the registry and repository, and
>>>
>>what's the main issue
>>
>>>   in developing ebXML-compatible software up to now.
>>>
>>The OASIS ebXML Registry TC is making rapid progress towards V2.0 of its
>>specifications. We expect to have V2.0 specs approved by the TC and
>>submitted to OASIS board for their approval as an OASIS standard by
>>December 1, 2001.
>>
>>Currently there are 5 implementations with various degrees of
>>conformance to the V1.0 specifications to the best of my knowledge.
>>
>>Based on my experience, the main issue for developing ebXML-compatible
>>software currently are:
>>
>>-The V1.0 specs like most V1.0 specs have some holes
>>-The V2.0 specs are being deveoped and therefor a moving target
>>-Implementations are slowly but surely coming out and sometimes are not
>>feature complete
>>
>>All of the above issues are normal to any new set of specifications and
>>I feel certain that within the next 6 months the above issues
>>will be a distant memory. In the meantime networking and collaborating
>>with each other on this mailing list is the best way to overcome
>>the short term issues.
>>
>>--
>>Regards,
>>Farrukh
>>
>>Hyungjoon Kim wrote:
>>
>>
>>>Hi, All I want to implement prototype integrating workflow and
>>>ebXML. When companies want to use ebXML message processing
>>>system,        Implementing registry and repository in industrial
>>>organization must go first. I want to know how it is going about the
>>>registry and repository, and what's the main issue    in developing
>>>ebXML-compatible software up to now.  sincerely, Hyungjoon Kim
>>>
>>----------------------------------------------------------------
>>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>
>>
>>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC