United States Patent
`US 7,191,160 B2
`(10) Patent No.:
`(12)
`Hoeft et al.
`(45) Date of Patent:
`Mar. 13, 2007
`
`
`US007191160B2
`
`(54) PLATFORM-INDEPENDENT DATA
`DICTIONARY
`
`(75)
`
`Inventors: Kerstin Hoeft, Walldorf (DE); Michael
`i
`i
`Tsesis, Heidelberg (DE)
`(73) Assignee: SAP AG, Walldorf (DE)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 509 days.
`
`(21) Appl. No.: 10/705,046
`
`(22) Filed:
`(65)
`
`Nov. 10, 2003
`Prior Publication Data
`US 2005/0203938 Al
`Sep. 15, 2005
`Int. CL
`(51)
`GO6F 15/18
`(2006.01)
`(52) US. Che ec ceeeneceeeeee 706/12; 706/45; 706/46;
`707/100
`(58) Field of Classificationscares 103.706145 wis
`s
`lication
`file
`f
`,
`1
`,
`° h hi ‘i a
`ee application
`Ile
`Lor complete search
`Alstory.
`References Cited
`U.S. PATENT DOCUMENTS
`
`(56)
`
`5,991,771 A * LI/1999 Falls et al. oe 707/202
`4/2002 Gawlick et al.
`.. 707/102
`6,377,953 B1*
`
`6,636,845 B2* 10/2003 Chauet al. oe FOWL
`
`
`soeeas oe ooope we 7
`eeor
`..
`:
`3
`°
`eto etal.
`.........
`. 719/316
`7,080,384 B2*
`7/2006 Wallet al.
`
`........ 707/100
`7,117,215 B1* 10/2006 Kanchwallaet al.
`OTHER PUBLICATIONS
`Tim Brayet al., Extensible markup Tanguage (XMT_) 1.0 (Second
`Edition) W3C Recommendation Oct. 6, 2000, http://www.w3.org/
`TR/REC-xml.*
`
`‘Thompson et al., XML Schema Part 1: Structures, W3C
`Henry S.
`Recommendation May 2, 2001, Sections 3.4, 3.14 http://www.w3.
`org/TR/2001/REC-xmlschema-1-20010502/.*
`* cited b
`i
`NOY RENE
`Primary Examiner
`Joseph P Hirl
`(74) Attorney, Agent, or Firm—Blakely, Sokoloff, Taylor &
`Zaiman LLP
`,
`57
`(67)
`A server system may include a data dictionary to store
`platform-independent data types. A development client may
`access and modify a platform-independent data type stored
`in the data dictionary. The server system may notify other
`developmentclients using the data type that the data type has
`been modified.
`
`:
`.
`ABSTRACT
`
`5,418,957 A *
`
`5/1995 Narayan oo... cece TAT/AL3
`
`20 Claims, 9 Drawing Sheets
`
`126
`
`Data
`Dictionary
`
`Booking, Exh. 1048, Page 1
`
`Booking, Exh. 1048, Page 1
`
`

`

`
`
`
`
`U.S. Patent Mar. 13,2007.—-Sheet 1 of 9 US 7,191,160 B2
`
`126
`
`Data
`Dictionary
`
`Booking, Exh. 1048, Page 2
`
`Booking, Exh. 1048, Page 2
`
`

`

`U.S. Patent
`
`Mar.13, 2007
`
`Sheet 2 of 9
`
`US 7,191,160 B2
`
`
`
`(s}ddyeaer
`
`JeN9SAde
`
`bee
`
`ddyAueyoudoid
`
`suoyeoddy
`
`JOAIaS
`
`922
`
`
`
`Aseuooiqeyeg
`
`8cc
`
`dojaaag
`
`JOOL
`
`obS
`
`TWX[2907
`
`sell
`
`Le
`
`
`
`sod]ejeg
`
`O12
`
`002
`
`¢OlA
`
`Booking, Exh. 1048, Page 3
`
`Booking, Exh. 1048, Page 3
`
`

`

`U.S. Patent
`
`Mar.13, 2007
`
`Sheet 3 of 9
`
`US 7,191,160 B2
`
`<00€1JoAyadoid>
`
`
`
`<puyoo¢gaddejyeq>
`
`
`
`<HE}S00€add]eyeq>
`
`
`
`<OzeadA]eVegJoAuadoiy>
`
`
`
`<0zeedA_eyeqJoApadold>
`
`
`
`<ue}SOzeedAleeq>
`
`
`
`<puyozeedALeyeq>
`
`
`
`<add}ul-yIng>
`
`OZ
`
`
`
`00€edA,eyeEQ
`
`
`
`adAjul-ying
`
`
`
`Oleadh,eyeq
`
`tOlas
`
`
`
`<OoLleadd,eyegjoAuedoig>
`
`
`
`<00¢adALB}eq0}Jaj}UIOg>
`
`<puzOreadheyeq>
`
`
`
`<ddA|{ul-yINg>
`
`Ole
`
`
`
`
`
`<OLlEedALB}eqQJoApedold>
`
`<He}SOLEadALB}eQ>
`
`cle
`
`VLE
`
`OLE
`
`BLE
`
`Booking, Exh. 1048, Page 4
`
`Booking, Exh. 1048, Page 4
`
`
`
`
`
`

`

`U.S. Patent
`
`Mar.13, 2007
`
`Sheet 4 of 9
`
`US 7,191,160 B2
`
`uoljejuasaid
`
`21607]sseuisng
`
`
`
`91607]sseooyejeq
`91607]
`
`Orr
`
`OEP
`
`OZP
`
`a\duis
`
`
`
`adA{eed
`
`clLp
`
`xe|dwoy
`
`
`
`add!eyeg
`
`vIV
`
`ArveuonoigBeg
`
`OLP
`
`aseqeleq
`
`adA,ele
`
`OLY
`
`eyedIn
`
`adAy
`
`Slr
`
`yOla
`
`Booking, Exh. 1048, Page 5
`
`Booking, Exh. 1048, Page 5
`
`

`

`U.S. Patent
`
`Mar.13, 2007
`
`Sheet 5 of 9
`
`US 7,191,160 B2
`
`
`eaust]eInjonUSadh]ajduis
`0s9orgo0e9blo
`
`
`
`edd}ul-ying
`
`clo
`
`029
`
`O19
`
`9
`
`Jls
`
`ainjomigyel4
`
`_099
`
`MIA8deiqelad
`
`P99c99
`
`//OS0¢S
`
`
`
`
`
`adh|xejdwoyedA|sejeos
`
`
`
`adh,ejeq
`
`GSls
`
`00S
`
`
`
`309190B80,ANIWAOAdAL(S1)IK8VIVE
`
`
`
`
`
`Booking, Exh. 1048, Page 6
`
`Booking, Exh. 1048, Page 6
`
`
`
`
`

`

