1 1 Gabriel Badescu Jun Xu Encoder Road Map

Sun Confidential: Internal Only 2 Encoders Today

Sun Confidential: Internal Only 3 Encoders > Provide a way to import native meta-data and convert to XSD + annotations > Provide a parser that can receive native data and parse into XML(DOM) and vice-versa > Provide a way to be looked up from a BC or to be used as a Java library through a JAXB code generation Types > HL7 > Custom > COBOL

Sun Confidential: Internal Only 4 Why Encoders Following a trend > Business protocol organizations are increasingly adopting XML (Swift, HL7) > Integration standards bodies' trend (SDO, MOF) > Integration solution providers and ERP vendors are increasingly using XML (SAP,DataDirect EDI-XML Converter, Microsoft XML Accelerator) XML is a key component of SOA, converting non- XML data --> XML is a natural fit For developers, Encoder framework is easier to use and less error prone No codegen for BPEL, XSLT etc. For Java, JAXB generates code faster than OTD and smaller jar file

Sun Confidential: Internal Only 5 Encoders Architecture

Sun Confidential: Internal Only 6 Encoder Architecture – Encoder Lookup Process

Sun Confidential: Internal Only 7 Tooling > Installed as NetBeans plugins > Viewing/Editing piggybacks on XML editor > Import wizards used to convert original formats to annotated XSDs > A generic Encoder tester is used to test all encoders > Pros & Cons: –Viewing/Editing is less intuitive, less user friendly- can be improved however will not compete with pure-play vendors –More generic, leverages generic features already available, such as XSD, XML validation –More structured, separates message structure from encoding annotations – tree structure of native data is represented in XSD

Sun Confidential: Internal Only 8 Tooling (continued) > Recommendations –Use third party native format editors when doing large editing jobs –Provide wizards to convert native formats into XSDs (Encoders) –Viewing and minor editing using XSD editor with specialized encoder plugins –Annotated XSDs will keep the original formats information as much as possible, so when necessary the original formats can be recreated from the XSDs being edited

Sun Confidential: Internal Only 9 Tooling Workflow Create XSD that represents your message structure using XSD Editor Add Encoding specific annotations (Apply Encoding)

Sun Confidential: Internal Only 10 Tooling (screen shots) – Creating meta-data (same as creating an OTD)

Sun Confidential: Internal Only 11 Tooling (screen shots)

Sun Confidential: Internal Only 12 Tooling (screen shots)

Sun Confidential: Internal Only 13 Tooling (screen shots)

Sun Confidential: Internal Only 14 Using an Encoder instance (using an OTD) From BPEL (or any other XML/Xpath based processor) > BC receives native data,Looks up WSDL binding, Call Encoder for this binding, Does Decode,Passes DOM to BPEL > User imports XSD representing Encoder into BPEL From Java > Find XSD for Encoder I'm trying to use > Run JAXB tool to generate Java binding files > Import these files into EJB > Get native data > Pass native data to Encoder – call decode

Sun Confidential: Internal Only 15 Example BC

Sun Confidential: Internal Only 16 Example Java //Get the encoder factory instance EncoderFactory factory = EncoderFactory.newInstance(); //Get the encoder type instance using an encoding style EncoderType type = factory.makeType("customencoder-1.0"); //Specify a top element QName topElem = new QName(" "root"); //Construct the metadata instance MetaRef meta = factory.makeMeta(this.getClass().getClassLoader().getResource("org/helloworld/newXmlSchema.xsd"), topElem); //Create the encoder instance Encoder coder = factory.newEncoder(type, meta);

Sun Confidential: Internal Only 17 Performance Parsing performance (scan only): Encoder better or equals to OTD Mapping performance (data access): Encoder worse than OTD if DOM is used, which is the situation today Recommendations > Replace DOM with –XmlBeans XmlObject –Home grown service data layer (discussed in later slides)

Sun Confidential: Internal Only 18 Migration Monk ETD (.ssc file) to Custom Encoder Converter (completed) Custom Encoder enhancement to cover Monk ETD features (completed but with some exceptions) UD-OTD to Custom Encoder Converter (planned)

Sun Confidential: Internal Only 19 Usability – Encoder Developers Takes 5 steps to develop a new Encoder type(OTD Type) from scratch Dynamic Encoder provider deployment not possible > Need OSGi based JBI implementation Although dynamic deployment not possible, Encoder pluggability better than OTD. Bound to BC as WSDL binding- usability needs to improve Can be used by Java as library- usability needs to improve

Sun Confidential: Internal Only 20 Missing Features > Improve Usability both from BCs and from Java > SDL – Service Data Layer – a standard way to describe the data contract between components in JBI > Encoder Service Engine for decoding/encoding on demand > Attachments > Streaming > Large message handling > Dynamic provider pluggability

Sun Confidential: Internal Only 21 Next Steps

Sun Confidential: Internal Only 22 Next Steps Develop a solid service data layer (SDL) Support attachments Support large message handling via SDL and attachments One pass streaming support will not be considered (see explanation in later slides) Convert Encoder framework and providers to modules when project Fuji is mature to support true pluggability

Sun Confidential: Internal Only 23 Service Data Layer What is it? > Service data later is the API and implementation used by developers to simply and unify the way in which they handle data. Why do we need it? > Currently we are using DOM as the service data layer –Pros: standard, easy to use, loose validation –Cons: performance, footprint, cannot handle large messages, lack of validation (too loose), lack of meta-data introspection > We need something better than DOM

Sun Confidential: Internal Only 24 Service Data Layer (continued) Characteristics of the SDL being proposed: > XML is the internal data format > XML Schema is the meta-model language > Any non-XML data will be converted to XML for processing or stored as an attachment > Small footprint, extreme fast and scalable XML store > Support both strong typed data access (generated code scenario) and generic data access > Support both lazy loading and eager loading (for strong typed access without XML infoset)

Sun Confidential: Internal Only 25 Service Data Layer (continued) > Has a clear set of supported simple types for interoperability > Support dynamic metadata introspection > Support single base type inheritance and dynamic type substitution and enforcement (xsi:type) > Native XPath support, convenient data conversion and copy support > Support partial scan of original non-XMLized data for XPath evaluation (handy for content based routing) > Easy to use by component developers

Sun Confidential: Internal Only 26 Attachments > Attachments can be used to store binary data as is. The binary data can be the entire message or part of it. > Attachments help achieve Decode On Demand. > URIs can be used to reference attachments as illustrated in XOP > Strong attachment support is desired from platform, which can be leveraged in creating fast and small footprint XML store and in handling huge size messages. > The desired features include but not limited to: random access attachment and persisted/partially-loaded attachment.

Sun Confidential: Internal Only 27 Streaming One-pass streaming process is not feasible for Open-ESB. The reasons are: > JBI SA contains processes defined by multiple heterogeneous languages piped together and often involve sophisticated asynchronous interactions. One- pass streaming would mean that whole processing cannot start until the last process in the pipeline is reached, which is ridiculous. > To fully support one-pass streaming, every component must participate, or become a breaker of the streaming process. > One-pass streaming usually cannot support full language features of XSLT, XQuery.

Sun Confidential: Internal Only 28 Streaming (continued) > One-pass streaming involves intensive design time analysis of execution plans, which might be doable for environment with single language, such as SQL in DBMS. In an open community, enforcing every component to do this is hard. We may do some experiments on streaming support but should not expect too much. Focusing on using persisted/partially-loaded attachment to support huge size message is a more feasible way to go.

Sun Confidential: Internal Only 29 Encoders Next Steps Usability! Framework libraries New Encoders

Sun Confidential: Internal Only 30 Thanks