1 / 26

GCA XML Dev XML Lessons learned

GCA XML Dev XML Lessons learned. David Orchard Technical Architect Pacific Development Centre. Introduction. Pacific Development Centre New Lab in Vancouver Canada Solutions/FOAK assets Education, Government, Sports, Telecom, Banking Technical architect on: IBM Student Server

tori
Download Presentation

GCA XML Dev XML Lessons learned

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GCA XML DevXML Lessons learned David Orchard Technical Architect Pacific Development Centre

  2. Introduction • Pacific Development Centre • New Lab in Vancouver Canada • Solutions/FOAK assets • Education, Government, Sports, Telecom, Banking • Technical architect on: • IBM Student Server • University student self-service web Asset • Access to all silo-based functions • registration, tuition, admission, grades, … • Prototype May 98 • Ver 1.0 Asset shipped Oct 98 • Ver 2.0 Live at University of Minnesota • One of first IBM web sites/app using XML

  3. Some modest Requirements • PeopleSoft Student Admin 7.0 • Running on Sun E10000 box • Oracle • has >5000 tables • Access by PS GUI and our app • Integrate with University’s X.500 • Performance: • 100 concurrent threads/requests • hundreds of requests/second. • Peak registration week has 60 registrations/minute • Updates through Win32 based api • registration actually done by 30 second COBOL job! • Reads through ODBC

  4. Solution architecture • Web App front end on IBM 3 node 16 cpu SP2 • IBM WebSphere 2.0 Standard • WebSphere performance pack for load-balancing • 24 Windows NT boxes for PS API • Connect via RMI • Developed using Visual Age, FrontPage • IBM Java 1.6 VM, XML4J Parser

  5. Design Decisions • Decided on XML in Nov 97 • EJB Style persistence • No Containers or transactions • Servlets then JSPs • PS & DB Connector • Roles-based UI

  6. Declarative/XML usages: • 1. Runtime generation of HTML from Java (XML) • 2. Compile-time generation of Java (XML) • 3. Runtime specification of Java Objects and Templates (.SHTML) • Rejected as transfer over HTTP between nodes • RMI used • Note: All 3 forms use Java at run-time, NO run-time XML

  7. Runtime Java->HTML • Via XML+XSL • Java object->XML, +XSL->HTML • Wrote Java code to convert Java to XML using DOM • Thrown out due to XSL tech + performance difficulties • Via HTML Template • IBM internal template programming language (TPL) • Applies XML template to Java Object • Produces any textual output • Java object + XML-based HTML template -> HTML • Note: Java Server Pages (JSP) can do first 2 • JSP not available at the time ( Last year ) • I still like TPL better • Note 2: JSP/XSL different architectures

  8. IBM Template Processing Language <template> The business object description is: $description$ <scope PROPERTY="career"> The career code is: $code$ <table> <repeat PROPERTYARRAY="terms"> <tr> <td>$code$</td> <td>$description$</td> </tr> </repeat> </table> </scope> </template>

  9. EJB-ish object defn. (YAEJBML) • Data Object definition, EJB Template (XML) • TPL based • Generates Home, Key, Interface, Data Object, Business Object • Our EJB-ish beans don’t have containers or descriptors

  10. YAEJBML sample <?xml version="1.0"?> <!DOCTYPE DOlist SYSTEM "../../DTD/DO.dtd"> <DOlist> <DO name="StudentEnrollment" package="com.ibm.studentserver.enroll"> <property name="emplid" key="true"/> <property name="classNumber" key="true"/> <property name="enrollStatus" /> </DO> </DOlist>

  11. XML Views • Used Lazy initialization of relationships • Performance was awful! • Created SQL Views with matching XML Views • Binds SQL Views to YAEJBML elements • New findBy method on Home • follows view specification • Some restrictions: • Result Set Columns must be grouped by Bean • No circular references

  12. Declarative Non-XML usage • Created Web Object Builder (WOB) • Parameters to WOB Servlet • Business Object, Keys, FindBy Method, Template <SERVLET NAME="WebObjectBuilder" CODE="com.ibm.whistler.WebObjectBuilder"> <PARAM NAME="TEMPLATE" VALUE="com.ibm.whistler.studentserver.currentenrollment.CourseInformation_CurrentEnrollmentsViewImpl"> <PARAM NAME="BUSINESS_OBJECT" VALUE="com.ibm.whistler.studentserver.currentenrollment.CurrentEnrollmentsView"> <PARAM NAME="HOME_METHOD" VALUE="findBy"> <PARAM NAME="KEY" VALUE="EMPL_ID"> <PARAM NAME="KEY" VALUE="INSTITUTION"> </SERVLET>

  13. Declarative mechanism for: • BO Home.findByMethod(Keys from POST or session data ) • Lock web session • set web session on BO • execute method specified or commit() • render according to template • get web session data from BO • put into web session • unlock web session

  14. Declarative everywhere: • PeopleSoft or RDB binding to Java class (DO) in XML • Views binding in XML • Template for Java object to HTML in XML • Originally XSL then IBM template tool • HTML/JSP page specifying Java Object and Template to render • VIP: Everything can be declarative • Assumes no behavior in Java Object • But: can add behavior betwixt presentation and DO

  15. +ve Design lessons • Declarative means reuse at design/compile time! • View optimizer would have been much harder if EJB code • Declarative means easily regenerate code • Not as many options for tracing/logging/debugging • Much easier to create hundreds of DOs than VAJ • Complete control over behavior and interface • Declarative means easy to adapt • IMHO, adaptability is a crucial success factor • refactoring classes meant text search and replace • GUI developers didn’t need VAJ • Declarative means easy to author • Data Objects, Object templates, Web templates

  16. -ve Lessons Learned • Myths: • XML will replace Java programming • XML always means presentation independence • Java + DOM are sufficient/”perfect together” • XSL is easy and will become ubiquitous • Model Data correctly for interchange • Observations about XML and Transforms

  17. Myth: Procedures in XML • Tried in 2 places • HTML Template • DO templates • End up creating declarative constructs for: • parameters, data types, expressions, loop constructs, variable scoping, subclassing/extension • Can became convoluted • TPL, XSL suffers from this • Can’t author/debug like Java • Suggestion: Declarative for pattern matching • sed/awk/perl/xsl • Better Java text templating would have solved problem

  18. Myth: Presentation Independence • Soo many RFPs with the XML+XSL to any client • Especially XML to IVR + Palmtop + browser + other business • Works in many cases, usually document focused • Similar styles of documentation - print + web pages • Rebranding of content - stories to branded web sites • Interactive web sites are a different story • Many issues from XML to client: • Navigation, Input Data validation, Output Formatting, Amount/ordering of content, Scrolling in content • Process becomes multi-step • Dispatcher queries for content, then format • Suggestion: XML best chance at re-use

  19. Myth: Java/XML “perfect together” • Common B2B, B2C Use Case: • Take lots of EJBs and convert to XML • Condition: read-only classes and DTDs • Either: • Write procedural code using DOM to serialize • Use reflection-based Conversion • Usually use DOM • Poor performance in current implementations • Transfer strongly typed XML tree to Java tree • ie public class student -> <student></student>

  20. XML/Java issues • Inheritance • Java has, XML doesn’t • Contain/embed/link to the parent? • Implements, extends? • References • Java has handles, XML has Linkss • Typing • Java primitives to strings and back • Built-in types + Java classes • Array/Vector/List/Hashtable become ?? • String value become attribute or entity • XML Pis and Comments

  21. Java/XML ideas • Serialization Proposal: • XML binding for Java<-->XML aka YAEJBML • NOT the focus of the Sun Java/XML data binding JSR • Compile XSLT to Java for performance • Perl/SAX pattern/entity matching in Java • Interface between XSLT and Java • call XSLT from JSP • call Java from XSLT • BUT: still problems of type conversion • Java based template string and streams • MessageFormat is awful, poor child of sprintf • generalization of JSP • Perl, others have • IMHO, only “perfect” because java xml parsers

  22. Myth: XSLT solves presentation • XSLT is declarative programming language • XSL has all the constructs of a programming language • Procedures, parameters, variables, VM (DOM) • Difficult to author and debug • ie, creating a Form with CSS, JavaScript, nested tables • Course list table with radio buttons select course and required subcomponents • XSLT needs usability performance/scalability improvements • Serialize Java tree into DOM tree currently • Solution: Know when to use XSL vs JSP

  23. Myth: Model Data “Correctly” • Same “Universal Model” myth heard with rdb and Java • Same modeling problems exist in XML • Example: When is a person a student? • Finance dept: When fees charged • Registrar:Accepted to University • Department: Enrolled in any course • Instructor: Enrolled in course with grade • Student society: Paid student fee • Do you create a student entity? • Solution: Don’t be deluded into “correct” model thinking

  24. Observations • XML everywhere means transforms are key • Need to chain multiple transforms together • Different sources/sinks of transform data • Transforms are behavior • Death of O-O? • Where does Java fit? • Watch for much confusion in market on • JSP+ EJB on DB versus XSLT+XML on DB

  25. XML Schema Announcement • Preview of new XML4J functionality • binary only, 90 day license, to be updated frequently • feedback to XML4J@us.ibm.com • Supports subset of 6 May 1999 Schema Working Draft • subset corresponds to DTD functionality - no datatypes • track the whole Schema spec • read and validate documents using either DTDs or schemas • convert DTDs to schemas and schemas to DTDs • access to DTD and Schema via a DOM extension

  26. Summary • XML widely usable for defining Data • Debatable use for defining behavior/procedures • Combined with code generation • Adaptable software • Easy to author • End2End functionality without Java • Can be part oflarge performance & scalability systems • Student Server • Proven Universal Data Language • Needs work, watch out for hype • tooling, maturity, Java integration Pretty Good for a toddler!

More Related