`Mar.13, 2007
`
`Sheet 6 of 9
`
`ajdwis
`GpZadk|ajduisGoledA,eyedaseqejeq
`
`
`
`OradAlBeINozadALe1egIN
`
`GeldA]eqG00GLZadh]Byeqa109
`
`
`
`
`adA|uringadh]ul-yINg
`
`adAajdwisadAL
`
`U.S. Patent
`
`US 7,191,160 B2
`
`ZSls
`
`Booking, Exh. 1048, Page 7
`
`Booking, Exh. 1048, Page 7
`
`

`

`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 7 of 9
`
`US 7,191,160 B2
`
`
`
`
`receiving a request for a data type
`
`providing a platform-independent data
`type from a data dictionary, responsive
`to the request for the data type
`
`
`
`
`810
`
`820
`
`FIG. 8
`
`Booking, Exh. 1048, Page 8
`
`Booking, Exh. 1048, Page 8
`
`

`

`
`
`
`
`U.S. Patent Mar. 13,2007—-Sheet 8 of 9 US 7,191,160 B2
`
`receiving a platform-independentdata
`
`storing the platform-independent data
`
`type
`type in a data dictionary
`
`
`receiving, during design time, a request
`
`for the stored data type from a first Java
`
`application
`
`second Java application
`
`providing the requested data typeto the
`first Java application
`
`receiving, during design time, a request
`for the data typefrom a second Java
`application
`
`providing the requested data type to the
`
`receiving notification that the first Java
`
`application has modified the data type
`the data type has been modified
`
`notifyingthesecondJavaapplicationthat
`
`- | G 9
`
`.
`
`910
`
`920
`
`930
`
`940
`
`950
`
`960
`
`970
`
`980
`
`Booking, Exh. 1048, Page 9
`
`Booking, Exh. 1048, Page 9
`
`

`

