`
`US 20090055345A1
`
`as) United States
`a2) Patent Application Publication co) Pub. No.: US 2009/0055345 Al
`Mehtaet al.
`(43) Pub. Date:
`Feb. 26, 2009
`
`
`(54) UDDI BASED CLASSIFICATION SYSTEM
`:
`Harish Mehta, Walldorf (DE);
`(76)
`Inventors:
`Thierry Tung, Gaiberg (DE);
`Alexander Zubeyv, Pazardzhik
`(BG); Timm Falter, Kreuzaecker
`
`(DE)
`
`Correspondence Address:
`MINTZ, LEVIN, COHN, FERRIS, GLOVSKY &
`POPEO. P.C
`ONE FINANCIAL CENTER
`BOSTON, MA 02111 (US)
`
`(21) Appl. No.:
`
`11/843,576
`
`(22) Filed:
`
`Aug. 22, 2007
`
`Publication Classification
`
`51)
`(1)
`
`Int. Cl.
`(2006.01)
`GO6F 17/30
`
`(52) US. Ch wee JO7T/1L; 707/E17.001
`
`(57)
`
`ABSTRACT
`
`The subject matter disclosed herein provides methods and
`apparatus, including computer program products, for provid-
`ing a classification service. The method may receive a request
`to access a UDDIregistry. The classification service may
`access metadata representing a classification system for the
`data stored in the UDDIregistry. The classification service
`may provide the data stored in the UDDIregistryin a format
`based on the access metadata. Related apparatus, systems,
`methods, and articles are also described.
`
`fClassification Systems ‘
`
`
`
`
`
`
`
`
`| animals ||Object> 200 |
`\
`xO AGE. os .
`!
`i
`fo RSS PTT 4 i
`(eat) Colue )co
`|
`m
`‘“1\‘,
`Po
`a
`
`
`
`
`System
` fenrectoneea
`Ph
`
`Group Classification
`
`f
`i
`iid
`deedbe
`
` an(Colors|
`
`eeXOCoonan)/
`
`
`
`
`Page 1 of 17
`
`GOOGLEEXHIBIT 1019
`
`Page 1 of 17
`
`GOOGLE EXHIBIT 1019
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 1 of 10
`
`US 2009/0055345 Al
`
`160
`
`| User Interface 110
`
`CLASSIFICATION |
`SERVICE 185
`
`| UDDI REGISTRY
`
`FIG. 1
`
`Page 2 of 17
`
`Page 2 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 2 of 10
`
`US 2009/0055345 Al
`
`a
`
`ms
`
`_ansuseennuacecontennunsnneaeenaneeennsannuneonateaneacueennenennaeeae
`
`f Classificaton Using Group |
`{ Classification Systems
`
`|
`i ObjectA
`|
`co os
`een ad
`/ Animals‘,
`UA AGE, NO
`Lf
`;
`V4
`
`|
`| foe ae
`if { cat
`)} (dog y
`1 (Coat) blue)|
`Lo
`Paar
`SO arr
`NO rat
`5
`Group Classification
`~ apple
`|
`,
`sf
`
`
`System
`| ae:
`—
`=
`i
`
`
`| ObjectB
`
`200
`
`i
`
`
`
`
`
`
`
`
`
`
`
`ren /
`|
`i
`banana} /
`
`:
`BN
`ttatteteettenee
`a
`i
`~
`‘“
`all
`
`
`Sc
`
`|
`i
`;
`
`wal
`
`FIG. 2
`
`Page 3 of 17
`
`Page 3 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 3 of 10
`
`US 2009/0055345 Al
`
`|
`oscS co
`
`a |
`(blue--“cat(applapple} |
`!
`7
`(dogdog(appleapple )
`
`erataanaatatinn
`
`Saini
`
`AAR
`
` Catapsie) ji1
`
`\!
`
`Browse by Fruit, Color, Animal
`oo
`| Browse byCokjor, Animal|Fruit
`a
`
`{!
`
`wd
`
`LanneanennntnnesAteennsnanenetennadnaeennnennennnne na
`
`FIG. 3
`
`recon uaa perenne
`
`ws
`
`lene
`
`Page 4 of 17
`
`Page 4 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 4 of 10
`
`US 2009/0055345 Al
`
`Publication of Service Model
`
`UDDI V3
`
`tModel name=[portType local narne}
`overviewURL= fiwsallocation]
`
`Keyed referencegroup
`
`Categorybag
`type = portType
`namespace = [namespace]
`lypes = eF service
`
`FIG. 4
`
`Page 5 of 17
`
`Page 5 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 5 of 10
`
`US 2009/0055345 Al
`
`Publication of Service
`
`UDDI V3
`
`iModel name={portType local name]
`overviewURL = fvsdi location]
`
`
`oneveveWURL[documentationjocation|=
`
`name]
`
`categorvBag
`type = portType
`NAMESDACE =fnamespace]
`
`
`
`“Riyscalayaiemreferencesystemtmodel]= [physical
`
`Keyed reference group
`deployment unit==_[SAP-DLs
`business object = [SAP BOL
`
`process component =
`
`fdentifierBag
`___ide- internatname= [internal
`
`
`FIG. 5
`
`Page 6 of 17
`
`Page 6 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 6 of 10
`
`US 2009/0055345 Al
`
`Publication of Service Endpoint
`
`Model name=[binding focal name]
`overviewURL = fwsdl location]
`
`categoryBag
`type = binding
`namespace = fnamespace]
`portType = [portType tModel]
`protocol = SOAP
`transport = HTTP
`
`businessService name=[humanreadable name}
`
`categoryBag
`ivype = service
`namespace = {namespace}
`focal name = [service local name]
`types = _eF service
`
`types= eF service
`
`bindingTempiate
`accessPoint = faccess point]
`portType = fportType tModel]
`binding = [binding Model]
`local name = [port local name]
`
`FIG. 6
`
`Page 7 of 17
`
`Page 7 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 7 of 10
`
`US 2009/0055345 Al
`
`Publication of Physical System
`
`UDDI V3
`
`
`tModel name=[ physical system name e.g B7T on is4005]
`
`Siegenrame=[¢.9.B77]
`
`hosthame =hotafea,eab0sia.S051
`
`BusinessSystem partition (ABAPClient) = fe.g 100]
`
`
`
`
`
`systemtype[e.9.1)=
`
`FIG. 7
`
`Page 8 of 17
`
`Page 8 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26, 2009 Sheet 8 of 10
`
`US 2009/0055345 Al
`
`JBPObf? "WUd}SAS
`
`UOHEIYISSE{O10)JEPOUW]
`
`TOSTSASFOHRIYSSESJa=SAAy
`
`
`{HWEJASAYA]=ALUEU
`fuondiuosap}/=uondosap
`
`
`
`"wajshsuoHeayissejodnos610}popouly
` NAS]Ui]=Siusiajai
`
`
`}=UogdiosapweGODUOBEZTUOBAICIJ=AURUJAVONY
`
`dadsinsi5
`
`lifeDUSISS!rJaqueddnb
`
`WSYSASHORRSYISSEDJo=adj
`
`dnarguongezuobaye?=sada}
`fuogduosap
`
`
`
`WwWa}SASUOIEDYISSE]D&joUOHeDang
`
`8“Sid
`
`UONEZHOBQIE=sadA}
`
`beghiobajes
`
`beghiobazes
`
`Page 9 of 17
`
`Page 9 of 17
`
`
`
`

