`(12)
`(10) Patent No.:
`US 7,191,160 B2
`
`Hoeft et a].
`(45) Date of Patent:
`Mar. 13, 2007
`
`USOO7 l 91 160B2
`
`(54) PLATFORM-INDEPENDENT DATA
`DICTIONARY
`
`(75)
`
`Inventors: Kerstin Hoeft, Walldorf (DE); Michael
`-
`-
`Tsem’ Heldelberg (DE)
`(73) Assignee: SAP AG, Walldorf (DE)
`
`11/1999 Falls et a1. .................. 707/202
`5,991,771 A *
`4/2002 Gawlick et a1.
`.. 707/102
`6,377,953 B1 *
`6,636,845 B2* 10/2003 Chau et a1. ............. 707/1
`
`787/181
`33882 lg/Iitllert 1~~~~~~~~~
`358251522; 3::
`..
`e 0 e a .
`......
`,
`,
`7/2006 Wall et a1.
`.................. 719/316
`7,080,384 B2*
`7,117,215 B1 * 10/2006 Kanchwalla et a1.
`........ 707/100
`
`
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 509 days.
`
`OTHER PUBLICATIONS
`Tim Bray et a1., Extensible markup Language (XML) 1.0 (Second
`Edition) W3C Recommendation Oct. 6, 2000, http://www.w3.0rg/
`TIUREC-Xml.*
`
`(21) Appl. No.: 10/705,046
`
`(22)
`
`Filed:
`
`NOV. 10, 2003
`
`(65)
`
`Prior Publication Data
`
`Sep. 15’ 2005
`
`US 2005/0203938 A1
`Int. Cl.
`3056FCl5/18
`
`(51)
`(52)
`
`(2006.07106/12' 706/45' 706/46'
`707/100
`(58) Field of Classification Search .................... 707/1,
`707/100, 102, 103; 706/45, 46, 12
`See application file for complete search history
`’
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`Henry S. Thompson et a1., XML Schema Part 1: Structures, W3C
`Recommendation May 2, 2001, Sections 3.4, 3.14 http://WWW.W3.
`
`0rg/TR/200l/REC-Xmlschema-l-20010502/.*
`*
`'t d b
`'
`C1 e
`y examiner
`Primary Examineriloseph P Hirl
`(74) Attorney, Agent, or FirmiBlakely, Sokoloif, Taylor &
`Zafman LLP
`ABSTRACT
`(57)
`to store
`include a data diction
`A server 5 stem ma
`my.
`y
`. y
`platform-independent data types. A development cllent may
`d
`d'
`1 f
`. d
`(1
`da
`(1
`access an m.0 .lfy a p at orm-m epen ent
`ta type store
`1n the data dictionary. The server system may not1fy other
`development clients using the data type that the data type has
`been modified.
`
`5,418,957 A *
`
`5/1995 Narayan ..................... 717/113
`
`20 Claims, 9 Drawing Sheets
`
`Exhibit 1026
`
`Adobe Inc. v. Express Mobile, |nc.,
`|PR2021-XXXXX; US. Pat. 9,471,287, Exhibit 1026
`
`100
`
`Page010f16
`
`Exhibit 1026
`Page 01 of 16
`
`
`
`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 1 0f 9
`
`US 7,191,160 B2
`
`100
`
`Dictionary
`126
`
`Data
`
`Exhibit 1026
`
`Page 02 of 16
`
`Exhibit 1026
`Page 02 of 16
`
`
`
`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 2 of 9
`
`US 7,191,160 B2
`
`
`
`Emmimama.
`
`Lozmmwwwa
`
`VNN
`
`mcozmo=aQ<
`
`
`
`Q94.E92591
`
`53mm
`
`mmm
`
`
`
`595220San.
`
`wmm
`
`Q0550
`
`molm
`
`N«OE
`
`N5Bob
`
`42xKoo;
`
`85
`
`SN
`
`
`
` oE3%...Ema
`
`Exhibit 1026
`
`Page 03 of 16
`
`Exhibit 1026
`Page 03 of 16
`
`
`
`U.S. Patent
`
`Ddar.13,2007
`
`Sheet3 0f9
`
`US 7,191,160 B2
`
`Aoom._.n_963.82%
`
`
`
`Aucmcom33..3va
`
`Aim8m9598v
`
`
`
`3%2;...EmaBEma
`
`Aomm33.BanV63.3
`
`oiv
`
`91v
`
`A55own2538v
`
`$9?:3
`
`__:mv
`
`Aucwomm2;
`.r98v
`
`mmm
`
`
`
`no5.33.Emaho>tmao._n_v
`
`no5on?2mm.5>tmqoiv
`
`A0825982526%
`
`
`
`555Sm09:.38v
`
`
`
`A33.:_-=_:mv
`
`
`
`Aucm3m2;...Smov
`
`mm
`
`N5
`
`in
`
`05
`
`3m
`
`m.OE
`
`8m.2528
`
`8:5-53m
`
`EmSE28
`
`Exhibit 1026
`
`Page 04 of 16
`
`Exhibit 1026
`Page 04 of 16
`
`
`
`
`
`
`
`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 4 of 9
`
`US 7,191,160 B2
`
`v.«GE
`
`063cozficowmi
`
`xmano
`
`
`
`83.9mm
`
`vS»
`
`
`
`b95305Ema
`
`0Eu
`
`mmmnmumo
`
`
`
`.33.Ema
`
`mZ»
`
`END5
`
`mg»...
`
`mg
`
`05393525
`
`
`
`2mgmmmood.Ema
`
`03
`
`omv
`
`omv
`
`Exhibit 1026
`
`Page 05 of 16
`
`Exhibit 1026
`Page 05 of 16
`
`
`
`U
`
`tneta
`
`uM
`
`m
`
`S
`
`f0
`
`US 7,191,160 B2
`
`9I
`
`5m0Ea.08m@3025«mi
`
`32>m0233.m0
`
`
`
`momm.ovo0830ANE3,m9...gm:930.5%09:.29:60%...c_.:_:m_
`
`
`
`
`
`Pg.mmm«b.._.uD
`
`1,
`
`
`
`0%o5me?65:8009:.59%
`
`Exhibit 1026
`
`Page 06 of 16
`
`vowNmo
`.uomEO3mm.m5._<>0wn_>._.33“me<H<D\\oEomm
`
`
`
`
`
`
`
`
`
`m.OE
`
`odw
`
`Exhibit 1026
`Page 06 of 16
`
`
`
`
`U.S. Patent
`
`Ddar.13,2007
`
`Sheet6 0f9
`
`US 7,191,160 B2
`
`——————_——n$$mmmm$m—————_—_—
`
`25525m
`
`
`
`m3.an:Ema€00
`
`ma>.r..m_QE_m
`
`9;25295m
`
`mm
`
`N.0_n_
`
`83295w
`
`
`
`
`
`mmn09:.9mm.829mm
`
`835.5%
`
`m2.m9?Bag900
`
`ofiwe?985
`
`Exhibit 1026
`
`Page 07 of 16
`
`Exhibit 1026
`Page 07 of 16
`
`
`
`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 7 0f 9
`
`US 7,191,160 B2
`
`receiving a request for a data type
`
`
`
`
`
`
`PTOVidiflg a platform-independent data
`type fiom a data dictionary, responsive
`
`to the request for the data type
`
`
`
`81 0
`
`820
`
`End
`
`FIG. 8
`
`Exhibit 1026
`
`Page 08 of 16
`
`Exhibit 1026
`Page 08 of 16
`
`
`
`U.S. Patent
`
`Mar. 13, 2007
`
`Sheet 8 0f 9
`
`US 7,191,160 B2
`
`receiving a platform-independent data
`type
`
`
`
`
`.
`.
`i
`stonng the platform-independent data
`type in a data dictionary
`
`receiving, during design time, a request
`for the stored data type from a first Java
`application
`
`
`
`
`
`
`
`_
`,
`.
`prov1ding the requested data type to the
`first Java application
`
`
`
`receiving, during design time, arequest
`for the data typefrom a second Java
`application
`
`.
`.
`,
`prov1d1ng the requested data type to the
`second Java application
`
`_
`_
`_
`.
`receivmg notification that the first Java
`application has modified the data type
`
`
`
`91 0
`
`920
`
`930
`
`940
`
`950
`
`960
`
`970
`
`980
`
`F I G 9
`
`.
`
`Exhibit 1026
`
`Page 09 of 16
`
`the data type has been modified
`
`..
`
`.
`
`notifying the second Java apphcafionthat
`
`.
`
`.
`
`End
`
`Exhibit 1026
`Page 09 of 16
`
`
`
`U.S. Patent
`
`Ddar.13,2007
`
`Sheet9 0f9
`
`US 7,191,160 B2
`
`O:
`
`@338
`
`or.0_n_
`
`Ema
`
`b20305
`
`omov
`
`{2302
`
`ovowAmvmomtBE
`
`ooor
`
` on?
`
`
`$303805
`
`oFor
`
`Exhibit 1026
`
`Page 10 0f16
`
`Exhibit 1026
`Page 10 of 16
`
`
`
`
`
`
`
`US 7,191,160 B2
`
`2
`
`1
`PLATFORM-INDEPENDENT DATA
`DICTIONARY
`
`TECHNICAL FIELD
`
`Embodiments of the invention generally relate 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. For example, a development
`client may be used to define a data type and store 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 method includes receiving a request for a data type from
`a client 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 of platforms associated with the client system.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Embodiments of the invention are illustrated by way of
`example, and not by way of limitation, 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 of distributed system
`200 implemented to provide a platform-independent data
`dictionary, according to an embodiment of the invention.
`FIG. 3 is a simplified block diagram illustrating design
`time data type 310 and run time data type 320.
`FIG. 4 is a conceptual block diagram illustrating distrib-
`uted system 400.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Exhibit 1026
`
`Page 11 of 16
`
`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
`embodiment of the invention.
`
`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 diagram illustrating 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
`C(ML) 1.0 (Second Edition),” 6 Oct. 2000 (hereinafter, the
`XML Standard).
`FIG. 1 is a block diagram of distributed system 100. The
`illustrated embodiment of distributed system 100 includes:
`user layer 110, application layer 120, and data access layer
`130. Some or 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.
`User layer 110 is the interface between distributed system
`100 and one or more users. The illustrated embodiment of
`
`user layer 110 includes user terminals 1147119. One or more
`of user terminals 1147119 may collect user input and send it
`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 1147119 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 1147119 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
`1227124 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 1227124 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
`
`Exhibit 1026
`Page 11 of 16
`
`
`
`US 7,191,160 B2
`
`3
`among application servers 1227124. In an embodiment in
`which application layer 120 exchanges information with
`user layer 110 Via the Internet, one or more of application
`servers 1227124 may be described as a Web application
`server. Application servers 1227124 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 1227124. For example, applications operating on
`application servers 1227124 may use 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. The first 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 by the 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 of distributed system
`200 implemented to provide a platform-independent data
`dictionary, according to an embodiment of the invention.
`Distributed system 200 includes development client 210 and
`application servers 220 and 225. In an embodiment, data
`types 216 are defined by development client 210 during
`design time and stored in data dictionary 228. At runtime,
`the operational data for applications executing on applica-
`tion server 220 and 225 may be structured by the data types
`stored in data dictionary 228.
`Development client 210 includes development tool 212,
`local XML files 214, and data types 216. Development tool
`212 provides a software development environment for writ-
`ing computer software. In an embodiment, development tool
`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.
`
`Development client 210 may use development tool 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`
`(e.g., systems that use dissimilar software and/or hardware).
`In one embodiment, data types 216 are platform-indepen-
`dent because they comply with the XML Standard. The
`XML Standard specifies a markup language that 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 may be 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 XML 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, some or all 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-
`coliHTTP/ 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
`schema that 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.
`In an embodiment, data types 310 and 320 comply with
`the XML Schema Standard. 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, in turn, may define a table that includes
`the previously defined field. In the illustrated embodiment,
`built-in type 318 is any of the built-in types that are available
`
`Exhibit 1026
`
`Page 12 of 16
`
`Exhibit 1026
`Page 12 of 16
`
`
`
`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 more properties 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 runtime data 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 Edition (J2SE),
`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.
`
`FIG. 4 is a conceptual block diagram illustrating distrib-
`uted system 400. In an embodiment, data dictionary 410
`includes simple data 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 FIG. 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 (JDBC)
`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
`of U1 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 U1 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.
`
`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-type 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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, in the 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 embodiments of 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 element and 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.
`
`Exhibit 1026
`
`Page 13 of 16
`
`Exhibit 1026
`Page 13 of 16
`
`
`
`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 by a 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 (e.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 copy data 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 may be removed and simple data type 745 may
`be added to data object 730. Similarly the properties of U1
`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 ordinary skill in the art to develop
`such programs including such instructions to carry out the
`methods on suitably configured computing devices (e.g., one
`or more processors of a node) executing the instructions
`from computer-accessible media. The computer-executable
`instructions may be written in a computer programming
`language or may be embodied in firmware logic. 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
`language. It will be appreciated that a variety of program-
`ming languages may be used to implement the 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, etc.), 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
`produce a 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 exemplary data 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 an alternative
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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 responsive to 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 XML
`Standard specifies a markup language that makes data
`portable across different platforms.
`FIG. 9 is a flow diagram illustrating 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 development client (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. The
`requested data type is provided at 940. In an embodiment,
`more than one application may use a 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 applica