United States Patent
`(12)
`(10) Patent N0.:
`US 7,191,160 B2
`
`Hoeft et a1.
`(45) Date of Patent:
`Mar. 13, 2007
`
`USOO7191 160B2
`
`(54) PLATFORM-INDEPENDENT DATA
`DICTIONARY
`
`(75)
`
`'
`’
`Inventors: Kerstin Hoeft; Walldorf (DE); l\Iichael
`Tsem’ Hadelberg (DE)
`(73) Assignee‘ SAP AG Walldorf (DE)
`
`5,991,771 A *
`6,377,953 1311’;<
`6,636,845 B2 *
`
`.
`,
`'
`$183522; 3;:
`7,080,384 132*
`7,117,215 B1 *
`
`11/1999 Falls et a1. .................. 707/202
`4/2002 Gawlick et al.
`.. 707/102
`10/2003 Chau et al. .......... 707/1
`
`..
`..
`e 0 e a.
`737/131
`23832 glitllert "'1'
`.........
`.. 719/316
`7/2006 Wall etal.
`
`........ 707/100
`10/2006 Kanchwalla et a1.
`
`
`
`( * ) 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 al,, Extensible markup Language (XML) [.0 (Second
`Edition) W3C Recommendation Oct. 6, 2000, http://wwwaorg/
`TR/REC-xml.*
`
`(21) Appl. No; 10/705,046
`
`(22) Filed:
`
`N0“ 109 2003
`
`(65)
`
`Prior Publication Data
`
`Scp. 15’ 2005
`
`US 2005/0203938 A1
`Int. Cl.
`(2006.01)
`G06F 15/18
`(52) US. Cl.
`............................ 706/12; 706/45; 706/46;
`707/100
`(58) Field of Classification Search .................... 707/1,
`707/100 102 103. 706/45 46 12
`S
`1.
`t'
`fil
`f
`’
`1
`’
`’ h h' t ’
`r
`’
`ee app 1ca ion
`e or comp ete searc
`ls 012’
`References Cited
`U.S. PATENT DOCUMENTS
`
`(51)
`
`(56)
`
`Henry S Thompson et al., XML Schema Part 1: Structures, W3C
`Recommendation May 2, 2001, Sections 3.4, 3.14 http://WWW.VV3.
`
`org/TR’200l/REC-Xmlschema-l-20010502/,*
`* "t d b
`'
`01 e
`y examiner
`Joseph P Hirl
`Primary Examiner
`(74) Attorney, Agent, or Fir/riiBlakely, Sokolofl, Taylor &
`Zafman LLP
`.
`57
`)
`(
`to store
`include a data diction
`A server s stem ma'
`t
`firyl.
`1 n?
`.
`31
`d tyd t
`t
`A d
`1
`p a orm—in epen en aa ypes.
`eve opmen c 1en may
`access and mod1fy a platform-mdependent data type stored
`in the data dictionary. The server system may notify other
`development clients using the data type that the data type has
`been modified.
`
`i
`,
`ABSTRACT
`
`5,418,957 A *
`
`5/1995 Narayan ..................... 717/113
`
`20 Claims, 9 Drawing Sheets
`
`
`
`100
`
`Page 1 of 16
`
`GOOGLE EXHIBIT 1022
`
`Page 1 of 16
`
`GOOGLE EXHIBIT 1022
`
`

`

`US. Patent
`
`Mar. 13, 2007
`
`Sheet 1 of 9
`
`US 7,191,160 B2
`
`100
`
`Dictionary
`
`Data
`
`Page 2 of 16
`
`Page 2 of 16
`
`

`

`US. Patent
`
`Mar. 13, 2007
`
`Sheet 2 of 9
`
`us 7,191,160 132
`
`
`
`339‘9.2.
`
`LmZommmww
`
`VNN
`
`mcozmo=aq<
`
`aa<Emawtaoi
`
`52mm
`
`oNN
`
`
`
`EmcozofiEma
`
`wmm
`
`8550
`
`mnm
`
`N.OE
`
`mE68.
`
`
`
`l=2x.804
`
`BE
`
`in
`
`
`
` oE8%...Ema
`
`Page 3 of 16
`
`Page 3 of 16
`
`

`

`US. Patent
`
`D4ar.13,2007
`
`Sheet3 0f9
`
`us 7,191,160 132
`
`$8.5B>tmqoiv
`
`
`
`Aucmcom33.Emov
`
`Aim8m9598v
`
`
`
`Aomm33.3mm.HoEmaoiv
`
`8%83.9mm“63.39%
`
`
`
`Atflwownon:Smov
`
`
`
`A33.:E__:mv
`
`Aucmomm8»»F98v
`
`omm
`
`A02”33.Engho>tmno._n_v
`
`norm839mg.8>tmnoiv
`
`
`
`A080%...EmaB.QEomv
`
`A55Sm3?98v
`
`
`
`A33.:_-H__:mv
`
`o5AncmSmm9?8va
`
`N5
`
`in
`
`8m
`
`3m
`
`8mwe:38
`
`3:5.53m
`
`o;2528
`
`Page 4 of 16
`
`Page 4 of 16
`
`
`
`
`

`

`US. Patent
`
`Mar. 13, 2007
`
`Sheet 4 of 9
`
`us 7,191,160 132
`
`v..®_n_
`
`coszmwmi
`
`meE00
`
`
`
`83.9mm
`
`iv
`
`
`
` o3E95305EmD
`
`wmmnmamo
`
`
`
` m395.San.
`
`Sun..3
`
`mg»...
`
`mg
`
`03
`
`omv
`
`omv
`
`0333355
`
`053$82Ema
`o_mo._
`
`Page 5 of 16
`
`Page 5 of 16
`
`

`

`U
`
`tneta
`
`wM
`
`m
`
`S
`
`1V
`
`mSo05omm301NE
`3,3:.«w:9:82533.29:58352:5,.
`
`
`
`
`
`
`
`cum05ourxmanowas.5:95
`
`Pa.».mmm«b.._.uD
`
`Page 6 of 16
`
`us 7,191,160 132
`
`f0
`
`9I
`5©mu_n_
`
`m.0mm
`
`
`.nn.9:6256....
`
`39>mo2anmo
`
`.vmmmoo
`
`mOE
`
`odw
`
`
`
`.8390Sam.m5._<>Omm>._.3;me<F<D\\oEomm
`
`
`
`
`
`Page 6 of 16
`
`
`

`

`8399:5
`
`
`
`
`
`mwfim9»...Emammmnmumo
`
`US. Patent
`
`D4ar.13,2007
`
`Sheet6 0f9
`
`us 7,191,160 132
`
`——————_———mmmmm$mmm—————_———
`
`m:83295m
`
`mm
`
`N.0_u_
`
`ma>._...m_qE_m
`
`
`
`09::23
`
`83i=5
`
`m?an?Ema900
`
`mi.83Bag900
`
`Page 7 of 16
`
`ofi3?9mm5
`
`Page 7 of 16
`
`

`

`US. Patent
`
`Mar. 13, 2007
`
`Sheet 7 of 9
`
`US 7,191,160 B2
`
`receiving a request for a data type
`
`
`
`
`
`
`PTOVidiflg 3 platfonn—independent data
`type fi'om a data dictionary, responsive
`
`to the request for the data type
`
`
`
`81 0
`
`820
`
`FIG. 8
`
`Page 8 of 16
`
`Page 8 of 16
`
`

`

`US. Patent
`
`Mar. 13, 2007
`
`Sheet 8 of 9
`
`US 7,191,160 B2
`
`receiving a platfonn-independent data
`
`,
`storing the platform-independent data
`
`type
`type in a data dictionary
`
`
`receiving, during design time, a request
`
`for the stored data type fiom a first Java
`
`application
`
`providing the requested data type to the
`first Java application
`
`receiving, during design time, a request
`for the data typefrom a second Java
`application
`
`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
`
`notifying the secondJava applicationthat
`
`F I G 9
`
`.
`
`Page 9 of 16
`
`910
`
`920
`
`930
`
`940
`
`950
`
`960
`
`970
`
`980
`
`Page 9 of 16
`
`

`

`US. Patent
`
`D4ar.13,2007
`
`Sheet9 0f9
`
`us 7,191,160 132
`
`
`
`o_\.0_n_
`
`Ema
`
`Emcozofi
`
`omor
`
`{05oz
`
`AmvmomtBE
`
`ovo_.
`
`008
`
`O:
`
`Amvmusmo
`
` one
`
`oEFAmrommmooi
`
`Page 10 of 16
`
`Page 10 of 16
`
`
`
`
`

`

`US 7,191,160 B2
`
`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 tenn “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
`rtmtime. 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 clientfserver 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 dilferent 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
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`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.
`
`60
`
`65
`
`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
`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 “platforrn-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/0r 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
`0(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 comrects to the Intemet, 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 perfomrs 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
`
`Page 11 of16
`
`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 J2E3 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 (wwweclipseorg). In an alternative embodiment,
`development
`tool 212 may be a different development
`environment.
`Development client 210 may use developme 1t 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
`
`30
`
`35
`
`40
`
`45
`
`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 JZEE 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 pro arietary application server to support
`user terminals that imp ement a proprietary distributed sys—
`
`tem. In an embodiment, J2133 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 dilferent 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 dilferent schema standard and the
`elements within data types 310 and 320 comply with a
`diiferent 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
`
`Page 12 of 16
`
`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 JZSE
`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 bLmdled with the Java 2 Platform, Standard Edition
`(JZSE), 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 III 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.
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`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.
`
`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, fiat 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.
`
`Page 13 of 16
`
`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 orr 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 0 3ject may be performed accord-
`
`ing to, for example, the J2S3 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 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 ordinary skill in the art to develop
`such programs including such instructions to carry out the
`methods on suitably configured corrrputirrg 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). I11 an alternative
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`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 platfomr-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 diagrarrr illustrating certain aspects of a
`method for receiving and processing a platform-independent
`data type during design time. Referring to process block
`910, a platforrn—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 platfonn-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,
`rrrore 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 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 shown in FIG. 2). I11
`such an embodiment, a LAN, WAN, MAN, and/or the
`Internet may link the nodes and a transport protocol (e.g., the
`HTTP Protocol) may be used to transport the requests and/or
`the requested data type.
`Referring to process block 970, a notification that the first
`Java applicat