`

`US 2009/0055345 Al
`
`FIG.9
`
`Classification
`
`Patent Application Publication
`
`Feb. 26, 2009 Sheet 9 of 10
`
`me
`
`Ie©u
`
`u4 “
`
`)ii
`
`S2W
`
`u” L
`
`iat
`
`e
`o.
`oe
`Li
`
`al
`
`u
`
`0
`
`Page 10 of 17
`
`Page 10 of 17
`
`

`

`Patent Application Publication
`
`Feb. 26,2009 Sheet 100f10
`
`|=US 2009/0055345 Al
`
`RECEIVING A
`|
`|_-- 1010
`q:
`| REQUEST TO ACCESS
`A UDDI REGISTRY
`
`,ACCESSING, ATA
`
`CLASSIFICATION
`|
`| SERVICE, METADATA
`REPRESENTING A
`CLASSIFICATION
`SYSTEM FORTHE
`DATA STORED IN THE
`UDDI REGISTRY
`
`|
`
`
`
` PROVIDING THE
`
`
`
`i.- 1020
`
`|
`
`DATA, FROM THE
`|
`| UDDI REGISTRY, INA
`|
`FORMAT BASED ON
`THE ACCESSED
`METADATA
`
`~- 1030
`
`
`
`
`
`FiG. 10
`
`Page 11 of 17
`
`Page 11 of 17
`
`

`