`U.S. Patent
`
`Mar.13, 2007
`
`Sheet 9 of 9
`
`US 7,191,160 B2
`
`OlOls
`
`OSOL
`
`AseuvonsiqOrOl
`
`eleq(s)eoepe}u|
`
`yIOMION
`
`(s)i0sse90l14
`
`OLOL
`
`Booking, Exh. 1048, Page 10
`
`Booking, Exh. 1048, Page 10
`
`
`
`
`

`

`1
`PLATFORM-INDEPENDENT DATA
`DICTIONARY
`
`TECHNICAL FIELD
`
`[Embodiments of the invention generallyrelate to the field
`of data dictionaries and, more particularly, to a system and
`method for a platform-independent data dictionary.
`
`BACKGROUND
`
`A “data dictionary” is a repository of data types and the
`relationships between the data types. The term “data type”
`refers to information that defines the semantic and. syntactic
`properties of operational data, such as the type, length, and
`relationships of operational data. The data types stored in a
`data dictionary may be used during both design time and
`runtime. The term “design time” refers to the design and
`development of computer software (or simply, software).
`The term “runtime” refers to the actual execution of soft-
`ware.
`
`A conventional data dictionary may be integrated into a
`traditional client/server system. I’or example, a development
`client may be usedto define a data type andstore the defined
`data type in a data dictionary on the server system (or in a
`data source to which the server system has access). The
`defined data type may, for example, specify the structure of
`a database table for the traditional client/server system.
`Software executing on a client system may access the
`defined data type and create a database table based on the
`defined data type.
`Traditional client/server systems are implemented with a
`single stack of technology from the physical layer to the
`application layer. In traditional single stack client/server
`systems a single data source (e.g., a database system)
`provides the data for all clients interacting with the appli-
`cation servers. A model
`in which different parts of the
`technology stack are implemented by different vendors is
`replacing the traditional single stack model. In multi-vendor
`implementations of client/server systems, developers may
`write software in more than one programming language.
`Conventional data dictionaries are not desirable in multi-
`vendor implementations of client/server systems because
`they store data types that are language-dependent and/or
`platform specific. According to one embodiment, a method
`for providing platform-independent data types is disclosed.
`‘The methodincludesreceiving a request for a data type from
`a clicnt system, and providing the data type to the client
`system in response to the request, wherein the data type
`includes a platform-independent data type that is indepen-
`dent ofplatforms associated with the client system.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`40
`
`Embodiments of the invention are illustrated by way of
`example, and not by wayoflimitation, in the figures of the
`accompanying drawings in which like reference numerals
`refer to similar elements.
`
`FIG. 1 is a block diagram of distributed system 100.
`FIG.2 is a simplified block diagram ofdistributed system
`200 implemented to provide a platform-independent data
`dictionary, according to an embodimentofthe invention.
`FIG. 3 is a simplified block diagram illustrating design
`time data type 310 and run Umedala type 320.
`FIG.4 is a conceptual block diagram illustrating distrib-
`uted system 400.
`
`60
`
`65
`
`US 7,191,160 B2
`
`2
`FIG. 5 illustrates exemplary DATA statement 400, suit-
`able for requesting a data type according to an embodiment
`of the invention.
`FIG. 6 illustrates exemplary data types available in an
`embodimentof the invention.
`
`10
`
`FIG. 7 is a simplified block diagram illustrating the
`copying and modifying of object 710.
`FIG. 8 is a flow diagram illustrating certain aspects of a
`method for providing a platform-independent data type,
`according to an embodiment of the invention.
`FIG. 9 is a flow diagramillustrating certain aspects of a
`method for receiving and processing a platform-independent
`data type during design time.
`FIG. 10 is a block diagram of node 1000 implemented
`according, to an embodiment of the invention.
`
`DETAILED DESCRIPTION
`
`[Embodiments of the invention are generally directed to a
`system and method for a platform-independent data dictio-
`nary. The term “platform-independent” data dictionary
`refers to a data dictionary that provides data types that are
`not limited to a particular programming language or par-
`ticular software and/or hardware architecture. As further
`described below, in one embodiment, the data types comply
`with the standard promulgated by the World Wide Web
`Consortium (W3C)entitled, “Extensible Markup Language
`(XML) 1.0 (Second Edition),” 6 Oct. 2000 (hereinafter, the
`XMLStandard).
`FIG. 1 is a block diagram ofdistributed system 100. The
`illustrated embodiment of distributed system 100 includes:
`user layer 110, application layer 120, and data access layer
`130. Someor all of the elements within each layer of
`distributed system 100 may be interconnected via a network
`(e.g., a Local Area Network (LAN) and/or the Internet).
`Alternative embodiments of distributed system 100 may
`include more layers, fewer layers, and/or different layers.
`Userlayer 110 is the interface betweendistributed system
`100 and one or more users. The illustrated embodiment of
`
`user layer 110 includes user terminals 114-119. One or more
`of user terminals 114-119 maycollect user input and sendit
`to application layer 120 over network connection 140.
`Network connection 140 may be a wired or wireless con-
`nection to a Local Area Network (LAN), a Wide Area
`Network (WAN), a Metropolitan Area Network (MAN),
`and/or the Internet. User terminals 114-119 may be personal
`computers, notebook computers, personal digital assistants,
`telephones, and the like. In an embodiment in which net-
`work connection 140 connects to the Internet, one or more
`of user terminals 114-119 may have a Web browser to
`interface with the Internet.
`
`In an embodiment, user layer 110 provides the presenta-
`tion logic and the business logic for conventional distributed
`system 100. The term “presentation logic”refers to software
`that determines how information is provided to a user and
`how the user interacts with an application. The term “appli-
`cation” refers to software that performs work, such as data
`creation or manipulation.“Business logic”refers to software
`that performs data processing.
`application servers
`Application layer 120 includes
`122-124 and data dictionary 126. An application server
`broadly refers to a computing device that performs data
`processing. In a three-tier client/server environment, such as
`distributed system 100, application servers 122-124 may
`provide the business logic for distributed system 100. In an
`embodiment, application layer 120 includes a computing
`device (e.g., called a dispatcher) to perform load balancing
`
`Booking, Exh. 1048, Page 11
`
`Booking, Exh. 1048, Page 11
`
`

`

`US 7,191,160 B2
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`3
`among application servers 122-124. In an embodiment in
`which application layer 120 exchanges information with
`user layer 110 via the Internet, one or more of application
`servers 122-124 may be described as a Web application
`server. Application servers 122-124 may be implemented
`according to any of the Java 2 Enterprise Edition Specifi-
`cations, for example, v1.4, published on Jul. 12, 2002
`
`
`(hereinafter the J2EE Standard). The term J2EE application
`server broadly refers to an application server that imple-
`ments, at least in part, one of the J2EE specifications.
`Data dictionary 126 provides a repository of data types for
`distributed system 100. Data types include information that
`defines the semantic and syntactic properties of operational
`data, such as the type, length, and relationships of opera-
`tional data. Data types defined in data dictionary 126 are,
`generally, available to applications operating on application
`servers 122-124. For example, applications operating on
`application servers 122-124 mayuse data or variables that
`are defined in data dictionary 126. In an embodiment,a first
`application executing on, for example, application server
`123 during design time may obtain a data type from data
`dictionary 126. Similarly, a second application executing on
`application server 123 (or another application server) during
`design time may also obtain the data type from data dictio-
`nary 126. Thefirst application may modify the obtained data
`type to produce a modified data type. In an embodiment, the
`changes made to the data type by the first application are
`propagated to the data type obtained bythe second appli-
`cation. Thus,
`in an embodiment, distributed applications
`work with a current version of the data type. As is further
`described below, in such an embodiment,the data dictionary
`may provide platform-independent data types. In addition,
`services sitting on top of the data dictionary 126 may also
`use the defined data types and values.
`Data access layer 130 provides a persistent data store for
`distributed system 100. The illustrated embodiment of data
`access layer 130 includes database computing device 134
`and data source 136. Database computing device 134 may
`include database management systems (DBMSs). A DBMS
`refers to application software that controls the data in data
`source 136 including the overall organization of the data,
`retrieval of the data, and integrity of the data. Data source
`136 may be, for example, a database or any other data source
`capable of providing a persistent data store.
`FIG.2 is a simplified block diagram ofdistributed system
`200 implemented to provide a platform-independent data
`dictionary, according to an embodiment of the invention.
`Distributed system 200 includes developmentclient 210 and
`application servers 220 and 225. In an embodiment, data
`types 216 are defined by development client 210 during 5
`design time and stored in data dictionary 228. At runtime,
`the operational data for applications executing on applica-
`tion server 220 and 225 maybestructured by the data types
`stored in data dictionary 228.
`Development clicnt 210 includes development tool 212,
`local XMLfiles 214, and data types 216. Developmenttool
`212 provides a software development environmentfor writ-
`ing computer software. In an embodiment, developmenttool
`
`212 is an implementation of the Eclipse Platform available
`under the Common Public License from the Eclipse Con-
`sortium (www.eclipse.org). In an alternative embodiment,
`development
`tool 212 may be a different development
`environment.
`Developmentclient 210 may use developmenttool 212 to
`create data types 216. In an embodiment, data types 216 are
`platform-independent. A platform-independent data type
`refers to a data type that may be used by dissimilar systems
`
`
`
`60
`
`65
`
`4
`(e.g., systems that use dissimilar software and/or hardware).
`In one embodiment, data types 216 are plattorm-indepen-
`dent because they comply with the XML Standard. The
`XMLStandard specifies a markup languagethat uses tags to
`specify the content and structure of the data enclosed by the
`tags. Data that complies with the XML Standard is platform-
`independent because the data’s content and structure is
`specified by the tags. A schema maybe used to define the
`legal elements and structure of an XML document. A schema
`may comply with, for example, the schema standard pro-
`mulgated by the W3C entitled, “XML Schema Part 1:
`Structures and XMI, Schema Part 2: Datatypes,” 2 May
`2001 (hereinafter,
`the XML Schema Standard).
`In an
`embodiment, the structure of data types 216 may be speci-
`fied by one or more schemas that comply with the XML
`Schema Standard.
`
`
`
`In an embodiment, someorall of the data types 216 may
`be transferred to data dictionary 228, for example, via
`network connection 240. Network connection 240 may be a
`LAN, WAN, MAN,and/or the Internet. In an embodiment,
`data types 216 are transferred over network connection 240
`according to the Protocol described in Request For Com-
`ments (RFC) 2616 entitled, “HyperText Transport Proto-
`col—HTTP/1.1,” June 1999 (hereinafter, the HTTP Proto-
`col). In alternative embodiments of the invention, data may
`be transferred according to a different protocol.
`Application server 220 includes J2EE server 224, propri-
`etary application server 226, and data dictionary 228. J2EE
`server 224 is. for example, a Web application server that
`complies with the J2EE Standard. Proprietary application
`server 226 may be a proprietary application server to support
`user terminals that implement a proprietary distributed sys-
`
`tem. In an embodiment, J2EE server 224 and/or proprietary
`application server 226 structure operational data based, at
`least in part, on the data type stored in data dictionary 228.
`In an embodiment, the representation of a data type at
`design time is different than the representation of the data
`type at runtime. FIG. 3 is a simplified block diagram
`illustrating design time data type 310 and run time data type
`320. In an embodiment, design time data type 310 and
`runtime data type 320 are written in accordance with a
`schemathat defines the legal (or permitted) structure for the
`elements that are the constitute parts of a data type. In an
`embodiment, the elements of design time data type 310 and
`runtime data type 320 may include, for example, properties,
`constraints, attributes, preexisting data types, built-in types
`and the like. A “property” refers to an element of a schema
`(or file) that provides information about data (e.g., whether
`the data is a string or an integer). A built-in type refers to an
`element that is “built-in’* to the programming environment.
`A “preexisting data type” refers to a data type that has been
`previously defined.
`Tn an embodiment, data types 310 and 320 comply with
`the XML SchemaStandard. In an embodiment, the elements
`of data types 310 and 320 comply with the XML Standard.
`In alternative embodiments of the invention, data types 310
`and 320 comply with a different schema standard and the
`elements within data types 310 and 320 comply with a
`different language standard (e.g., a different markup lan-
`guage).
`Design time data type 310 includes properties 312 and
`314, pointer 316, and built-in type 318. Pointer 316 points
`to a preexisting data type 300 upon which data type 310 is
`based. For example, preexisting data type 300 may define a
`field. Data type 310, m turn, may define a table that includes
`the previously defined field. In the illustrated embodiment,
`built-in type 318is any of the built-in typesthat are available
`
`Booking, Exh. 1048, Page 12
`
`Booking, Exh. 1048, Page 12
`
`

`

