OpenTravel Advisory Forum 2012 XML Object Suite Lab


Published on

OpenTravel specification architect provides a developer's view and summarizes the advantages of implementing web services using the new OpenTravel 2.0 specification.

  • Be the first to comment

OpenTravel Advisory Forum 2012 XML Object Suite Lab

  1. 1. 2012 North American Advisory Forum (Miami  Florida  April 2012) LAB PRESENTATION< build:2.0 name = " OpenTravel Lab" /> To address the changing way XML is consumed in today’s global travel marketplace, a new OpenTravel schema product called the “OpenTravel 2.0 XML Object Suite” is being introduced Summer of 2012. The architectural advantages of this new specification facilitate light-weight and interoperable XML payloads— with multiple extension points that support proprietary business logic. This lab provides a developer’s view of 2.0 that will start with a brief presentation titled “Why 2.0” and end with a demo of implementing a 2.0 web service. 1 © OpenTravel Alliance
  2. 2. 2012 North American Advisory Forum (Miami  Florida  April 2012) Lab FacilitatorsDAVID MORLEY, Technical STEVE LIVEZEY, Enterprise Consultant, Marriott Services Technology, Sabre International (moderator) Holdings DAVE HOLLANDER, STUART WALDRON,Enterprise Architect, Sabre Information Technology Holdings Architect, Amtrak BONNIE LOWELL, Specification Architect, OpenTravel 2 © OpenTravel Alliance
  3. 3. 2012 North American Advisory Forum Miami, Florida < build:2.0 OpenTravel Lab" />name = " <Aliases> Why 2.0? XML Component Overview Terminology Mechanics Design Patterns Implementation Best Practices </Aliases>
  4. 4. Why 2.0? DAVID MORLEYTechnical Consultant, Marriott InternationalChair, OpenTravel Architecture Workgroup 4 © OpenTravel Alliance
  5. 5. Ongoing Challenges for Travel Distribution The dynamic nature of travel distribution poses IT design and development challenges… and this impacts XML standards. 5 © OpenTravel Alliance
  6. 6. OpenTravel’s 2.0 XML Object Suite• Will be available in 2012• Provides comprehensive support for the newest XML technologies• Is freely available to all implementers• Is based on OpenTravel’s travel industry CIEM (common information exchange model) 6 © OpenTravel Alliance
  7. 7. 2.0 Architectural Advantages The architectural advantages of the newOpenTravel 2.0 XML Object Suite allow trading partners to construct light-weight and interoperable XML payloads—with multiple extension points that support proprietary business logic and market innovations. So let’s take a look at why you should implement 2.0… 7 © OpenTravel Alliance
  8. 8. Why Should You Implement 2.0? Built By and For Travel CompaniesThe OpenTravel membercommunity—comprised of companiesin the electronic distributionsupply chain—have worked together tocreate the 2.0 specificationbased on a specific set ofgoals. 8 © OpenTravel Alliance
  9. 9. Why Should You Implement 2.0?Maximized Out-of-the-Box InteroperabilityThe 2.0 architecture is based onOpenTravels CIEM, whichfollows a “define once and reuseeverywhere” design pattern• Minimized optional elements & attributes• Naming & structural pattern consistency • Core travel industry concepts described the same way • Substantial reduction of object model analysis requirements 9 © OpenTravel Alliance
  10. 10. Why Should You Implement 2.0? Light Weight Payloads2.0 supports light-weight servicemodels by:• Allowing implementers to use only the XML component “building blocks” needed for their services• Incorporating element & attribute de-duplication into the schema design process 10 © OpenTravel Alliance
  11. 11. Why Should You Implement 2.0?#4) Built-In Extensibility2.0 supports both your proprietarybusiness requirements/ innovationand industry emerging requirementsthrough extensible structures:• Open Enumerations• Core Components• Business Objects 11 © OpenTravel Alliance
  12. 12. Why Should You Implement 2.0?#5) Reduced Binding IssuesWith a focus on reduced bindingissues, 2.0:• Minimizes namespace intrusions• Eliminates nested include files• Eliminates nested attributes• Replaces NMTOKEN with atomic string (to alleviate .Net issues) 12 © OpenTravel Alliance
  13. 13. Why Should You Implement 2.0?#6) Faster Specification ReleasesThe 2.0 publication schedule is RAD-friendly:• Two “Candidate Releases” that provide enough time for member implementers to test implementation • and submit enhancement requests• One final publication that includes all features of Candidate ReleasesRAD = rapid application development 13 © OpenTravel Alliance
  14. 14. Why Should You Implement 2.0?#7) Easy to Learn and Use2.0 is easy to learn and use• Consistent architectural design patterns• Established implementation best practices • Published & included in “reference implementation services”• 2.0 publication add-ons • Component modeling tools• Multiple learning resources on the OpenTravel Developers Network (ODN) 14 © OpenTravel Alliance
  15. 15. Terminology BONNIE LOWELLSpecification Architect, OpenTravel 15 © OpenTravel Alliance
  16. 16. OpenTravel CIEM (Common Information Exchange Model)• A common representational model of all data and data relationships contained in OpenTravel specifications • Precise atomic to component mapping between all OpenTravel schema products • Ensures precise (and consistent) data exchange between parties• OpenTravel libraries are modeled as packages• Supports 2.0 OpenTravel Model• XML structures are modeled as classes • Structure name, type, relationships and schema mapping• Key OpenTravel specification architectural component • Minimizes data duplication • Adds more meaning to data • Semantics, relationships, mapping between specifications, related artifacts 16 © OpenTravel Alliance
  17. 17. OpenTravel Design Patterns• An OpenTravel community determined set of XML architectural design patterns that support the requirements of modern messaging systems • Incorporated into OpenTravel XML Architecture Model • XML schema constructs • Naming • Enumerations • Repeating Groups • Documentation • Substitutions • Namespaces • Extensions • Incorporated into OpenTravel CIEM 17 © OpenTravel Alliance
  18. 18. OpenTravel Implementer Best Practices• An OpenTravel community determined set ofimplementation guidelines for schemaimplementation and data exchange betweentrading partners • Message Exchange Patterns • Service Architectures (SOAP and REST) • Encryption • Data Policies 18 © OpenTravel Alliance
  19. 19. OpenTravel Model (OTM)• A development environment for producing “model driven” OpenTravel schema and creating OpenTravel 2.0 Publications • The OTM contains structured reusable XML objects • Model objects are maintained in CIEM and library(s) for reuse • OTM Compiler creates WSDL and XML schemas for XML services • OTM model compiler created by SABRE for OpenTravel 19 © OpenTravel Alliance
  20. 20. OpenTravel 2.0 Model OpenTravel 2.0 Development EnvironmentModel Development Tool User OpenTravel Interface OTM Publication Model WSDL Compiler Schema Included Examples Library XSD 20 © OpenTravel Alliance
  21. 21. 2.0 OpenTravel Model Type BuildersConstructs Used to Build 2.0 Components 21 © OpenTravel Alliance
  22. 22. Documentation• Six levels of documentation supported • All documentation strings up to 2048 characters • All but Description up to 10 instances Non-Contextual • Description (required): The basic description of the XML structure. • Developer: Implementer-specific textual information, which may contain tips and warnings. • Deprecated: A notification that the object has been marked for deprecation and the publication version or date for the final object deprecation. • Reference: URL(s) to additional reference information. For example, a link to an OpenTravel best practice, an OpenTravel glossary definition and/or a third-party site and/or standard. • MoreInfo: URL(s) to additional documentation that includes links to publication schedules and instructions for submitting publication comments. Contextual • OtherDoc: Other documentation (not included in any of the other Documentation types) with a context-based indicator. 22 © OpenTravel Alliance
  23. 23. EquivalentA (string-based) complex type that providesa mechanism to relate a 2.0 element orattribute to a proprietary implementer-defined application standard, schema and/or database• Related mechanism identified by @context 23 © OpenTravel Alliance
  24. 24. Facet• Mostly used in Core Components and Business Objects • Separate data into: • ID (business objects only) • Summary • Attribute collection • Element collection • Indicator collection • Detail • Attribute collection • Element collection • Indicator collection • Query: • Custom • Has Documentation 24 © OpenTravel Alliance
  25. 25. Alias• Mechanism for providing alternate names usable for valid element references for an object or facet • Typically used to provide alternate names for Core Components and Business Objects within a travel segment (2.0 Library) for ease of implementation 25 © OpenTravel Alliance
  26. 26. 2.0 Built-InsPredefined 2.0 datatypes and structures definedin one common 2.0 library• Used to declare elements or attributes in other 2.0 structures• OpenTravel namespaced• May be Simples, Enumerations, Value with Attributes and Core Components 26 © OpenTravel Alliance
  27. 27. 2.0 Types2.0 Components Contained in Libraries and Used to Construct Services & Service Operations 27 © OpenTravel Alliance
  28. 28. 2.0 Type Library ComponentsThe 2.0 Library is builtfrom a hierarchy ofXML components….…let’s take a look! 28 © OpenTravel Alliance
  29. 29. 2.0 Simple/ Atomic TypeThe most granular 2.0 XML structures• Has atomic XML base type • xsd:string, xsd:integer, xsd:date, etc. • May also be comprised of lists• May be 2.0 “Named” simple types • Atomic base type with no Facets • Provide easier implementations and schema readability• May be 2.0 “Constrained” simple types • Constrain the content of elements and attributes • Contain one or more facets • Pattern, MinLen, etc. 29 © OpenTravel Alliance
  30. 30. 2.0 EnumerationsThe 2.0 specification supports twodiscrete types of enumerations: • Closed Enumeration • Open Enumeration• Both may be used as base types for Values with Attributes• Code List strategy 30 © OpenTravel Alliance
  31. 31. 2.0 Value with AttributesA complex type with:• One base value • Base type may be a Simple Type, Closed Enumeration or Open Enumeration• One or more Attribute and/ or Boolean Indicator collections• Typically replace 1.0 attributeGroups• Promotes re-use• Has Documentation and Base Value Documentation• Has Example(s) 31 © OpenTravel Alliance
  32. 32. Core ComponentA Complex Type:• Containers for application data that defines common representations of real world objects used by all supported OpenTravel sectors • Address, Phone Number, Payment Card• Typically used as building blocks for Business Objects• Typically not implementer extensible • But may extend another Core Components• Have one or more Facets • Summary Facet • Detail Facet• May have a Simple Form representation• May have Roles• May have Aliases 32 © OpenTravel Alliance
  33. 33. Business ObjectsA Complex Type:• Containers for application data (such as an itinerary or a traveler profile)• Implementer extensible• Have Facets • ID • Summary Facet • Detail Facet • Query• May have Roles• May have Aliases 33 © OpenTravel Alliance
  34. 34. ServicesA collection of 2.0 components thatsupport interoperable machine-to-machine interaction over a network Service Operation Patternsspecified in Web Services • RequestDescription Language (WSDL) • Responseformat • Notification• Implementer extensible • Have Equivalents • Have Service Operations• OTM compiler produces trimmed schema 34 © OpenTravel Alliance
  35. 35. Services Simple Types Business Objects Core Components Open Enumerations Value with Attributes Closed Enumerations X X X Simple X X X Complex X X X X Base XML Atomic Type X Base Simple Type X Base Enumeration X Constraining Facets X X Literal Values X X X Implementer Extensible X X X X X X X Documentation X X X Example(s) Attribute Collection Summary Element Collection X Indicator Collection X Simple Form X ID Facet X X Summary Facet X X Detail Facet35 X Query Facet X Custom Facet X X X X X X Equivalent(s) X X Alias(es) X Role(s)© OpenTravel Alliance
  36. 36. Demo DAVE HOLLANDER Enterprise Architect, Sabre HoldingsCo-Chair, OpenTravel Architecture Workgroup 36 © OpenTravel Alliance
  37. 37. Demonstration Goal Let’s build a new “Journey” service complete with Schema + WSDL in 5 minutes or less 37 © OpenTravel Alliance
  38. 38. Steps Examine Profile Demo  Create Journey Object  Use tree filters  Flight, Profile, Hotel,  Expose children of Profile HotelType  Examine Service Example  Create Service Operations data  Compile Create Journey Library  Examine Results Create Extensions  Model schema  Extend Phone  Service description  Add a “preferedName”  Generated Examples  Define extension point for  Create Java classes Profile_Summary  Add a “cvs” attribute 38 © OpenTravel Alliance
  39. 39. 2.0 Mechanics DAVE HOLLANDER Enterprise Architect, Sabre HoldingsCo-Chair, OpenTravel Architecture Workgroup 39 © OpenTravel Alliance
  40. 40. OTM Primary Design Goals1. Enhance OpenTravel’s CIEM (controlled vocabulary)  Owners of a data type define the names by which it is used  Code bound to a type can be written once and reused everywhere2. Embody OpenTravel XML Schema Design Patterns  Developer-oriented to make it easier to program XML applications3. Embody OpenTravel XML Implementation Best Practices  Industry created and adopted data exchange and message implementation guidelines4. Provide a consistent structure that supports reuse 40 © OpenTravel Alliance
  41. 41. GOAL #1: CIEM Controlled Vocabulary Vocabulary owners control the names by which objects are known Consistent object names  A “Phone” is the same real world object with the same recognizable XML name where- and how-ever it is used Approved names and aliases  Model developer defines and controls object names and aliases  New names, aliases and extensions defined within the model  Element references in the schemas enforces approved names 41 © OpenTravel Alliance
  42. 42. GOAL #1: CIEM Controlled Vocabulary Why?  Without a consistent naming strategy, people who define an object will lose control of the names by which that object is known Benefits  Increases understanding of what the data represents  Promotes collaboration and communication  Accelerates system design, development and integration  Code can be defined once and reused OTM uses XML Schema element references to assure the object name is used whenever the object is used  Without this structure, we lose the benefits of everyone speaking the same “language”  Simplifies namespaces in XML messages (as described later) 42 © OpenTravel Alliance
  43. 43. GOAL #2: Embody OpenTravel Schema Design Patterns The OpenTravel Model (OTM) embodies and enhances OpenTravel’s established practices for schema architecture and design  XML schema constructs  Naming  Enumerations  Repeating Groups  Documentation  Substitutions  Namespaces  Extensions 43 © OpenTravel Alliance
  44. 44. GOAL #3: Embody OpenTravel Implementation Best Practices The OpenTravel Model (OTM) embodies and enhances consistent practices for schema implementation and data exchange between trading partners  Message Exchange Patterns  Service Architectures (SOAP and REST)  Transaction Initiator/ Authentication  Encryption  Data Policies  Code Lists 44 © OpenTravel Alliance
  45. 45. OpenTravel Schema Design Patterns and Implementation Best Practices Embodying best practices in the OpenTravel Model (OTM) and development environment makes it easier to create sophisticated schemas The consistency and design makes it easier to write and reuse code that implement those schemas 2.0 Design Patterns and Implementation Best Practices  Are developed from real-world implementations and application knowledge  the complexity of information needed in the travel industry  the broad range of 1.0 messages  Based on modern object-oriented tools bind code to schemas  Object-oriented information objects  Encourages service oriented development  Supports REST and WSDL/SOAP Service Oriented Architectures  Provide a more direct communication between model designer and application developer 45 © OpenTravel Alliance
  46. 46. Design Pattern: Namespaces Allow developers to track and manage their application while updating and extending services Namespaces distinguish  Messages from reusable types  OpenTravel from Implementer Content One Namespace = One Package  Versions One Namespace = One Java Package  Once defined in a namespace the object remains the same  Allows extensions to be used or ignored  Allows code to be reused 46 © OpenTravel Alliance
  47. 47. Design Pattern: Namespaces & Element References  Using element references to preserve the namespace of complex data elements makes it easier to understand an XML message  OTM pattern is to make all complex objects global  Enables types to be defined consistently and reused  References to complex objects are by element reference  Enforces controlled vocabulary goals  Overcomes limitation of namespace specification (see example)Why are card and its children in different OTM element reference assures parent andnamespaces? Because of type reference. children are in same namespace.<Card effective="0412" type="A"> <Card effective="0412" type="A"> <ons:expire>expire</ons:expire> <expire>expire</expire> <ons:holder>holder</ons:holder> <holder>holder</holder> <ons:Issuer>Issuer</ons:Issuer> <Issuer>Issuer</Issuer> </Card> </Card> 47 © OpenTravel Alliance
  48. 48. Design Pattern: Naming Conventions Naming conventions support modular objects, consistently named across many different services and messages while minimizing XML file sizes  Name your object for the real-world item it represents  Use Camel Case  Avoid compound words because they may  Make XML data larger without improving understanding  Describe multiple objects that will be more reusable if separated Item Case Compound Word Attribute lowerCamelCase Permitted Element UpperCamelCase Permitted Simple Type UpperCamelCase Discouraged Simple Complex Type UpperCamelCase Discouraged Core Complex Type UpperCamelCase Discouraged Business Complex Type UpperCamelCase Discouraged 48 © OpenTravel Alliance
  49. 49. Design Pattern: Optional Elements OTM design patterns provide design alternatives to “optional elements”  Optional elements make it harder to understand what will be in a message and complicate application design While we can never eliminate optional elements, OTM provides key alternatives:  Objects with multiple levels of detail allowing each level to  Mandate more properties  Act as a “contract” about what must be present  Customize levels specifying requirements of specific object usage  Query facets to identify query-able properties  Supporting the query use case without making everything in the object optional when used as a data container 49 © OpenTravel Alliance
  50. 50. Design Pattern: Enumeration To improve the OpenTravel 1.0 practice of using and maintaining “code lists” (separate from the XML schema):  OTM provides open and closed enumeration objects for code lists which get compiled directly into the XML Schemas Using XML schema to describe code lists places them directly into the developers code  Simplifying development when using tools with code completion  Reducing mistakes Problems caused by external lists include  Developers may not have access to the lists  Developers must develop custom list handling code 50 © OpenTravel Alliance
  51. 51. Design Pattern: Roles “Role” based object names and repeating groups simplify development and implementation while assuring consistent naming • For example: a phone can have roles of: home, work, mobile OTM design patterns capture the various “roles” objects can assume  Enforces consistent set of roles  May be an attribute on a list of repeating core objects 51 © OpenTravel Alliance
  52. 52. Design Pattern: Documentation Understanding data objects requires consistent naming  With clear and consistent documentation describing the object, its usage, examples and equivalents OTM design patterns include with each object:  Description, developer documentation, reference links  Examples and equivalents The OTM model  Provides a rich set of documentation elements  Supports development tools are easier to use than XSD Schema documentation  Generates both human and machine readable documentation 52 © OpenTravel Alliance
  53. 53. Design Pattern: Substitutability <Profile_ID Authority="MyCompany">When you use the object <ProfileID>123XyZ987</ProfileID>name, any of these can be </Profile_ID>found in a VALID XML file. <Profile Authority="MyCompany"> <ProfileID>123XyZ987</ProfileID> Profile_ID <Address>3 Brooks Street, Somewhere, CA</Address> ProfileID <Name>Name</Name> Authority <Phone>999-555-1212</Phone> </Profile> Profile_Summary Name <Profile_Detail Authority="MyCompany"> Address <ProfileID>123XyZ987</ProfileID> Phone <Address>3 Brooks Street, Somewhere, CA</Address> Profile_Detail <Name>Name</Name> Contact <Phone>999-555-1212</Phone> Remarks <Remarks>send email with changes</Remarks> <Contact>Rick or Sally</Contact> </Profile_Detail> Profile_Custom_Web Remarks <Profile_Custom_Web Authority="MyCompany"> <ProfileID>123XyZ987</ProfileID> <Address>3 Brooks Street, Somewhere, CA</Address> <Name>Name</Name>Just use the object name <Phone>999-555-1212</Phone>whenever possible to allow <Remarks>send email with changes</Remarks> </Profile_Custom_Web>flexibility via substitution 53 © OpenTravel Alliance
  54. 54. Design Pattern: Substitution Groups – PhoneExSubGrpCore Object PhoneExSummary Core Object Sub-Group has 4 elements PhoneEx  Core Object SubGrp is head of substitution group  Use Summary and Detail to avoid substitution PhoneExDetail Alias Sub-Group has 4 elements Extension Sub-Group has 4 elements Extension PhoneSubGrp Where this is in TeleSubGrp the schema PhoneSummary TeleSummary This can be in the Phone Tele data PhoneDetail TeleDetail And this Core Alias 54 © OpenTravel Alliance
  55. 55. Ex SubGrpDesign Pattern: Substitution Groups – Ex IDBusiness Object Ex Identifier Business Object Sub-Group has 6 or more elements Ex  Additional elements for Query and Custom facets Ex Summary  Business Object SubGrp is head of substitution group  Use Identifier, Summary, Detail to avoid substitution Ex Detail Alias Sub-Group has 6 or more elements ExCustom Extension Sub-Group has 6 or more elements ExQuery Extension Alias SubGrp BO SubGrp BOID Alias ID Where this is in the schema BO Identifier Alias Identifier Alias BO This can be in BO Summary Alias Summary the data BO Detail Alias Detail And this BOCustom Alias Custom BOQuery Alias Query 55 © OpenTravel Alliance
  56. 56. Design Pattern: Versions OTM’s versioning practices guide the model designer on how to change the schemas and standards to accommodate growth and changing requirements  While giving the developer and their tools visibility to the changes The model includes version number and scheme Extension 56 © OpenTravel Alliance
  57. 57. Design Pattern: Imports and Includes Modular model design supports team oriented development and management Import and include allow for modular development  Include –definitions in the same namespace from another file  Import –definitions from a different namespace in another file OTM Model simplifies managing the relationships  Managed automatically  You just use the type, the tools will manage the Imports and includes  Compiler consistently creates schema namespace import and include 57 © OpenTravel Alliance
  58. 58. OpenTravel Implementation Best Practices BONNIE LOWELL Schema Architect, OpenTravel 58 © OpenTravel Alliance
  59. 59. Best Practice: Message Exchange Patterns  Two message exchange patterns  Request/ Response  Pull style starts an explicit request for information or action  Notification  Push style – an unsolicited send of data  ACK (acknowledgement) response optional 59 © OpenTravel Alliance
  60. 60. Best Practice: Service Architecture As a standards body, OpenTravel does not dictate web service architectural implementation style 2.0 provides two service naming and operations  Verb-noun naming pattern  REST  SOAP SOAP: 2.0 Service Operation Verb, Noun, Operation Verb Noun Service Name Operation Names Read DemandTicket AirDemandTicket ReadRQ Read DemandTicket AirDemandTicket ReadRS Read Fare AirFare ReadRQ Read Fare AirFare ReadRS 60 © OpenTravel Alliance
  61. 61. Best Practice: Data Encryption Data encryption mechanism provided  Supports PCI and other privacy initiatives Encryption indicator in payload Repeating built-in included in header of message  Xpath to encrypted element  Encryption method  Encrypted value Encryption warnings in schema documentation  <Developer>Note that is it a best practice to encrypt all account access information using the Encryption element in the message header.</Developer> 61 © OpenTravel Alliance
  62. 62. Best Practice: Authentication Multiple levels of authentication information  For identifying and authenticating transaction initiator  ID  Booking Channel  Travel Agency  Airline  Company  Location  Time Zone  Travel Sector 62 © OpenTravel Alliance
  63. 63. Best Practice: Code Lists Two methods to exchange code list information (OpenTravel and Third-Party)Open Enumerations (provided in schema) Code List Metadata 63 © OpenTravel Alliance