[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]