`US 7,191,160 B2
`
`5
`to the programming language in which data type 318 is
`written. In an embodiment, built-in type 318 is one of the
`built-in types of the XML Standard. Properties 312 and 314
`define attributes of data type 310. In an embodiment, prop-
`erties 312 and 314 comply with the XML Standard. In an
`alternative embodiment, data type 310 inherits the properties
`of a previously existing data type (not shown). In such an
`embodiment, one or moreproperties of the preexisting data
`type may be modified (e.g.. by overwriting the one or more
`properties) to create data type 310.
`In an embodiment, generating process 330 converts
`design time data type 310 into runtime data type 320.
`Converting design time data type 310 into runtimedata type
`320 includes, in the illustrated example, replacing pointer
`316 (which points to data type 300) with data type 300. For
`further information regarding replacing a pointer with a file
`(e.g., an XML file representing data type 300) see, for
`example,
`the Java 2 Platform, Standard Fdition (J2SF),
`version 1.4.2, published June 2003 (hereinafter, the J2SE
`Standard).
`In an embodiment, an application (not shown) builds
`Object 340 based on underlying data type 320. The term
`“object” refers to a self-contained entity that may consist of
`both data and procedures to manipulate the data. In an
`embodiment, Object 340 is an instance of the data type
`defined by data type 310. Object 340 is further discussed
`below with reference to FIG. 7.
`
`10
`
`20
`
`FIG. 4 is a conceptual block diagram illustrating distrib-
`uted system 400. In an embodiment, data dictionary 410
`includes simple dala type 412, complex data type 414,
`database data type 416, and user interface data type 418.
`Simple data type 412 and complex data type 414 are more
`fully described below with reference to 'IG.6.
`In an embodiment, database data type 416 provides, at
`least in part, the semantic and syntactic definition of opera-
`tional data for data access logic 430. Examples of database
`data type 416 include a definition of a database element,
`field, and/or table. Database data type 416 may specify
`properties for a database object
`including, for example,
`specifying the Java Database Connectivity driver (IDBC)
`with which the object may used. The term JDBC driver
`broadly refers to an Application Program Interface (API)
`that is bundled with the Java 2 Platform, Standard Edition
`(J2SE), version 1.4.2, published June 2003. In alternative
`embodiments of the invention, other APIs may be specified
`by database data type 416.
`In an embodiment, User Interface (UI) data type 418
`provides, at least in part, the semantic and syntactic defini-
`tion of operational data for presentation logic 420. Examples 5
`of UT data type 418 include data types that determine the
`layout, composition, and/or color of objects that are dis-
`played to a viewer (not shown). The properties of a UI data
`type may specify, for example,a field label, a column label,
`help text, and the like. UI data type 318 is further described
`below with reference to FIG. 6.
`
`40
`
`A data type defines, for example, how data is stored in
`memory. Different data types may exist because data may be
`used differently in distributed system 400. For example,
`character-lype data is typically used to store and display
`values, whereas numerical-type data is used to perform
`calculations. Examples of data types used in distributed
`system 400 are further described below with reference to
`FIG. 6. Also, certain applications may require specifically
`defined data types. For example, a JDBC driver may use
`database data type 416, whereas a Web browser may use UI
`data type 418.
`
`6
`FIG. 5 illustrates an exemplary data statement 500 that
`may be used to request a data type, in an embodiment of the
`invention. A data type defines the attributes of a data object.
`Reference numeral 510 illustrates that the requested data
`type is “c” which,inthe illustrated embodiment, refers to a
`character-type data type. The requested data object may
`have a length of 15 characters as illustrated by reference
`numeral 520. The data type of a data object determines how
`an application will handle the data. Data statement 500 may
`be used to create a data object that an application can access
`via the name“text.” In the illustrated example, an applica-
`tion accessing the data object named “text” will store the
`object as character-type data in memory.
`FIG.6 is a conceptual illustration of data types available
`in an embodiment of the invention. In an embodiment, data
`types may be written or encoded in a markup language. A
`“markup language” refers to a computer software language
`in which labels are embedded within text to distinguish
`individual elements or groups of elements for display and/or
`identification purposes. The term “markup language based”
`refers to a software entity written, and/or encoded, and/or
`formatted in one of the markup languages. For example, in
`an embodiment, data types are encoded in one of the
`[Extensible Markup Languages (XMLs)
`(e.g.,
`the XML
`language specified by the XML Standard). The term “XML
`based” refers to a software entity written, and/or encoded,
`and/or formatted in one of the XML languages.
`In an embodiment, data types may be hierarchically
`organized into either scalar type 610 or complex type 620.
`Scalar type 610 broadly refers to data types that hold a single
`data element such as an integer or a character.
`In an
`embodiment, scalar types may, for example, include: integer
`data types, string data types, floating point data types, and/or
`decimal data types.
`Scalar type 610 includes built-in type 612 and simple type
`614. Built-in type 612 represents scalar data types that are
`“built-in” to the schema that is used to define data types. In
`an embodiment, data types are structured according to the
`XML Schema Standard. In such an embodiment, built-in
`type 612 represents a built-in type of the XML Schema
`Standard. In alternative embodimentsof the invention, built-
`in type 612 may represent a built-in type of another and/or
`a different standard.
`
`In an embodiment, simple data type 614 represents a user
`defined scalar type. Simple data type 614 may be, for
`example, a user defined database data type (e.g., specifying
`a JDBC driver), a user defined UI data type (e.g., specifying
`the structure of a display), and/or previously defined data
`types from a proprietary system.
`Complex type 620 refers to data types that hold multiple
`data items. In an embodiment, complex type 620 includes
`structure data type 630, list data type 640, and/or tree data
`type 650. In an embodiment, structure data type 630 con-
`tains one or more named fields. Each of the two or more
`named fields may contain a data type of any type. In an
`embodiment, flat structure data type 660 refers to a struc-
`tured data type in which all of the named fields are scalar
`data types. List data type 640 refers to an ordered group of
`elements belonging to the same data type. In an embodi-
`ment, tree data type 650 refers to a data type having one root
`element and zero or more non-root elements. Each non-root
`element may have one predecessor elementand zero, one, or
`more successor elements. Database table 662 may be a data
`type defining a database table. In an embodiment, database
`view 664 is a flat structure data type defining a logical view
`of one or more database tables.
`
`Booking, Exh. 1048, Page 13
`
`Booking, Exh. 1048, Page 13
`
`

`

`US 7,191,160 B2
`
`7
`Data types may be defined independently of the applica-
`tions that use them. Applications may use data types to
`define data objects. The term “data object” refers to a
`self-contained module of data and its associated processing.
`In an embodiment, data objects comply with the Java
`Specification Request 12 entitled, “Java Data Objects (JDO)
`Specification,” Apr. 30, 2002.
`In an embodiment, data objects (which are based on
`underlying data types) are copied and modified to form local
`data objects for an application. In an embodiment, data
`objects based on simple type data types are locally copied
`and modified. Copying and modifying data objects provides
`a mechanism to increase the variety of data objects that are
`supported bya data dictionary. FIG. 7 is a simplified block
`diagram illustrating, the copying and modifying, of object
`710. Data object 710 is an instance of a data type that
`includes core data type 715, UI data type 720, and/or
`database data type 725. An application executing on an
`application server (¢.g., J2EE Server 224, shown in FIG. 2)
`may create data object 710 in memory based on data types
`in a data dictionary (e.g., data dictionary 228, shown in FIG.
`2). In an embodiment, data object 710 is an instance a simple
`type.
`The application may copydata object 710 to create data
`
`object 730. Copying a data object may be performed accord-
`ing to, for example, the J2SE Standard. In an embodiment,
`methods may be called to add, remove, and/or change the
`constitute parts of data object 730. For example, database
`data type 725 maybe removed and simple data type 745 may
`be added to data object 730. Similarly the properties of UI
`data type 720 may be changed to form UI data type 740.
`Turning now to FIGS. 8 and 9, the particular methods
`associated with embodiments of the invention are described
`in terms of computer software and hardware with reference
`to a flowchart. The methods to be performed by a platform-
`independent data dictionary may constitute state machines
`or computer programs made up of computer-executable
`instructions. Describing the methods by reference to a
`flowchart enables one of ordinaryskill in the art to develop
`such programs including such instructions to carry out the
`methods onsuitably configured computing devices(e.g., one
`or more processors of a node) executing the instructions
`from computer-accessible media. ‘he computer-executable
`instructions may be written in a computer programming
`language or may be embodied in firmwarelogic. If written
`in a programming language conforming to a recognized
`standard, such instructions can be executed on a variety of
`hardware platforms and for interface to a variety of operat-
`ing systems. In addition, embodiments of the invention are
`not described with reference to any particular programming 5
`language. It will be appreciated that a variety of program-
`ming languages may be used to implementthe teachings of
`the invention as described herein. Furthermore,it is common
`in the art to speak of software, in one form or another(e.g.,
`program, procedure, process, application, ctc.), as taking an
`action or causing a result. Such expressions are merely a
`shorthand way of saying that execution of the software by a
`computing device causes the device to perform an action or
`producea result.
`FIG. 8 is a flow diagram illustrating certain aspects of a
`method for providing a platform-independent data type,
`according to an embodiment of the invention. Referring to
`process block 810, a request for a data type is received(e.g.,
`via exemplarydata statement 500, shown in FIG. 5). In an
`embodiment,
`the request for the data type originates at
`design time from, for example, a development tool (e.g.,
`development tool 212, shown in FIG. 2). In analternative
`
`40
`
`45
`
`8
`the request for the data type originates at
`embodiment,
`runtime from an application (e.g., presentation logic 420,
`data access logic 430, and/or business logic 440, shown in
`FIG. 4).
`Referring to process block 820, a platform-independent
`data type is provided from a data dictionary responsiveto the
`received request for a data type. A platform-independent
`data type refers to a data type that may be used by dissimilar
`systems.
`In an embodiment,
`the provided data type is
`platform-independent because it complies with the XML
`Standard. A data type that complies with the XML Standard
`is platform-independent, at least in part, because the XMT.
`Standard specifies a markup language that makes data
`portable across different platforms.
`FIG. 9 is a flow diagramillustrating certain aspects of a
`method for receiving and processing a platform-independent
`data type during design time. Referring to process block
`910, a platform-independent data type is received. In an
`embodiment, the received data type complies with the XML
`Standard and may be sent from a developmentclient (e.g.,
`development client 210 shown in FIG. 2) during design
`time. The received platform-independent data type may be
`stored in a data dictionary(e.g., data dictionary 228 shown
`in FIG. 2) at 920.
`Referring to process block 930, a request for the stored
`data type is received at process block 930. In an embodi-
`ment, a first Java application (e.g., development tool 212)
`requests the stored data type during design time.
`‘Uhe
`requested data type is provided at 940. In an embodiment,
`more than one application may usea data type during, design
`time. Process block 950 illustrates receiving a request for the
`data type from a second Java application (e.g., a second
`development tool) during design time. The data type is
`provided to the second Java application at 960.
`In an
`embodiment the requesting Java applications and the data
`dictionary may be on separate nodes (e.g., development
`client 210 and application server 220 shownin FIG. 2). In
`such an embodiment, a T.AN, WAN, MAN, and/or th