RE: Naming conventions

["Pim van der Eijk" <lists@sonnenglanz.net>]

Hello Cristiano,

Your approach (having a file interface between MSH and back-end
applications) is very common and makes a lot of sense.  It is also by far
the easiest way for backend systems to integrate with an MSH.  Oracle B2B
also uses file names to store message metadata, very much like what you are
proposing:
http://www.oracle.com/technology/products/integration/b2b/pdf/B2B_TN_010_Tra
nsport_File_FTP_Internal.pdf

However, there is a lot of meta-information in an ebXML message header to
store in a file name. File names have (OS-specific) length limitations, and
ebMS 3.0 has even more and extensible metadata (message properties), which
the back-end application may want to process too. And what to do if there is
more than one payload in a single message? The backend application will want
to know which documents were received (or are to be sent as) a single
message. In those cases, an XML file that references those files/attachments
is an easy way to store this information.  Oracle's attachment support uses
an XML interface, last time I checked. 

In various projects I've used the Axway ebMS product that also has such an
XML interface. We've developed a Python library that uses this XML message
interface (invisibly to the user) and which makes writing simple clients or
servers that interface using ebMS as easy as writing any other script ...  

Pim

P.S. I'm copying this message to ebXML-Dev, as other developers may be
interested .. 

-----Original Message-----
From: Cristiano Novelli [mailto:cristiano.novelli@bologna.enea.it] 
Sent: 07 April 2008 18:36
To: Pim van der Eijk
Subject: Re: Naming conventions

Hello Pim,
you can forward this message to the mailing list, of course!

Your answer is very interesting.
I try to explain you our approach about naming conventions requirement.
In our MSH implementation we are adopting a solution to obtain a clear-cut
separation between MSH and enterprise applications that generate the XML
documents (or other formats).
The generated document to send is saved (or moved) into the "Outbox" 
directory,
MSH takes the document, create the ebXML message and sends it, then MSH
saves a document copy into the "Sentbox" dir.
The received document, instead, is saved into an "Inbox" directory, so other
software applications can take it and handle it.

MSH parses the document file name and obtains:
- the CPPID of receiver to load the related CPA;
- the Business State to find into the CPA the related channel and package
(when many channels are defined)
- other information to understand the conversation and, in case, to rebuild
the history of collaborations (all sent and received messages are stored
through the univocal name) [this feature is work in progress].

I understood your vision when you spoke about a "Business Service Handler" 
component, but (in my opinion) it is a very complex system ebBP/CPA-based
and I (we) prefer a gradual approch for our ebXML implementation.
The information stored into the SOAP envelope is interesting way, I will
think about this solution too.

Thanks for your answer, Pim.

Cristiano



From: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>
To: "'Cristiano Novelli'" <cristiano.novelli@bologna.enea.it>
Sent: Monday, April 07, 2008 2:51 PM
Subject: RE: Naming conventions


[...]
> In MIME (which SOAP-with-attachments and ebMS use), it is possible to 
> encode the original filename of a MIME attachment. This is how email 
> clients know the name of files that you send as attachments in email.  
> In ebMS and SOAP-with-attachments this functionality is never 
> discussed. I know one commercial ebXML product that does support this, 
> and when I attach a file called "VerifyRequest.xml" with it, it 
> includes the name as follows in the MIME envelope:
>
> ------=_Part_1_22221394.1159346316789
> Content-Type: application/xml
> Content-Transfer-Encoding: binary
> Content-Disposition: attachment; filename=VerifyRequest.xml
> Content-Id: <A1159346316789.3602@sonyvaio_cn>
>
> This same product also recognizes this with incoming messages, and 
> optionally uses these names when writing attached business documents 
> to file.  Other products do not include file name information in MIME 
> envelopes, and they generate unique file names.
>
> The meta-information about payloads and about the message as a whole 
> are typically passed to the application separately from the business 
> documents.
> Two products have (a.o.) an XML interface that basically contains some 
> information from the ebMS document header (From, To, Service, Action 
> ..) plus a reference to the business document. So when you submit a 
> document to be sent, you pass this XML meta-document to the ebMS 
> message handler, which reads the metadata from it and the pointer to 
> the document, to be included.
> When the message handler receives an incoming document, it extracts 
> the business document (or documents) from it, writes it to disk (using 
> the original filename or a new auto-generated one) and passes XML 
> structure to a receiving application.
>
> Some products also allow you to pass the metadata as JMS properties 
> (if using a JMS integration) or using a Java or other programming
interface.
>
> Note that although this example and your message refer to XML 
> documents, an ebMS message can also include other documents, e.g. PDF 
> documents or TIFF image files, with different extensions.
>
> I've not yet used any ebMS product that supports BPSS (most support 
> just ebMS, and some CPA).  I don't think the BPSS "state" needs to be 
> directly linked to, or derived from, the business document file or its 
> name. A "Business Service Handler" component that interfaces with the 
> Message Service Handler, knows the state the conversation is in, could 
> use message header properties (Service, Action, CpaId etc.) of 
> incoming or outgoing messages and the state transitions expressed in 
> the ebBP document to determine what state the conversation should move to.
>
> I hope this helps ..
> Can I forward this message to the ebXML Message mailing list of the 
> ebXML-Dev?  Other people may have the same question.
>
> Pim
>
>
> -----Original Message-----
> From: Cristiano Novelli [mailto:cristiano.novelli@bologna.enea.it]
> Sent: 04 April 2008 12:30
> To: Pim Van Der Eijk
> Subject: Naming conventions
>
> Hello Pim,
> I know that you are ebMS TC member too and I have a question for you 
> about ebXML MSH implementation experiences:
> is there a convention to name:
> - the XML documents to send before the encapsulation into the ebXML 
> envelope,
> - the received XML documents past the extraction from the ebXML 
> envelope,
> - the messageId and the conversationId?
> If there isn't a diffused common syntax convention, do you know some 
> examples?
>
> May be we will adopt the following syntax for the document to send:
> [MSH-Prefix]_[recipient-cppid]_[BusinessState]_[ProgressiveNumber]_[Co
> nversa
> tionId].xml
>
> where:
> [MSH-Prefix] = Our convention to individualize our MSH2 messages 
> [recipient-cppid] = Our convention to individualize the CPP ID to 
> retrieve the related CPA to use for this collaboration [BusinessState] 
> = Our convention to individualize the ebBP business state (the 
> business process context) [ProgressiveNumber] = A progressive number, 
> identifier of this message in the MSH context [ConversationId] = 
> Identifier of MSH conversation
>
> for example:
> MSH2_IT-12345678909_2_211_[ConversationId].xml
>
> and I thought that you could be interested to this problem beacause it 
> is connected to the business states of ebBP representation and to the 
> CPP/CPA use too.
>
> Last question: how can I connect in an other way the XML document to 
> the ebBP business state?
>
> What do you think about?
> Regards
>
> ----------------------------------------------------------------------
> ------
> -
> Cristiano Novelli
> ENEA, SIC - UDA - PMI
> Via Martiri di Monte Sole, 4
> 40128 Bologna, Italy
> tel +39 051 6098 859
> fax +39 051 6098 084
> cristiano.novelli@bologna.enea.it
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.8/1362 - Release Date: 
> 06/04/2008 11.12
>
>