`US 2009/0055345 Al
`
`Feb. 26, 2009
`
`UDDI BASED CLASSIFICATION SYSTEM
`
`FIELD
`
`[0001] The present disclosure generally relates to manag-
`ing the providinga classification service.
`
`BACKGROUND
`
`In the drawings,
`FIG. 1 depicts a system including a classification
`
`[0008]
`[0009]
`service;
`[0010]
`tem;
`[0011] FIG.3 isa another diagram depicting a classification
`system;
`FIGS. 4-8 depict tModels;
`[0012]
`FIG. 9 depicts an example of an implementation of
`[0013]
`the classification service; and
`[0014]
`FIG. 10 depicts a process for classifying UDDI reg-
`istry data.
`[0015] Like labels are usedto reter to sameor similar items
`in the drawings.
`
`providing a classification service. In one aspect there is pro-
`vided a computer-implemented method. The method may
`receive a request to access a UDDIregistry. The classification
`service may access metadata representing a classification
`system for the data stored in the UDDIregistry. The classifi-
`cation service may provide the data stored in the UDDIreg-
`istry in a format based on the accessed metadata.
`[0007]
`tis to be understoodthat both the foregoing general
`description and the following detailed description are exem-
`[0002] UDDI (short for Universal Description, Discovery,
`plary and explanatory only andare notrestrictive. Further
`and Integration (UDDJ)is a web-baseddistributed directory
`features and/or variations may be provided in addition to
`to enable entities, such as businesses and web services, to be
`those set forth herein. For example, the implementations
`listed on the Internet, discovered, and then accessed. UDDI
`described herein may be directed to various combinations and
`uses a registry based on the eXtensible Markup Language
`subcombinations of the disclosed features and/or combina-
`(XML). The XML-based UDDIregistry enablesentities to be
`tions and subcombinations of several further features dis-
`listed in the UDDIregistry, which may be accessed through a
`closed belowin the detailed description.
`public Internet or throughaprivate intranet. Whenregistered,
`the registration includes three components whichare as fol-
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`lows:
`a so-called “white pages” registration including
`addresses, contact information, and known identifiers; a so-
`called “yellow pages” registration including industrial cat-
`egorizations based. on standard taxonomies(e.g., using stan-
`dard industrial categorization schemes,
`industry codes,
`product codes, business identification codes, and thelike) to
`make it easier to search throughthelistings; and a so-called
`“oreen pages” registration including technical information
`about services provided or exposed(e.g, discovery informa-
`tion including, interface information, a Uniform Resource
`Locator (URL), a WSDL (Web Services Description Lan-
`guage)ofthe service, andthe like). Past specifications define
`many aspects ofUDDI. For example, the UDDIVersion 3.0.2
`Specification describes the web services, data structures, and
`the behavior of the UDDIregistry (see, e.g., OASIS UDDI
`Version 3.0.2 Specification, dated Oct. 19, 2004).
`[0003] UDDI may be implemented as a webservice acces-
`sible using standard protocols, such as Simple Object Access
`Protocols (SOAP) for messaging and WSDL documents for
`FIG. 1 depicts an exemplary system 100 including a
`[0016]
`describing the protocols, bindings, and message formats
`user interface 110, a classification service 185, and a UDDI
`required to interact with the web serviceslisted in the UDDI
`registry 160, all of which are coupled by network 150a-b
`registry. A service, such as a Web service is an application or
`(e.g., the Internet, an intranet, or any other communication
`program that makesitself available over the Internet or an
`mechanism).
`intranet, may use standardized messaging, such as XML (eX-
`[0017] User interface 110 may be implemented as any type
`tensible Markup Language) and SOAPS and mayuse some
`of interface that enablesinteraction with an application, such
`type of location mechanism, such as UDDIto locate the
`as a webservice. For example, the user interface 110 maybe
`service and its Application Program Interface (API).
`implemented as a browseroraclient application to interface
`[0004] The UDDIregistry may include UDDI data types.
`with (and/or access) classification service 185 and UDDI
`UDDIdata types refer to one or more of the following data
`registry 160. Although the following description refers to a
`types used by the UDDIregistry when storing and accessing
`webservice, other implementations using programs, applica-
`the above-noted white, yellow, and green page information, a
`tions, and services may be used as well.
`businessEntity data type for describing a business or other
`[0018] UDDIregistry 160 includes descriptors of web ser-
`entity for which information is being registered; a busi-
`vices registered al UDDIregistry 160. The descriptors (also
`nessService data type for describing a set of web services
`referred to as service descriptors) may be in the form ofXML
`which may contain one or more bindingTemplates; a bind-
`and may include information to enable finding a web service
`ingTemplate data type for information necessary to invoke
`and binding to the web service. For example, to search for a
`specific web services which may encompass bindings to one
`webservice, user interface 110 searches through XML-based
`or more protocols, such as HTP (Hyper‘lext ‘Llransfer Pro-
`descriptions of web services included in UDDIregistry 160.
`tocol); and a tModel data type which is a technical model
`When a web service is found, the UDDI registry includes
`representing reusable constructs.
`information (e.g.,a WSDI description of the web service) to
`[0005] UDDI may thus provide a useful mechanism to
`enable user interface 110 to bind to the web service. The
`enable entities (e.g., web services, businesses, and the like) to
`descriptors ofthe web service include elements, such as white
`register at a UDDIregistry one or moreof the following, the
`pages information, yellow pages information, green pages
`identity of the entity, the location of the entity, and howto
`information, tModels, as well as other metadata.
`access andinteract with the entity. As such, other entities can
`[0019] Classification service 185 may be implemented as a
`find and then access the registered entities.
`webservice and include one or more APIs. Through one ofthe
`APIs, classification service 185 managesclassification data
`and is a source ofclassification data. The classification data
`refers to information (e.g., metadata), which may be used to
`formclassification systems from data in UDDIregistry 160.
`
`FIG. 2 is a diagram depicting a classification sys-
`
`
`
`DETAILED DESCRIPTION
`
`SUMMARY
`
`[0006] The subject matter disclosed herein provides meth-
`ods and apparatus, including computer programproducts, for
`
`Page 12 of 17
`
`Page 12 of 17
`
`

