1. Encoder versus OTD Gabriel Badescu, Jun Xu Sun Microsystems, Inc

2. 2 How Are They Different?

3. Sun Microsystems, Inc 3 OTD is meant for old fashioned Java centric application integration. It is a wrapper around everything being used in Java Collaboration (such as a message or a connector). In terms of messageable OTD, OTD is the message. And in terms of non-messageable OTD, OTD is the connector, for example. OTD

4. Sun Microsystems, Inc 4 Encoder Encoder is meant for enabling new fashioned SOA technology to understand what legacy enterprise systems speak. Conceptually it has some similarity to messageable OTD, but it is NOT a wrapper of anything. It is a core library (plus some design time tooling support) that concentrates on data conversion and validation (from legacy format to XML and vice versa).

5. Sun Microsystems, Inc 5 Why Encoder Technology? ● Function Cohesive (easy to understand and explain) ● Simple, Lightweight and Well-Defined Infrastructure (easy to learn and work with) ● Open, Flexible yet Consistent Metadata Format (easy to exchange and maintain) ● Service Provider Based Pluggability for Runtime (easy to plug in new encoder runtime support) ● Service Provider Based Pluggability for Design Time (easy to plug in new encoder design time tooling support)

6. Sun Microsystems, Inc 6 Continued ● Streaming Interface Support (ready for future enhancement) ● Use SAXSource and ContentHandler Internally (good performance) ● Interpretative Parsing and Marshaling (no codegen, resource efficient, fast deployment) ● Standards Driven (support full features of certain specification)

7. Sun Microsystems, Inc 7 Continued ● Binding Technology Agnostic (utilize the best of everything) ● Java Story Still Supported (easy to use in Java code) ● Support Customization at Different Levels (good for ESRs)

8. Sun Microsystems, Inc 8 Function Cohesive Encoder runtime only does data conversion. It is very function cohesive. While OTD is wrapper of everything and it's hard to describe what it really is.

9. Sun Microsystems, Inc 9 Simple, Lightweight and Well-Defined Infrastructure OTD framework contains Forest and FOG APIs, Layering, Codegen framework and big amount of glue code, which is a very heavy infrastructure. Using it involves big learning curve. Too much wrapping is also error prone. Encoder framework, on the other hand, is much simpler. It only contains a few major interfaces and classes, plus some runtime support classes. It's very easy to learn and use.

10. Sun Microsystems, Inc 10 OTD metadata is API based and its persistency format is proprietary. There is no easy way for user to find the persisted OTD metadata, to understand it or to exchange it. Encoder metadata, on the other hand, is based on XSD, which is an open standard. Encoder specific meta- information is stored in XSD's annotation and the XML structures in annotations are also defined by XSDs. Open, Flexible yet Consistent Metadata Format

11. Sun Microsystems, Inc 11 Sample Metadata 10 RPIE-CODENR PIC X(2) 10 RPIE-CODENR X(2) Very straight forward, right? Everyone understands this at first glance.

12. Sun Microsystems, Inc 12 Service Provider Based Pluggability for Runtime New encoder provider runtime can be found by the encoder framework once it implements the EncoderProvider interface (the SPI) and expose the implementation class through the service provider mechanism. The contract between encoder framework and encoder provider is very straight forward.

13. Sun Microsystems, Inc 13 Service Provider Based Pluggability for Design Time Encoder Metadata Editor – Encoder GUI extension can be plugged into XSD editor through AppInfoProvider SPI. Encoder Metadata Validator – Encoder specific validation extension can be plugged into XSD validation framework through XAM Validator SPI.

14. Sun Microsystems, Inc 14 Sample: Custom Encoder GUI Extension

15. Sun Microsystems, Inc 15 Sample: Custom Encoder Validation Extension

16. Sun Microsystems, Inc 16 Streaming Interface Support In addition to methods that use String or byte[] as parameter data type, the Encoder interface has a set of decoding methods that use InputStream or Reader as input parameter data type and use Source as output parameter data type. It also has a set of encoding methods that use Source as input parameter data type and use OutputStream or Writer as output parameter data type. This way, at interface level, streaming support is not a problem. Actually HL7 and COBOL Copybook encoders also do streaming processing internally.

17. Sun Microsystems, Inc 17 Use SAXSource and ContentHandler Internally Encoder implementation returns SAXSource as output and favors SAXSource as input. This ensures better performance and lower resource consumption over DOMSource. Of course if other components (SEs, BCs) always turn a SAXSource into a DOMSource, overall processing may not benefit from it too much. But if encoder is directly used in Java code, this might be a big benefit.

18. Sun Microsystems, Inc 18 Interpretative Parsing and Marshaling Encoder providers being implemented so far (Custom, HL7, COBOL Copybook) all use interpretative parsing and marshaling. No code generation is needed. For huge metadata, resource consumption is relatively lower during deployment and the deployment process is faster without codegen. Also, it avoids some tricky class loading issues when being used in JBI environment. Performance-wise there shouldn't be much difference since the descriptors are loaded only once.

19. Sun Microsystems, Inc 19 Standards Driven Encoder implementation usually tries to follow the standards if there are any. For example, HL7 encoder follows the HL7 v2 specification and HL7 v2 XML encoding specification. Besides handling normal data adhere to HL7 v2 rules, it also handles unrecognized data and escape sequences in an HL7 recommended way.

20. Sun Microsystems, Inc 20 Binding Technology Agnostic Encoder only focuses on data conversion. It is up to the user to decide if binding technology should be used after encoder has done its job, or what binding technology should be used. There are so many XML binding technologies out there. We do not want to compete with them. Let them do their job and we do ours. If user likes JAXB, just uses JAXB. If he/she likes XmlBeans, just uses XmlBeans.

21. Sun Microsystems, Inc 21 Java Story Still Supported People may think that encoder technology is developed only for JBI environment. Actually this is not true. Encoders can be used in plain Java as well (E.g., in JavaSE or JavaEE projects). Every encoder provider's runtime is packaged as a NetBeans library module and can be added to the classpath of a JavaSE or JavaEE project and be used in Java code. Please see the screen shot in next slide.

22. Sun Microsystems, Inc 22 Encoder Runtime Packaged as NetBeans Library Modules

23. Sun Microsystems, Inc 23 Support Customization at Different Levels An encoder's behavior can be configured at three levels: [level-1] In the encoder's metadata [level-2] In encoding style string [level-3] Through an EncoderProperties instance when decode or encode method is called. The precedence rule is level3 > level2 > level1.

24. Sun Microsystems, Inc 24 Continued This mechanism is very handy, especially when user wants to tweak an encoder's behavior without touching its metadata. For example, user can pass in or override two properties through encoding style string as below: cocoencoder-1.0?displaycoding=cp037&display1coding=GB18030 On the other hand, an OTD's behavior can only be configured in its metadata (level-1).

25. Sun Microsystems, Inc 25 Prerequisite Users must know XML and XSD well to use encoder technology well because they are first class citizens in JBI based ESB offering!

26. Sun Microsystems, Inc 26 Thanks.