[ebxml-iic] RE: impl guidelines,on the "technical" and "deployment" sides

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: [ebxml-msg] speak in Barcelona?

All:

 

As mentioned in the call this morning, I am resending the list of "MS implementation items"

we drafted with Michael Wang, that can help MS implementors in giving feedback/recommendation 

based on their implementation experience.

 

Again, I see this as a way to help interoperability between various implementations,

as this will promote sharing the same interpretation of the spec, not to mention the "untold" features

beyond the scope of the MS spec, that are also critical for interoperability (e.g. Security package being used, etc.).

 

In fact, I would propose to rename it: "MS implementation, interoperability and deployment guidelines"

 

So I encourage anyone whose company has been involved in MS implementation,

to give feedback based on the attached survey template, to the degree there is no IP conflict.

(Please check with your lawyers, as Jeff Turpin (CycloneCommerce) will do).

 

As for the "deployment" side of the guidelines, a cooperation path seems to emerge with EAN.UCC,

where Federico and Bolivar (EAN), will work with Pete Wenzel (CycloneCommerce), on some

"deployment" (or business customization?)  template - whatever name they agree on - that should help

user communities to achieve this layer of interoperability beyonf technical MSH interaction,

but before payload business content (e.g. as specified by OAG or RosettaNet).

EAN would provide a first instance of such template.

Such template would also help in standardizing test cases for this layer.

 

Thanks to all,

 

Jacques Durand

 

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Friday, June 14, 2002 3:11 PM
To: ebxml-iic@lists.oasis-open.org
Cc: 'pereira@ean-int.org'; 'franciosi@ean-int.org'; 'pim.vandereijk@oasis-open.org'
Subject: [ebxml-iic] RE: EAN.UCC TRP guidelines

All:

 

For those who reviewed the EAN.UCC ebXML TRP Guidelines,

can you send me - or to the list - your comments soon?

Or be ready to communicate them at our conf call this Monday?

 

Among other things we would like to hear about:

 

1. Opinion on broadening our current guideline document, to an "implementation and deployment guidelines",

that would cover deployment recommendations and conventions proper to standard groups closer to a user community,

such as EAN.UCC (while clearly limiting their scope to EAN.UCC applications)

 

2. Comments on the EAN Guidelines:

What are the recommendations that are not specific to EAN.UCC and could apply more generally?

Any more specific comment on the handling of:

- CPA

- security

- Party ID and naming

- message payload & manifest

- others

 

Thanks,

 

jacques

Implementation Guideline Survey:
-------------------------------

Any suggestion / recommendation on any of the following points 
is welcome. Even a short paragraph / sample material is fine. 
You do not have to give away your implementation competitive, 
but think in terms of what may facilitate interoperability / standardization 
of implementations for testing and trouble shooting purpose. 

1. MSH General

(a)- MSH Configuration. 
(Any suggestion/recommendation? What format is used? Sample file? 
Expected content / scope of the configuration? What aspects of the CPP
will that also cover? Can it be done through API? …)

(b)- Application interface. 
(Advices on what should be in an MSH interface for the application layer. 
Comments on how to handle received messages? callback vs. “pull”...?)

(c)- Error logging. 
(Advice on what to do with errors messages received / generated ,  
Other errors / warnings that do  not translate in messages: 
logging format ( e.g. Log4j - and examples)? 
How unsupported/uninmplemented features are notified to partners?)

(d)- Web Server connection. 
(Implementing using servlets, thread considerations, servlet-engine 
specifics, etc.)

(e)- Message persistence. 
( required functions? Scalability issues? Database / file / message queue. )

(f)- MSH Version management. 
(How to facilitate the transition to a new MS version? Implement an 
MSH supporting two versions?)

(g)- ID generation 
(message ID, conversation Ids, SOAP extension ID)

(h)- Timing management and computations (timeouts, handling time zones)

(i)- What are the third-party software and utilities used to complement
the MSH functions? (Security? Persistence? ID generation?)

(j)- Others?


2. Any recommendation on the implementation of particular MSH Features:
(e.g. using specific language packages: Java libraries, multi-threading, etc.)

- Message Envelope, XML parsing
- Security
- Reliability (Duplicate search, Timeout mechanism)
- Status Messages
- Ping Service
- Message Ordering (management within a conversation)
- SyncReply (transport connection management)
- Multi-Hop
- Protocol Bindings
- …