`

`US 2009/0055345 Al
`
`Feb. 26, 2009
`
`For example, key identifiers may be used to identify informa-
`tion in a UDDIregistry. The classification data (i.e., meta-
`data) may be usedto format(e.g., organize, describe, classify,
`and the like) data in the UDDI registry. Moreover, the classi-
`fication data may be used to form classification systems, as
`described below.
`
`sification service 185) to classify data in the UDDIregistry
`(c.g., cat, dog,rat, red, bluc, yellow, pear, apple, and banana).
`For this UDDI registry data,
`the classification data may
`include metadata describing groups (e.g., animals, colors,
`and fruits). Moreover,
`the classification data may also
`describe other classification systems based on these groups.
`For example, the metadatastored at classification service 185
`[0020] Classification service 185 managesandstores clas-
`sification data. Classification service 185 enables information
`may describe group formats including animals, colors, and
`fruits, such as “Object A.” The metadata may thus include
`stored in UDDIregistry 160 to be accessed and classified
`descriptions (e.g., XML-based descriptions) as well as links
`according to a predefined classification system (e.g., as
`to identifiers (e.g., keys) in the UDDIregistry. For example,
`described below with respect to FIGS. 2 and 3). As such,
`an identifier “1010” may be associated with the UDDIregis-
`classification service 185 may cnable user interface 110 to
`try data for “dog” and maybe associated with metadata to
`view and browse data in UDDIregistry 160 based onpre-
`enable classification of “dog”registry data as classification
`defined classification systems, such as a hierarchy format, a
`system “Animals.”
`flat format, a group format, or in any other format defined by
`[0026] Classification service 185 mayprovide a variety of
`classification service 185. As such, data in UDDIregistry 160
`different, predefined classification systems. In some cases,
`may be formatted (e.g., presented, searched, browsed, orga-
`the classification service 185 may include templates (or
`nized, classified, and the like) based classification systems
`examples) of predefined classification systems(e.g., possible
`defined by classification data (i.e., metadata) stored in clas-
`values, descriptions, and format), which may be augmented
`sification service 185—enabling customized classification
`dynamically at design time and at runtime. In some imple-
`schemes for UDDIregistry data.
`mentations, the ability to add values “onthe fly”to a classi-
`[0021]
`Insome implementations, classification service 185
`fication system via the APIoftheclassification service 185 is
`is separate from UDDIregistry 160. Moreover, classification
`an advantage of the subject matter described herein since
`service 185 may manage the classification of any data in
`design time tools may now allow a developer to classify
`UDDIregistry 160. The classification service 185 may also
`services they have built to dynamically add values to the
`perform one or moreofthe following functions; expose APIs
`predefined classification systems without, in some cases, hav-
`to retrieve the list of supported classification systems and
`ing to perform cumbersomesteps (e.g., export/import steps,
`their related metadata; expose APIs to retrieve the entire
`re-install, re-deploy, and the like). Moreover, the classifica-
`contentof a classification system; expose APIs to write con-
`tion service 185 may, in some implementations, allow clas-
`tent to a classification system; and expose the UDDI V3
`sification systems to be transported between systems (so-
`standard get_allValidValues API to allow UDDI V3servers to
`called “landscapes”’) on-the-fly. For example, when a new
`cacheclassification system valuesin order to check validity at
`value is added to a classification system in a development
`UDDIentity save time.
`landscape, the new value would enter the production land-
`[0022] Moreover, in some implementations, classification
`scape only when a web service using the new value is
`service 185 may include different types of predetermined
`deployed in a runtime, production landscape.
`classification systems(also referred to as taxonomies), such
`[0027]
`In one implementation, the initial content for each
`as a flat format, a hierarchy format, a group format, and the
`predefined classification system is provided as a flat, tab
`like. A flat classification system is simply a flat list of codes
`separatedtextfile, which is included aspart of the classifica-
`and descriptions. The code values are used directly as the
`tion service 185. The flat, tab separated text file may be
`value attribute of keyed reference elements used for UDDI
`implemented as four columnsas follows; column 1 including
`registry data categorization. A hierarchy classification system
`a code; column2 including descriptive text, column3 includ-
`is a tree-like format in which each node in the tree has a code
`ing parent information; and column 4 including information
`and, possibly, a description. With the hierarchy formats the
`regarding whether the code of column 1 may be used. for
`code maynot (without more information) identify a node in
`classification. Moreover,the first rowoftheflat, tab separated
`the tree since a nodein thetree is identified uniquely by the
`text file may include the namesofthe columns(e.g., a string
`code together with the path fromthe root of the tree to that
`of ASCII text). For example, column 1 may include a code
`code. In hierarchy classification systems where the codesare
`representing a valueattribute of a keyed reference. Column 2
`not all unique throughoutthe trees the code value alone can-
`may includetext for describing the code ofcolumn1. Column
`not be usedas the valueattribute ofkeyed reference elements
`3 may be used to support classification systems formatted as
`for UDDIregistry data categorization. Instead, the path and
`trees by identifying path information(e.g., information iden-
`the code must be used. A groupclassification system is a way
`tifying one or more nodes associated with the tree hierarchy
`to associate values fromflat and/or hierarchy formats.
`or a parent nodein the hierarchy). In some implementations,
`[0023]
`FIG. 2 depicts an example ofa group classification
`a node in the tree hierarchy is a so-called “parent node”
`200. The group defines its constituent classification systems,
`having a unique identifier to identify the parent node from
`which in this example represents object A, object B, and
`other nodes. When the value in column4is “no”or “false,”
`object C. Each value in a groupclassification systemis thus a
`this represents that the code of column 1 may notbe used to
`set of values. The set contains zero or one valueper constitu-
`classify data, wherein any other values in column 4 represent
`ent classification system. Group hierarchies are modeled as
`that the code of column 1 maybe usedto classify data.
`keyed reference groups.
`[0028] Through the APIof classification service 185, meta-
`[0024] 1G. 3 depicts an example ofa group classification
`data storedat classification system 185 may be used to access
`system 300 expressed as a tree including different constituent
`informationto provideclassification systemsfor registry data
`classification systems forming each level of the tree. The
`stored in UDDIregistry 160. Tables 1-4 include parameters
`used in one or morecalls to an API of classification service
`classification service 185 supports the depicted presentation
`of groups as trees. Thecaller (e.g., user interface 110) may
`185 (e.g., user interface 110 makes a call using SOAP to
`specify the order of the constituent classification systems.
`classification service 185 to access registry data stored at
`[0025] Referring to FIGS. 2 and 3, classification service
`UDDIregistry 160). Moreover, these parameters mayrepre-
`185 mayuseclassification data (e.g., metadatastored in clas-
`sent metadata to describe the data in the UDDIregistry 160.
`
`Page 13 of 17
`
`Page 13 of 17
`
`

