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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: Packaging extension: Transform



One of my concerns with the current ebXML standards is that as written it
doesn't meet our real-world need.  While it would be great if everyone used
HTTP or even SMTP, we have customers that use FTP or even Kermit on dial-up
modems.  And we would be happy if everyone would send XML based payload
documents, we have many that send fixed-record length, comma separated
variables (csv), excel spreadsheets or PDF files.  If the packaging is
ebXML, well and good, but if they want to use SOAP 1.2 with WSDL, XML-RPC
or simply push a document as the entire body of an email or http POST, then
we need to cater for it.  But we want only one Message Service Handler
(MSH).

For the most part, our CPPA copes with it and I commend the developers of
these protocols and vocabularies that allow us to work so well.  In almost
all cases, we try to keep the payload opaque.  If the packaging doesn't
provide the 'per message' control variables, then we use the ones found in
the CPA.  If we can't identify the CPA then we imply it on the CPP of the
remote party.   The CPPA helps us establish the business processing and
document exchange rules for these documents, the reliability and the
security.

One of the things we learned doing XSL-FO, was that where we may have one
application process producing or processing a document, we may need to
present it in a number of ways.  Our Request Purchase Order process may be
sent as a fax (graphic), a pdf, attached as an XML document based on our
schema definition or perhaps our customers' to an email, or in some file
format natively compatible with their back-end system.  To this end we have
extended the Packaging element to support Transform elements.  We may use
XSLT for transforming the payloads, or POJOs or simple scripts running
through a script engine, or dedicated programs with piped input & output.
We are also able to do this on both 'public' side of our MSH and our
private Application Service Interface (ASI).

In this way we are able to make the MSH implement ebXML features without
necessarily using ebXML packaging (as it stands).

Of course, such transforms, being out-of-scope of the standard, prevents us
from automated publishing and negotiation.  So what is needed to have this
considered for incorporation in the standard?

Jim Wowchuk               jim.wowchuk@marketboomer.com
Chief Technology Officer  marketboomer Pty Ltd
 _--_|\                   Post:  36-42 Waterloo Road
/      \                         Macquarie Park, NSW 2113
\_.--._/ <---Sydney NSW   Phone: +61 (2) 8870 3370 #3357 Mobile: 0419 262
706
       v      Australia   Fax:   +61 (2) 8870 3399




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