Hi Isuru, have you considered some kind of robust "Fallback-Reader" capable of reading whatever comes in as binary raw data? It might be very handy in error handling like illegal characters in XML payloads, wrong encoding of payloads, malformed payloads and so on.
A typical scenario is like this: a illegal payload ends up in some fault-handler ( e.g. XML parser throws an exception). Fault-Handling should be able to process the illegal payload like encoding it as Base64 compliant text and write it to the log-file and so on. By that Fault-Handling should be able to access the payload as binary data stream through "Fallback-Reader". Ideally "Fallback-Reader" provides convenience functionality like base64 encoding, compressing, ... Regards, Jochen -- Jochen Traunecker https://www.linkedin.com/in/jochen-traunecker Isuru Ranawaka <[email protected]> schrieb am Di., 14. Juni 2016 um 19:27 Uhr: > Hi all, > > > We have identified three scenarios when considering content aware support > in Next Gen ESB . These can be categorized as a pure pass thru scenario > where payload is not touched , reading the content without modifying > scenario and reading and modifying the content. So we came up of initial > design and implementation of the content reading part. We have come up > with different message readers for different content types . For > example, for the XML message XMLReader is used and for the JSON Messages > JSONReader is used. Message readers are pluggable via OSGI service. > > [image: reader_implementation.png] > > > Reader Registration > > - > > Gateway core consists of in memory registry which keeps registered > MessageReaders according to content type. > - > > Message readers are registered via OSGI services. > - > > JSON message reader and XML message reader are implemented as two > different OSGI bundles. > - > > CarbonMessage is supported with reading content as InputStream and > write content via OutputStream. > > > Message Flow > > - > > Need to specify the portion of the message that needs to be read via > XPath or JSONPath according to the content type. > - > > When message hits the content aware mediator it checks weather > message is already read if so then it takes MessageDataSource which is data > holder for already read message inputstream according contentType.Else it > gets the matching reader from reader registry and read the input stream and > load the inputstream into MessageDataSource. > - > > XPath and JSONPath are evaluated using MessageDataSource > - > > Serialize data from MessageDataSource to CarbonMessage before sending > to the transport level after mediation. > > > > XML Reading > > - > > Axiom is used for represent XML messages as OMElements > - > > Axiom uses StAX API for read and write XML messages which is > inherently supports deferred building concept. > - > > AxiomXpath is used for evaluate XPath and it used Jaxen as underlying > XPath library. > - > > XPath libraries are pluggable. > > > > JSON Reading > > - > > Jayway library is used for represent JSONPath. > - > > Underlying JSON library is Jackson. > - > > Jackson has JSONParser and JSONGenerator which are similar to > StreamingXMLReader and Writer in StAX API and can read, write events in > streaming manner. > - Jackson supports data binding as well. > > > Thanks > -- > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