`

`US 2009/0055345 Al
`
`Feb. 26, 2009
`
`TABLE 1
`
`Classification System Metadata
`Classification System Metadata (all types of classification systems
`
`Name
`
`Id
`
`Name
`description
`Type
`isPredefined
`
`Type
`
`String
`
`String
`String
`Int
`Boolean
`
`isReadOnly
`
`Boolean
`
`isOnlyOnce
`
`Boolean
`
`valuesVersion
`
`Long
`
`Descripton
`
`Identifies the classification system. It can be the UDDI V3
`tModel Keythat represents that Classification System.
`The nameoftheclassification system
`Description of the classification system.
`Thetype oftheclassification system. FLAT = 0, HIERARCHY = 1
`or GROUP = 2
`True ifthis classification system is a one of the Predefined
`Classification Systems.
`True if the values ofthis classification system cannot be
`modified using the write APIs.
`Trueif it is semantically wrong to classify the same thing more
`than onceusing this classification system.
`Version ofvalues ofthis classification system. This version is
`changedon each saveordelete of values ofthis system.
`
`TABLE 2
`
`TABLE2-continued
`
`Classification System Metadata
`Classification System Metadata (FLAT and IIIERARCITY
`
`Classification System Metadata
`Classification System Metadata (FLAT and ITERARCITY.
`
`Name
`
`must]IaveDescription
`
`normalizeCodes
`
`Type
`Description
`Boolean True if the each value ofthe
`classification system must have
`a description.
`Boolean If true, the codes ofthis value set are
`“normalized” before being processed
`by the save APIs. “Normalization”
`
`Name
`
`Type
`
`Description
`
`consists of: conversion to lowercase,
`UNICODEnormalization, stripping of
`leading andtrailing white space, and
`collapsing of any remaining white space
`into a single space character.
`
`
`TABLE 3
`
`
`Classification System Metadata
`Classification System Metadata (HIERARCHY)
`
`Name
`
`Type
`
`Description
`
`serializationMethod
`
`Int
`
`pathSeparator
`
`String
`
`Page 14 of 17
`
`
`
`Determines how to “serialize” a point in the hierarchy into a
`single string value. 0 = SIMPLE_CODE, 1 = CONCATENATE,
`2=CONCATENATE WITH LEAD SEP,
`3 = CONCATENATE_NO_SEP.
`With scrializationMecthod SIMPLE_CODE,the code of a
`pointin the hierarchy is serialized without any parent
`information (e.g., “dog”). With serializationMethod
`CONCATENATE,the point in the hierarchy is serialized with
`the codesofall ofits ancestors, left to right, oldest ancestor
`to youngest. The codes are separated with a pathSeparator
`string (e.g., “animal/mammal/dog”). ‘he serializationMethod
`CONCATENATE_WITH_LEAD_SEPis exactly like
`CONCATENATEwith a pathSeparatorstring pre-pended
`(e.g., “/animal/mammal/dog”). With serializationMethod
`CONCATENTE_NO_SEP,the pointin thehierarchyis
`serialize
`with the codesofall ofits ancestors, left to right,
`oldest ancestor to youngest(¢.g., “animalmammaldog”)
`Meaningful only if serializationMethod = CONCATENATEor
`CONCATENATE_WITH_LEAD_SEP.Thisis the string
`(string, not character) used to separate the nodes in the
`hierarchy from each other. Max length ofthis Stringis 3.
`
`
`
`Page 14 of 17
`
`

`

`US 2009/0055345 Al
`
`Feb. 26, 2009
`
`TABLE 4
`
`Classification System Metadata
`Classification System Mctadata (GROUPonly)
`A sequenceofat least 2 and at most 5 groupComponentlds
`
`Name
`
`Type
`
`Description
`
`groupComponentId
`
`String
`
`Identifies one of the classification systems
`that form part ofthis group. It can be the
`UDDIv3 tMcdel Key that represents that
`Classification System.
`
`[0029] Moreover, in some implementations, classification
`service 185 may be used to read and/or to write the content of
`the classification systems. Tables 5 and 6 depict an example
`structure for such reading and writing.
`
`classification systems defined in the classification service
`185. The method “getClassificationSystemValue” may be
`called to obtain classification value details like description,
`selectable, and the like. The method “getClassificationSys-
`temValues” may becalled to obtain the contents of a classi-
`fication system definedin the classification service 185. ‘The
`“createCassificationSystem” API may be used to create a new
`classification system. The “updateClassificationSystem” API
`may be used to modify an existing metadata of the classifi-
`cation system. The “saveClassificationSystemValues” API
`may be used to add new valuesor to modify existing valuesto
`a classification system of typeflat or hierarchy. The “save-
`ClassifcationSystemGroupValues” API may be used to add
`new values to a classification system of type group. The
`“deleteClassificationSystem” API may be used to delete a
`classification system andall ofits data. The “deleteClassifi-
`
`Name
`Code
`
`‘lype
`
`String
`
`Description
`Path
`
`String
`
`String[ ]
`
`Selectable
`
`Boolean
`
`
`
`TABLE 5
`
`Classification System Value
`Classification System Value
`
`Description
`
`This code, together with the path, uniquely identifies a point in
`the classification system. There is a length constraint for
`is field - no longer e.g. than 255 symbols.
`Description ofthis point in the classification system.
`Optional.
`A sequenceofstrings, each of which is the code of an
`ancestor of this point in the classification system. Orderis
`oldest ancestors to youngest ancestor. An absent or empty
`path elementsignifies that this code has no ancestors (i.e.
`classification system is flat, or codeis at Lop level of a
`hicrarchy). Zoro length strings in the sequence are
`permitted only in the case of a GROUP,to express
`classification that used only a subset ofthe group. There is
`a length constraint for this field - sum of length ofall strings
`plus length of all pathSeparators between them must be no more
`than 255 symbols
`f false, this point in the classification system may not be
`usedto classify data.
`
`TABLE 6
`
`Classification System Value for Groups
`Group Value
`
`Name
`
`Type
`
`Description
`
`Id
`
`String
`
`Value
`
`String
`
`A key whichidentifies one ofthe classification
`systems used in this group. Each id in the
`sequence mustbe different, and each id in
`the sequence mustbe in the set of IDs defined in
`the metadata of the group. Not every ID definedin the
`metadata need be present in the sequence(i.e. partial
`groups are supported).
`Values that represents a valid point in the classification
`system identified by the Id above.
`Forflat classification systems, this is simply the code.
`For hierarchy classification systems,this is the
`value produced accordingto the classfication
`systems serializationMethod.
`
`Insome implementations, classification service 185
`[0030]
`may becalled to access methods. For example, the method
`“getAllClassificationSystems” may be called at classification
`service to obtain metadataforall ofthe classification systems
`definedin classification service 185. The method “getClassi-
`ficationSystem”may be called to obtain metadata for specific
`
`cationSystemAllValues” API may be usedto delete all ofthe
`classification data ofthe classification system.
`[0031] UDDI may be modeled using standard approaches,
`such as tModels. However, these standard tModels may be
`augmented to include one or more of the following: which
`services are available in a system (e.g., landscape); which
`services are modeled; which models are implemented in a
`system; which services are configured and thus invoked: and
`where should the service endpoints of the web service be
`exposed? To support such augmentation, additional classifi-
`cations and modeling may be implemented using UDDI
`tModels including descriptions for category group, refer-
`ences to identify a group, constituent category systems, and
`thelike.
`
`FIGS. 4-8 depicts UDDI tModels representations
`[0032]
`consistent with the subject matter described herein. In par-
`ticular, the UDDI tModel mayalso include aspects to enable
`operation in an OASISopen standard recommendation envi-
`ronment where WSDLis used in a UDDIregistry. Moreover,
`the UDDI tModels of T'IGS. 4-8 may include additionalcat-
`egorizations as well as identifiers and documentation links to
`the UDDIentities. Moreover, the UDDI tModel of FIGS.4-8
`may include additional UDDI entities not specified by the
`OASIS standard to enable use with predefined classification
`
`Page 15 of 17
`
`Page 15 of 17
`
`

`

`US 2009/0055345 Al
`
`Feb. 26, 2009
`
`systems. For example, a UDDI tModel may be implemented
`to include category information identifying a physical sys-
`tem.
`
`example, specific groupings of datathat fall into the classifi-
`cation scheme defined bythe classification system(e.g., only
`showingregistry data representative ofthe “Oil Industry” and
`“Bulgaria” combination).
`FIG. 4 depicts various aspects of the tModel includ-
`[0033]
`[0036]
`Theclassification service 185 may be implemented
`ing an “overviewURL”as well as a categorybag including
`as a program or component,i.e., a smal] binary object(e.g., an
`types for specific services(e.g., “er-service” and “er-service-
`applet) or program that performs a specific function and is
`modeled”) and a keyed-reference group representation of a
`designed in such a way to operate easily with other compo-
`keyed-reference group for a specific physical system. More-
`nents and applications, such as a service, Web service, and/or
`over, a Keyed-reference group for a deployment unit is
`user interface 110. In some implementations, classification
`depicted as well. FIG. 4 may be used to publish the tModel to
`service 185 is implemented as a service (e.g., as part of SAP’s
`other entities. [IG. 5 depicts the addition of a “physical-
`Enterprise Services Framework) or a web service accessible
`system-reference,” which may be used to point to another
`by other applications through an intranet and/or the Internet.
`tModel representing a physical system. For example, the
`[0037]
`FIG. 9 depicts an example implementation of clas-
`physical system may represent an ABAP implementation.
`sification service 185 in an enterprise services registry 1000.
`The physical system information may be used to determine
`Specifically, the classification service 185 may be imple-
`whatservices are available at a physical system. FIG. 5 also
`mented as part of an Enterprise Services Registry, which may
`depicts the addition of an indentifierBag. FIG. 6 depicts how
`also include other aspects such as a UDDI V3 server, and a
`service end-points are modeled using the tModcel(sces c.g.,
`keywordsearchservice.
`“types=er-service”). FIG. 7 depicts a tModel for a physical
`system including a tModel name, a categoryBag with system
`[0038]
`FIG. 10 depicts a process for aclassification service.
`specific information, and an identifierBag. FIG. 8 depicts a
`At 1005, classification service 185 receives a request to
`tModel for a group classification including a group name and
`access a UDDIregistry fromuser interface 110. The request
`a calegoryBag.
`may be implemented as a message, such as a SOAP message.
`At 1010, classification service 185 may access metadata rep-
`the subject matter
`[0034]
`In some implementations,
`resenting a classification system. The accessed metadata
`described herein may enable searching the data in a UDDI
`(e.g., Tables 1-4 above) enables classification service 185 to
`registry by keyword. For example, keyword searching of
`provide registry data from registry 160 in accordance with a
`UDDI registry data may be implemented using a search
`predetermined classification system (e.g., a group, a hierar-
`engine to index UDDI registry data to enable keyword
`chy,oraflat format). At 1020, the registry data is provided by
`searches that return UDDIentity keys. The registry data,
`the classification system 185 to user interface 100 in a format
`indexed by the search engine, includes the web service’s
`consistent with the predetermined classification system.
`name, description, category data, and reference documenta-
`tion. The registry data may includelinks(e.g., URIs or URLs)
`[0039] The systems and methods disclosed herein may be
`to external documentation, which may be indexedas well. In
`embodied in various forms including, for example, a data
`one implementation,data is extracted from the UDDIregistry
`processor, such as a computer that also includes a database,
`using UDDI APIs. The extracted data is then provided to a
`digital electronic circuitry, firmware, software, or in combi-
`nations of them. Moreover,
`the above-noled features and
`search engine (e.g., an application that searches and/or cre-
`ates an index), where the extracted data is indexed for search-
`other aspects and principles of the present disclosed embodi-
`ing. Classification service 185 may include an API for key-
`ments may be implemented in various environments. Such
`word searches of the indexed