ebxml Registry And Repository Registry Services Proposal

Transcription

1 ebxml Registry And Repsitry Registry Services Prpsal Wrking Draft 10/2/ :35 PM This versin: RegistryServicesSpecificatin v0-8.dc Abstract This dcument is a draft prpsal whse purpse is t slicit additinal input and cnvey the current state f the ebxml Registry Service recmmendatins. This dcument defines the varius Registry Services as interactin prtcls and prcesses between an ebxml capable party and the ebxml Registry. It is assumed that all interactins between the party and the ebxml registry will be cnducted using ebxml Messaging Service Ntatinal Cnventins The key wrds "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this dcument are t be interpreted as described in Key Wrds fr Use in RFC s t Indicate Requirement Levels (RFC 2119) Status f this Dcument This dcument represents wrk in prgress upn which n reliance shuld be made. 20 Dcument Versin Histry Versin 0.1: Initial versin (nt released) Versin 0.2: Crrectins based n internal review (nt released) Versin 0.3: Added DcumentManager, Remved SchemaManager and PrcessManager Versin 0.4: Added supprt fr Querying the Registry. Added DTDs fr all dcuments currently defined RegistryServicesSpecificatin v0-8.dc 10/2/00 1

2 Versin 0.5: Majr changes based n feedback frm team review resulted in a cmplete rewrite frm previus versin. Replaced DcumentManager with ObjectManager and assciated name changes (e.g. DcumentInf replaced with ManagedObject). Factred ut infrmatin mdel aspects in separate dcument [3]. Added QueryManager. Remved TPA Manager. Changed terminlgy where relevant t better align with [2]. Changed Registrar t Registry, Registrant t RegistryClient. Cmpletely redid the DTD definitin based n Repsitry Infrmatin Mdel spec [3]. Versin 0.6: Changes based n issue lgged during review f v0.5. Versin 0.7: Changed RequestErrrRespnse with ebxmlerrr defined by draft TRP errr handling specificatin. Changed registerorganizatin t registerparty. Changes made t almst all DTDs with majr changes in the area f classificatin. This was due t simplificatins in classificatin mdel. DTDs nw allw fr multiple bject submissin with ptinal classificatins defined. The new DTDs als allw fr multiple bject apprval, deprecatin, and remval. Changed GetClassifiedObjectsRequest s that multiple classificatins may be specified. Versin 0.8: Changes based n review dated 9/29/2000. Changed managed bject t managed bject cntent. Prvided asynchrnus query supprt with methd additins t ObjectQueryManager and ObjectQueryManagerClient. RegistryServicesSpecificatin v0-8.dc 10/2/00 2

3 Table f Cntents 1 Intrductin Purpse and Scpe Gals Related ebxml Specificatins General Cnventins Guiding Principals Specificatin Structure Overview Rle f ebxml Registry Use Cases fr the Registry Services Business Dmain Wrkflw Use Cases Parties Register With Registry Schema Dcuments Are Submitted Business Prcess Dcuments Are Submitted TPA is Submitted Interfaces Implemented By Registry Service Interfaces Implemented By Clients f Registry Service Registratin Service Interpretatin f UML Diagrams Describing an ebxml Business Prcess UML Class Diagram UML Sequence Diagram Interpretatin f Btstrap Registratin Prcess Sequence Diagram Service Interfaces Defined The Actins Defined On Service Interfaces Requests Defined Fr Actin Requests Messages Defined Fr Request Respnses Defined Fr Request Exceptin Respnses Defined Fr Request Messages Defined Fr Requests and Respnses Registry Service Interface in TPA SPECIFICATION RegistryClient Service Interface in TPA SPECIFICATION Object Management Service Life Cycle f a Managed Object Object Attributes The Submit Objects Prtcl ManagedObject The Apprve Objects Request The Deprecate Objects Request The Remve Objects Request Object Query Management Service Design Gals Fr Object Query Management Supprt Brwse and Drill Dwn Query Supprt Get Rt Classificatin Ndes Request Get Classificatin Tree Request Get Classified Objects Request Ad Hc Query Supprt Keywrd Search Based Query Supprt...22 RegistryServicesSpecificatin v0-8.dc 10/2/00 3

4 Object Retrieval References Acknwledgments...23 Appendix A Schemas and DTD Definitins...24 A.1 RequestAcceptedRespnse Message DTD...25 A.2 ebxmlerrr Message DTD...25 A.3 ManagedObject DTD...26 A.4 RegisterPartyRequest Message DTD...27 A.5 SubmitObjectsRequest Message DTD...28 A.6 ApprveObjectsRequest Message DTD...29 A.7 DeprecateObjectsRequest Message DTD...29 A.8 RemveObjectsRequest Message DTD...29 A.9 ClassificatinNde DTD...30 A.10 GetRtClassificatinNdesRequest Message DTD...31 A.11 GetRtClassificatinNdesRespnse Message DTD...32 A.12 GetClassificatinTreeRequest Message DTD...32 A.13 GetClassificatinTreeRespnse Message DTD...32 A.14 GetClassifiedObjectsRequest Message DTD...32 A.15 GetClassifiedObjectsRespnse Message DTD...33 Appendix B TPA Between Registry Client And Registry...33 Appendix C Example XML fr Submitting a Classificatin Tree...33 Appendix D Terminlgy Mapping...34 Appendix E Open Issues Table f Figures Figure 1: Business Dmain Wrkflw Use Cases...8 Figure 2: Btstrap Registratin Prcess Sequence Diagram...12 Figure 3: Life Cycle f a Managed Object...16 Figure 4: Submit Objects Sequence Diagram...17 Figure 5: Apprve Objects Sequence Diagram...18 Figure 6: Deprecate Objects Sequence Diagram...18 Figure 7: Remve Objects Sequence Diagram...19 Figure 8: Get Rt Classificatin Ndes Sequence Diagram...20 Figure 9: Get Rt Classificatin Ndes Asynchrnus Sequence Diagram...21 Figure 10: Get Classificatin Tree Sequence Diagram...21 Figure 11: Get Classificatin Tree Asynchrnus Sequence Diagram...21 Figure 12: Get Classified Objects Sequence Diagram...22 Figure 13: Get Classified Objects Asynchrnus Sequence Diagram...22 RegistryServicesSpecificatin v0-8.dc 10/2/00 4

5 Table f Tables Table 1: Terminlgy Mapping Table Intrductin This dcument defines the ebxml Registry Services as a set f specialized business prcesses. Clients f the ebxml Registry are referred t as RegistryClients while the ebxml Registry itself is referred t as Registry. [Nte] Fr interperability reasns it is required that a Registry implementatin must supprt its service interfaces using the ebxml Messaging Service bindings defined in this dcument. A Registry implementatin is free t prvide any ther technlgy bindings (e.g. LDAP) as a nninterperable implementatin specific detail. All interactin between RegistryClients and the Registry are treated as if they are B2B interactins between trading partners. Thus the prcesses supprted by the Registry are described in terms f: A special TPA between the Registry and RegistryClient A set f business prcesses invlving the Registry and RegistryClient A set f business messages that are exchanged between the Registry and RegistryClient as part f a specific Registry business prcess Purpse and Scpe This dcument prvides sufficient detail t develp: The specified functinality f the ebxml Registry Services ebxml based applicatins that utilize the Registry Services functinality specified in this dcument Sftware practitiners MAY use this dcument in cmbinatin with ther ebxml specificatin dcuments when creating ebxml cmpliant sftware. NOTE: This versin describes nly sme f the Registry Services that are likely t be needed by the prpsed Tky POC scenaris. Several Registry Services identified in [2] are currently unspecified and will be added in a later versin. Sme f the missing functinality includes: Security (assuming it will be based upn the security specificatin that will be included in a future versin f ebxml Messaging Service Specificatin) Transfrmatin Service Wrkflw Service Quality Assurance Service. RegistryServicesSpecificatin v0-8.dc 10/2/00 5

6 Gals The gals f this versin f the specificatin are t: Cmmunicate functinality f registry services t sftware develpers Meet the immediate requirements f the Tky POC dem scenaris Able t evlve in future t supprt mre cmplete ebxml Registry and Repsitry requirements Be cmpatible with ther ebxml specificatins Related ebxml Specificatins The fllwing set f related specificatins may be f interest t the reader: a) Registry and Repsitry Part 1: Business Dmain Mdel [2] b) ebxml Repsitry Infrmatin Mdel [3] c) Messaging Service Specificatin [4] d) Business Prcess Meta Mdel Specificatin [5] e) Trading-Partner Specificatin [7] General Cnventins managed bject cntent is used t refer t actual repsitry cntent (nt meta data) instance (e.g. a DTD) ManagedObject is used t refer t an bject that prvides meta data abut cntent instance (managed bject cntent). The infrmatin mdel des nt cntain any elements that are the actual cntent f the repsitry (managed bject cntent). All elements f the infrmatin mdel represent meta data abut the cntent and nt the cntent itself. UML diagrams are used as a way t cncisely describe business prcesses, cllabratin and cncepts. They are nt intended t cnvey any specific implementatin requirements. The Registry Service prcesses are described as UML diagrams. The intent is t describe business prcesses in a cncise manner in terms f ebxml TRP. The reader must acquaint themselves with sectin 3.1 (abstract) and sectin 3.2 (cncrete example), in rder t understand these prcesses based n their UML descriptin Guiding Principals The fllwing principals guided the wrk represented by this dcument: Keep it simple while sufficient (KISS) All access t repsitry cntent is thrugh interactin with Registry Services Interactins between Registry Services and its client are a special case f partner-t-partner business prcess. In fact there is a TPA between clients and Registry Services Interactins between Registry Services and its client are based n ebxml TRP messaging RegistryServicesSpecificatin v0-8.dc 10/2/00 6

7 Specificatin Structure This specificatin is rganized arund the fllwing main tpics: Overview - A high level descriptin f the Registry Service Registratin Service- A descriptin f the initial registratin functinality that btstraps the cmmunicatin between a Party assciated with a Submitting Organizatin and the Registry Services. This sectin is imprtant t understand fully as it serves as a blueprint when reading subsequent sectins n hw t interpret UML representatin f the registry services interfaces. Object Management Service- A descriptin f the Object Management functinality f the ebxml Registry that simplifies the definitin and subsequent sharing f business bjects (e.g. dcuments) between partners. The types f bjects that may be shared are defined in [3] and include Schema dcuments (e.g. DTDs), Business Prcess descriptins (e.g. XMI dcuments and sftware cmpnents cmpliant t a registered business prcess), Party Prfiles and TPAs. Object Query Management Service- A descriptin f the Object Query Management functinality f the ebxml Registry that enables querying the repsitry fr managed bject cntents. RegistryServicesSpecificatin v0-8.dc 10/2/00 7

8 218 2 Overview Rle f ebxml Registry The ebxml Registry prvides a set f distributed services that enable sharing f infrmatin between interested parties fr the purpse f enabling business prcess integratin between such parties based n the ebxml specificatins. The shared infrmatin is maintained as bjects in an ebxml Repsitry [3] that is managed by the ebxml Registry Services defined in this dcument and its future versins. All access t the repsitry is expsed via the interfaces defined fr the Registry Services Use Cases fr the Registry Services This sectin describes at a high level sme use cases illustrating hw registry clients may make use f the registry Services t cnduct B2B exchanges. It is meant t be illustrative and nt prescriptive Business Dmain Wrkflw Use Cases Figure 1: shws the Business Dmain Wrkflw Use Cases as identified in [2] Figure 1: Business Dmain Wrkflw Use Cases RegistryServicesSpecificatin v0-8.dc 10/2/00 8

9 The fllwing scenari textually exemplifies a subset f abve use cases in terms f interactin between registry clients and the registry. It is currently nt a cmplete listing f use cases envisined in [2]. It assumes fr purpses f example, a buyer and a seller that wish t cnduct B2B exchanges using the Rsetta Net PIP3A4 Purchase Order business prtcl. It is assumed that bth buyer and seller use the same registry service prvided by a 3 rd party. Nte that the architecture supprts ther pssibilities (e.g. each party uses their wn private registry). It is assumed that the Registry Service is always peratinal fr the use cases described belw Parties Register With Registry Bth parties register with the Registry using the Registratin Service described in sectin Schema Dcuments Are Submitted Either the buyer r the seller r a registered 3 rd party can submit the necessary schema dcuments required by the Rsetta Net PIP3A4 Purchase Order business prtcl with the Registry using the Object Manager service f the Registry described in sectin Business Prcess Dcuments Are Submitted Either the buyer r the seller r a registered 3 rd party can submit the necessary business prcess dcuments required by the Rsetta Net PIP3A4 Purchase Order business prtcl with the Registry using the Object Manager service f the Registry described in sectin TPA is Submitted Either the buyer r the seller can nw create a cncrete TPA dcument that will be used by bth parties t cnduct B2B exchanges based n the Rsetta Net PIP3A4 Purchase Order business prtcl. This is dne using a TPA Assembler tl that is a client f the registry services and uses registry services t assemble a TPA frm submitted TPA elements. The resulting TPA is submitted t the Registry using the Object Manager service f the Registry described in sectin 4.3. Once the TPA is submitted the parties may nw begin t cnduct B2B transactin as defined by [4]. RegistryServicesSpecificatin v0-8.dc 10/2/00 9

10 Figure 2: Registry Services Class Diagram Figure 2: Registry Services Class Diagram shws an abstract class diagram fr the Registry Service. It is intended as a high level verview and des nt prescribe any particular implementatin. The Registry makes use f a Repsitry (nt shwn in diagram) fr string and retrieving persistent infrmatin required by the Registry Services Interfaces Implemented By Registry Service The ebxml Registry is shwn t implement the fllwing interfaces as its sub-services (Registry Services): 1. Registry: This is the principal btstrapping interface used by clients f Registry t register themselves as RegistryClients. RegistryServicesSpecificatin v0-8.dc 10/2/0010

11 ObjectManager: This is the Object Management interface f the Registry services. It prvides the functinality t manage the life cycle f any managed bject cntent in the repsitry. 3. ObjectQueryManager: This is the Object Query Management interface f the Registry services. It prvides the functinality t receive query requests and return managed bject cntents that match the specified query as a respnse Interfaces Implemented By Clients f Registry Service An ebxml applicatin that is a client f the Registry Service must implement the fllwing interfaces: 1. RegistryClient: This is the principal interface implemented by a client f the Registry Services. It is used by the Registry t cmmunicate with the ebxml registry client applicatin during the initial btstrapping registratin prcess. 2. ObjectManagerClient: This is the interface implemented by a client f the Object Management sub-service f the Registry Services. It is used by the ObjectManager t cmmunicate with the ebxml applicatin during the Object Management prcess. 3. ObjectQueryManagerClient: This is the interface implemented by a client f the Object Query sub-service f the Registry Services. It is used by the ObjectQueryManager t cmmunicate with the RegistryClient during the Object Query prcess Registratin Service In rder t submit r therwise change cntent, a RegistryClient must register itself as Party assciated with an Organizatin with the Registry. An Organizatin currently can have a rle f a SubmittingOrganizatin, RespnsibleOrganizatin r a RegistratinAuthrity as defined by [6].This is an essential btstrapping prcess that is required prir t any ther interactin between the RegistryClient and the Registry Service. [Nte] Clients that nly intend t brwse the repsitry cntent d nt have t register with the repsitry. Because there is n previusly established TPA between the Registry and the RegistryClient, the Registry must smehw make public at least ne well-knwn Transprt specific cmmunicatin address. It is recmmended that the registry at least make public a URL t its Registry Service Interface. This sectin describes the btstrapping Registratin Prtcl f the Registry Service that allws a client t register itself with the Registry. Since this is the first use f the stylized use f UML ntatin in this dcument, the diagram will be fllwed by its interpretatin. Future prcesses in the dcument will nly be described pictrially in the interest f brevity. RegistryServicesSpecificatin v0-8.dc 10/2/0011

12 Figure 2: Btstrap Registratin Prcess Sequence Diagram Interpretatin f UML Diagrams Describing an ebxml Business Prcess This sectin describes in abstract terms the cnventins used t define ebxml business prcess descriptin in UML UML Class Diagram A UML class diagram is used t describe the Service Interfaces and Actins (as defined by [7]) required t implement an ebxml business prcess. See Figure 2: Registry Services Class Diagram fr an example. The UML class diagram cntains: 1. A cllectin f UML classes where each class represents an ebxml dcument. Such class definitins, their attributes and their relatinships can be used t create schema elements by a schema assembler tl that is a RegistryClient. 2. A cllectin f UML interfaces where each interface represents a Service Interface. 3. A cllectin f methds n each interface where each methd represents an Actin (as defined by [7]) within the Service Interface representing the UML interface. 4. Each methd within a UML interface specifies ne r mre parameters, where the type f each methd argument represents the ebxml message type that is exchanged as part f the Actin crrespnding t the methd. Multiple arguments imply multiple paylad dcuments within the bdy f the crrespnding ebxml message UML Sequence Diagram A UML sequence diagram is used t specify the business prtcl representing the interactins between the UML interfaces fr an ebxml business prcess. A UML sequence diagram prvides the necessary infrmatin t determine the sequencing f messages, request t respnse assciatin as well as request t errr respnse assciatin as described by [7]. RegistryServicesSpecificatin v0-8.dc 10/2/0012

13 Each sequence diagram shws the sequence fr a specific cnversatin prtcl as methd calls frm the requestr t the respnder. Methd invcatin may be synchrnus r asynchrnus based n the UML ntatin used n the arrw-head fr the link. Each methd invcatin may be fllwed by a respnse methd invcatin frm the respnder t the requestr t indicate the RespnseName fr the previus Request. Pssible errr respnse is indicated by a cnditinal respnse methd invcatin frm the respnder t the requestr. See Figure 2 fr an example Interpretatin f Btstrap Registratin Prcess Sequence Diagram This sectin describes in cncrete terms the cnventins used t define ebxml business prcess descriptin in UML diagrams. It uses the Btstrap Registratin Prcess as a cncrete example. There is an implicit TPA between the Registry and the ebxml applicatin that is a client t the Registry services. This TPA defines the Btstrap Registratin Prcess shwn abve Service Interfaces Defined In the implicit TPA there are tw Business Interfaces which are represented by the UML interfaces in UML sequence diagram abve. The Registry must exprt a Service Interface called the Registry interface. The registry client must exprt a Service Interface called the RegistryClient interface The Actins Defined On Service Interfaces The Registry interface must supprt an actin named registerparty. The RegistryClient uses the registerparty actin f the Registry interface t register its Party and assciated Organizatin with the Registry. The RegistryClient interface must supprt the fllwing actins fr receiving respnses t requests made t the Registry: 1. A registerpartyaccepted actin that is used by Registry t ntify RegistryClient f successful registratin. This serves as a business level Acknwledgement Respnse t the register actin. 2. A registerpartyerrr actin that is used by Registry t ntify RegistryClient f a failure during registratin. This serves as an Errr Respnse t the register actin Requests Defined Fr Actin The Registry interface defines an actin with id f registerparty (crrespnding t the interface methd) Requests Messages Defined Fr Request The register actin has a request whse RequestName and RequestMessage are bth RegisterPartyRequest. This name is derived frm the actin name (with first letter capitalized) appended with the suffix Request Respnses Defined Fr Request Each Request message may have a Respnse message assciated with it. The RespnseName is inferred frm the sequence diagram frm the name f the methd called upn success f the Request methd invcatin. RegistryServicesSpecificatin v0-8.dc 10/2/0013

14 Mst Registry Requests in this dcument cnsistently use a standard business level acknwledgement respnse message f type RequestAcceptedRespnse Exceptin Respnses Defined Fr Request Each Request message may have ne r mre Exceptin Respnse messages assciated with it. The ExceptinRespnseName is inferred frm the sequence diagram frm the name f the methd called upn failure f the Request methd invcatin. Mst Registry Requests in this dcument cnsistently use the generic ebxmlerrr message defined by [8] as a business level errr respnse message Messages Defined Fr Requests and Respnses The type f ebxml message exchanged during each interactin (methd invcatin in diagram) can be inferred frm the type f argument fr each methd invcatin. The RegisterPartyRequest message must cntain either an Organizatin element that prvides infrmatin n the Organizatin being registered, r a ManagedObjectRef element that is a reference t a previusly defined Organizatin. Nte that is is pssible t have multiple Parties be assciated with the same Organizatin. The RegisterPartyRequest message must als cntain a Party Prfile element that describes the RegistryClient s half f the special TPA between the Registry and the RegistryClient. See Appendix AA.4 fr details Registry Service Interface in TPA SPECIFICATION The abve specificatin f the Registry service interface is expressed in TPA SPECIFICATION [7] as fllws 1 : <BusinessInterface> <ServiceInterface InterfaceId = "Registry"> <OrgName Partyname = "Registry">Registry</OrgName> <TaskName>RegisterPartyRequest</TaskName> <ActinMenu> <Actin id = "registerparty" Type = "basic" Invcatin = "asynconly"> <Request> <RequestName>RegisterPartyRequest</RequestName> <RequestMessage>RegisterPartyRequest</RequestMessage> </Request> <Respnse Required = "yes"> <RespnseName>RequestAcceptedRespnse</RespnseName> </Respnse> <ExceptinRespnse> <ExceptinRespnseName>ebXMLErrr </ExceptinRespnseName> </Respnse> </Actin> </ActinMenu> </ServiceInterface> </BusinessInterface> 1 It shuld be nted that this XML fragment is tentative since the exact grammar f the ebxml TPA has nt yet been defined. RegistryServicesSpecificatin v0-8.dc 10/2/0014

15 RegistryClient Service Interface in TPA SPECIFICATION The abve specificatin f the RegistryClient service interface is expressed in TPA SPECIFICATION [7] as fllws 2 : <BusinessInterface> <ServiceInterface InterfaceId = "RegistryClient"> <OrgName Partyname = "RegistryClient">RegistryClient</OrgName> <TaskName>RegisterPartyRespnse</TaskName> <ActinMenu> <Actin id = "registerpartyaccepted" Type = "basic" Invcatin = "asynconly"> <Request> <RequestName>RequestAcceptedRespnse</RequestName> <RequestMessage> RequestAcceptedRespnse </RequestMessage> </Request> <Respnse Required = "n"/> </Actin> <Actin id = "registerpartyerrr" Type = "basic" Invcatin = "asynconly"> <Request> <RequestName>ebXMLErrr</RequestName> <RequestMessage> ebxmlerrr</requestmessage> </Request> <Respnse Required = "n"/> </Actin> </ActinMenu> </ServiceInterface> </BusinessInterface> Object Management Service [Nte] The wrkflw envisined in [2] is nt addressed cmpletely in this versin. This chapter is a simplified sub-set f that wrkflw. This sectin defines the Object Management service f the Registry. The Object Management Service is a sub-service f the Registry service. It prvides the functinality required by RegistryClient s t manage the life cycle f managed bject cntents (e.g. dcuments) required fr ebxml business prcesses. The Object Management Service can be used with all types f managed bject cntents including the built-in managed bject cntents specified in [3] such as Classificatin and Assciatin. Once an ebxml client f the Registry Services has successfully been thrugh the Btstrapping Registratin Prcess, it is nw capable f using the Object Management services f the Registry Life Cycle f a Managed Object The main purpse f the Object Management service is t manage the life cycle f managed bject cntents in the repsitry. Figure 3 shws the typical life cycle f a managed bject cntent. 2 It shuld be nted that this XML fragment is tentative since the exact grammar f the ebxml TPA has nt yet been defined. RegistryServicesSpecificatin v0-8.dc 10/2/0015

16 Figure 3: Life Cycle f a Managed Object Object Attributes A managed bject cntent is assciated with a set f standard meta-data defined as attributes f the ManagedObject class described in [3]. These attributes reside utside f the actual bject cntent and prvide valuable meta-data abut the managed bject cntent. An XML schema element called ManagedObject (See Appendix AA.3 fr details.) is defined that encapsulates all bject meta-data attributes defined in [3] as attributes f the schema element The Submit Objects Prtcl This sectin describes the prtcl f the Registry Service that allws a RegistryClient t submit ne r mre managed bject cntents in the repsitry using the Object Manager n behalf f a Submitting Organizatin. It is expressed in UML ntatin as described in sectin 3.1. RegistryServicesSpecificatin v0-8.dc 10/2/0016

17 Figure 4: Submit Objects Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t Appendix AA ManagedObject The SubmitObjectRequest message includes a ManagedObject element which identifies the Submitting Party. It als includes 1 r mre SubmittedObject elements. Each SubmittedObject element specifies a ManagedObject element which prvides standard meta-data abut the bject being submitted t the repsitry as defined by [3]. Nte that these standard ManagedObject attributes are separate frm the managed bject cntent itself, thus allwing the ebxml Repsitry t catalg arbitrary bjects. In additin each SubmittedObject in the request may ptinally specify any number f Classificatins r Assciatins fr the SubmittedObject. In summary each managed bject cntent in the Repsitry is assciated with a standard set f meta-data attributes cllectively described by a ManagedObject element in XML. A simple URI reference t a ManagedObject is represented in XML as a ManagedObjectRef element The Apprve Objects Request This sectin describes the prtcl f the Registry Service that allws a client t apprve ne r mre previusly submitted managed bject cntents using the Object Manager. Once a managed bject cntent is apprved it will becme available fr use by business parties (e.g. during the assembly f new TPAs and Party Prfiles). It is expressed in UML ntatin as described in sectin 3.1. RegistryServicesSpecificatin v0-8.dc 10/2/0017

18 Figure 5: Apprve Objects Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t Appendix AA The Deprecate Objects Request This sectin describes the prtcl f the Registry Service that allws a client t deprecate ne r mre previusly submitted managed bject cntent using the Object Manager. Once an bject is deprecated, n new assciatins t that bject can be submitted. In effect the managed bject cntent is marked as remved r deleted. Hwever, existing references t a deprecated managed bject cntent cntinue t functin nrmally. The deprecate bject prtcl is expressed in UML ntatin as described in sectin Figure 6: Deprecate Objects Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t Appendix AA.7. RegistryServicesSpecificatin v0-8.dc 10/2/0018

19 The Remve Objects Request This sectin describes the prtcl f the Registry Service that allws a client t remve ne r mre previusly deprecated managed bject cntents using the Object Manager. An bject cannt be remved as lng as there exists 1 r mre bjects with assciatins t that bject. Once an bject is remved it will be nt be present at all in the Registry. The remve bject prtcl is expressed in UML ntatin as described in sectin Figure 7: Remve Objects Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t Appendix AA Object Query Management Service This sectin describes the capabilities f the Registry Service that allws a client (ObjectQueryManagerClient) t search fr (query) managed bject cntents in the ebxml Repsitry using the ObjectQueryManager interface f the Registry. Due t the synchrnus nature f queries all interactins between the ObjectQueryManagerClient and the ObjectQueryManager are synchrnus in nature as reflected in the UML sequence diagrams that fllw. Any errrs in the query request messages are indicated in the crrespnding query respnse message Design Gals Fr Object Query Management Supprt The fllwing gal mtivated the design f Object Query Management service: 1. Make it simple fr Registry clients t query the registry fr managed bject cntents 2. D nt invent a new query language (a very large wheel t reinvent) 3. Make it simple fr Registry prviders t implement the Repsitry using a relatinal database 4. Supprt all query mechanisms described in [3] RegistryServicesSpecificatin v0-8.dc 10/2/0019

20 Leverage security mechanism that will be specified in ebxml TRP rather than inventing a different mdel fr the Registry Brwse and Drill Dwn Query Supprt The brwse and drill drwn query style is cmpletely supprted by a set f primitive interactins between the ObjectQueryManagerClient and the ObjectQueryManager as described next. Nte that fr each query request/respnse there is bth a synchrnus and asynchrnus versin f the interactin. [Nte] Fr the Tky POC it is nly required that the asynchrnus queries must be supprted by registry client and registry services Get Rt Classificatin Ndes Request An ObjectQueryManagerClient send this request t get a list f rt ClassificatinNdes (ndes with n parent) defined in the repsitry. Nte that it is pssible t specify a namepattern attribute that can filter n the name attribute f the rt ClassificatinNdes using a wildcard pattern defined by SQL-92 LIKE clause. It is expressed in UML ntatin as described in sectin Figure 8: Get Rt Classificatin Ndes Sequence Diagram 546 RegistryServicesSpecificatin v0-8.dc 10/2/0020

21 Figure 9: Get Rt Classificatin Ndes Asynchrnus Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t A.10 and A Get Classificatin Tree Request An ObjectQueryManagerClient send this request t get the ClassificatinNde sub-tree defined in the repsitry under the ClassificatinNde specified in the request. Nte that a GetClassificatinTreeRequest can specify an integer attribute called depth t get the sub-tree upt the specified depth. If depth is 1 (default) then nly the immediate children f the specified ClassificatinItemRef are returned. If depth is 0 then the entire sub-tree is retrieved. It is expressed in UML ntatin as described in sectin Figure 10: Get Classificatin Tree Sequence Diagram Figure 11: Get Classificatin Tree Asynchrnus Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t A.12 and A.13. RegistryServicesSpecificatin v0-8.dc 10/2/0021

22 Get Classified Objects Request An ObjectQueryManagerClient send this request t get a list f references t managed bject cntents defined in the repsitry that are classified by the specified ClassificatinNdes in the ManagedObjectRefList in the request. Nte that it is pssible t get managed bject cntents based n matches with multiple classificatins. It is expressed in UML ntatin as described in sectin Figure 12: Get Classified Objects Sequence Diagram Figure 13: Get Classified Objects Asynchrnus Sequence Diagram Fr details n the schema fr the business dcuments shwn in this prcess refer t A.14 and A Ad Hc Query Supprt Details will be specified pst Tky Keywrd Search Based Query Supprt The Registry prvides a search engine functinality t search fr managed bject cntents that cntain specified keywrds in their cntent r attributes. Details will be specified pst Tky. RegistryServicesSpecificatin v0-8.dc 10/2/0022

23 Object Retrieval The respnse messages that is returned by ObjectQueryManager cntain zer r mre ManagedObjectRef elements, ne fr each bject that matched the query. Each ManagedObjectRef element cntains a URI fr the bject matching the query in the repsitry. The client can use the URI t retrieve the bject. Nte that security issues will be addressed by ebxml TRP security mechanisms that are utside the scpe f this dcument References [1] ebxml Glssary, see [2] Registry and Repsitry Part 1: Business Dmain Mdel [3] ebxml Repsitry Infrmatin Mdel [4] ebxml Messaging Service Specificatin, Versin 0.21, [5] ebxml Business Prcess Meta-mdel [6] ebxml Cre Cmpnents Meta-mdel (unable t find reference despite best attempt) [7] Trading-Partner Specificatin [8] ebxml TRP Errr Handling Specificatin Acknwledgments The members f the Registry and Repsitry team wish t acknwledge the supprt f the members f the varius ebxml wrking grups wh have cntributed ideas and suggestins fr this prpsal. RegistryServicesSpecificatin v0-8.dc 10/2/0023

24 Appendix A Schemas and DTD Definitins The fllwing are definitins fr the varius ebxml Message paylads described in this dcument. [Nte] The DTDs fr messages shuld be cnsidered as wrks-in-prgress. They are pen t change based n cllabratin with and input frm the team and varius ther wrking grups. [Nte] Several DTDs use a cmmn biler plate DTD ManagedObject.dtd that must be read in rder t understand the main DTD. This cmmn DTD is defined in Appendix AA.3 RegistryServicesSpecificatin v0-8.dc 10/2/0024

25 A.1 RequestAcceptedRespnse Message DTD <!ELEMENT RequestAcceptedRespnse EMPTY> <!ATTLIST RequestAcceptedRespnse xml:lang NMTOKEN #REQUIRED interfaceid CDATA #REQUIRED requestmessage CDATA #REQUIRED actinid CDATA #REQUIRED > <!ENTITY % interfaceid ""> A.2 ebxmlerrr Message DTD <!ELEMENT ebxmlerrr (ErrrHeader, ErrrLcatin* )> <!ATTLIST ebxmlerrr xml:lang NMTOKEN #REQUIRED > <!ELEMENT ErrrHeader (Severity, ErrrCde, ErrrDesc?, MinRetrySecs? )> <!ATTLIST ErrrHeader ID NMTOKEN #REQUIRED > <!ELEMENT Severity (#PCDATA )> Either Warning, TransientErrr r HardErrr <!ELEMENT ErrrCde (#PCDATA )> string max 14 char <!ELEMENT ErrrDesc (#PCDATA )> string max 256 (?) char <!ELEMENT MinRetrySecs (#PCDATA )> An integer <!ELEMENT SwVendrErrrRef (#PCDATA )> string max 256 (?) chars <!ELEMENT ErrrLcatin (RefTMessageId?, (Href XMLDcumentErrrLcn ) )> <!ATTLIST ErrrLcatin ID NMTOKEN #REQUIRED > <!ELEMENT RefTMessageId (#PCDATA )> <!ELEMENT Href (#PCDATA )> <!ELEMENT XMLDcumentErrrLcn (DcumentId, Xpath )> <!ELEMENT DcumentId (#PCDATA )> <!ELEMENT Xpath (#PCDATA )> RegistryServicesSpecificatin v0-8.dc 10/2/0025

26 A.3 ManagedObject DTD <!ENTITY % ebxmlerrr SYSTEM "ebxmlerrr.dtd"> Pulls in the mdule at this spt in my DTD: %ebxmlerrr; <!ELEMENT ManagedObject EMPTY> The fllwing are standard dcument attributes that prvide meta-data abut the dcument. These are based n the ebxml Repsitry Infrmatin Mdel specificatin: <!ATTLIST ManagedObject guid CDATA #REQUIRED> <!ATTLIST ManagedObject uri CDATA #REQUIRED> <!ATTLIST ManagedObject type (UserDefined Schema Prcess PartyPrfile ServiceInterface BusinessService Rle Transprt Assciatin ClassificatinNde Classificatin ) #REQUIRED> <!ATTLIST ManagedObject name CDATA #REQUIRED> <!ATTLIST ManagedObject descriptin CDATA #IMPLIED> <!ATTLIST ManagedObject mimetype CDATA #IMPLIED> <!ATTLIST ManagedObject majrversin CDATA "0"> <!ATTLIST ManagedObject minrversin CDATA "1"> <!ATTLIST ManagedObject registrystatus (Submitted Apprved Deplyed Deprecated ) "Submitted"> <!ELEMENT ManagedObjectRef EMPTY> <!ATTLIST ManagedObjectRef guid CDATA #REQUIRED uri CDATA #IMPLIED name CDATA #IMPLIED > <!ELEMENT ManagedObjectRefList (ManagedObjectRef )*> <!ELEMENT ExternalObject EMPTY> <!ATTLIST ExternalObject guid CDATA #REQUIRED uri CDATA #IMPLIED descriptin CDATA #IMPLIED > <!ELEMENT ExternalObjectList (ExternalObject )*> RegistryServicesSpecificatin v0-8.dc 10/2/0026

27 A Classificatin specifies references t tw previusly submitted managed bject cntents. The first ManagedObjectRef is ref t a ManagedObject being classified The secnd ManagedObjectRef is a ref t ClassificatinNde The first ManagedObjectRef is ptinal when Classificatin is defined part f a SubmittedObject. <!ELEMENT Classificatin (ManagedObjectRef?, ManagedObjectRef )> <!ELEMENT ClassificatinList (Classificatin )*> A Classificatin specifies references t tw previusly submitted managed bject cntents. The first ManagedObjectRef is ref t the "frm" ManagedObject in assciatin The first ManagedObjectRef is ref t the "t" ManagedObject in assciatin The first ManagedObjectRef is ptinal when Classificatin is defined part f a SubmittedObject. <!ELEMENT Assciatin (ManagedObjectRef?, ManagedObjectRef )> <!ATTLIST Assciatin frmlabel CDATA #IMPLIED tlabel CDATA #IMPLIED type CDATA #IMPLIED bidirectin CDATA #IMPLIED > <!ELEMENT AssciatinList (Assciatin )*> A.4 RegisterPartyRequest Message DTD The RegisterPartyRequest Message includes a Party Prfile specified by a TPA element, which cnfrms t the DTD specified fr TPA SPECIFICATION in [7]. RegistryServicesSpecificatin v0-8.dc 10/2/0027

28 Pulls in the mdule at this spt in my DTD: <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> %managedobject; <!ENTITY % tpa SYSTEM "tpa_1_0_6.dtd"> %tpa; The Organizatin element needs t be defined by CC team. Fr nw this is a place hlder. <!ELEMENT Organizatin EMPTY> The party must be assciated with an Organizatin. The Organizatin may be defined in the request r may refer t a previusly defined Organizatin referred t by ManagedObjectRef. The party must prvide a PartyPrfile which currently is represented by a TPA. TP team needs t define PartyPrfile pst Tky. <!ELEMENT RegisterPartyRequest ( (Organizatin ManagedObjectRef ), TPA )> A.5 SubmitObjectsRequest Message DTD <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> Pulls in the mdule at this spt in my DTD: %managedobject; The ManagedObjectRef must be a ref t a previusly registered Party which is the Submitting party The SubmittedObject prvides meta data fr submitted bject Nte bject being submitted is in a separate dcument that is nt in this DTD. <!ELEMENT SubmitObjectsRequest (ManagedObjectRef, SubmittedObject+ )> The ManagedObject prvides meta data abut the bject being submitted ClassificatinList can be ptinaly be specified t define Classificatins fr the SubmittedObject AssciatinList can be ptinaly be specified t define Assciatins fr the SubmittedObject The ExternalObjectList prvides zer r mre external bjects related t RegistryServicesSpecificatin v0-8.dc 10/2/0028

29 the bject being submitted. <!ELEMENT SubmittedObject (ManagedObject, ClassificatinList?, AssciatinList?, ExternalObjectList? )> A.6 ApprveObjectsRequest Message DTD <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> Pulls in the mdule at this spt in my DTD: %managedobject; The ManagedObjectRef is t a previusly registered Party which is the apprving party. The ManagedObjectRefList is the list f refs t the managed bject cntents being apprved. <!ELEMENT ApprveObjectsRequest (ManagedObjectRef, ManagedObjectRefList )> A.7 DeprecateObjectsRequest Message DTD <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> Pulls in the mdule at this spt in my DTD: %managedobject; The ManagedObjectRef is t a previusly registered Party which is the deprecating party. The ManagedObjectRefList is the list f refs t the managed bject cntents being deprecated. <!ELEMENT DeprecateObjectsRequest (ManagedObjectRef, ManagedObjectRefList )> A.8 RemveObjectsRequest Message DTD <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> Pulls in the mdule at this spt in my DTD: %managedobject; The ManagedObjectRef is t a previusly registered Party which is the remving party. The ManagedObjectRefList is the list f refs t the managed bject cntents being remved RegistryServicesSpecificatin v0-8.dc 10/2/0029

30 <!ELEMENT RemveObjectsRequest (ManagedObjectRef, ManagedObjectRefList )> A.9 ClassificatinNde DTD This DTD is used t submit ClassificatinNdes. It is capable f submitting a single nde r an entire sub-tree. RegistryServicesSpecificatin v0-8.dc 10/2/0030

31 <!ENTITY % managedobject SYSTEM "ManagedObject.dtd"> Pulls in the mdule at this spt in my DTD: %managedobject; ClassificatinNde is used t submit a Classificatin tree t the Registry. Nte that this is a recursive schema definitin. The parent attribute f a nde in tree is implied by the enclsing ClassificatinNde The children ndes f a nde are implied by enclsing immediate child elements f type ClassificatinNde. <!ELEMENT ClassificatinNde (ClassificatinNde* )> The name f the ClassificatinNde. Maps t the name attribute f the ManagedObject meta data class. <!ATTLIST ClassificatinNde name CDATA #REQUIRED> ClassificatinNdeRef is used by the ObjectQueryManager fr varius query respnses. It represents a tree f ClassificatinNdeRef. <!ELEMENT ClassificatinNdeRef (ManagedObjectRef, ClassificatinNdeRef* )> ClassificatinNdeRefList is used t send a list f ClassificatinNdeRef when returning immediate children ndes f a nde. <!ELEMENT ClassificatinNdeRefList (ClassificatinNdeRef )*> A.10 GetRtClassificatinNdesRequest Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; The query request that gets the specified rt ClassificatinNdes <!ELEMENT GetRtClassificatinNdesRequest EMPTY> The namepattern fllws SQL-92 syntax fr the pattern specified in LIKE clause. It allws fr selecting nly thse rt ndes that match the namepattern. The default value f '*' matches all rt ndes. <!ATTLIST GetRtClassificatinNdesRequest namepattern CDATA '*' > RegistryServicesSpecificatin v0-8.dc 10/2/0031

32 A.11 GetRtClassificatinNdesRespnse Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; The respnse includes a ManagedObjectRefList which has zer r mre references t ManagedObjects that represent ClassificatinSchemeRefs <!ELEMENT GetRtClassificatinNdesRespnse (ManagedObjectRefList ebxmlerrr )> A.12 GetClassificatinTreeRequest Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; Get the ClassificatinItemTreeRef under the ClassificatinItemRef specified by ManagedObjectRef. <!ELEMENT GetClassificatinTreeRequest (ManagedObjectRef )> If depth is 1 just fetch immediate child ndes, therwise fetch the descendant tree upt specified depth level. If depth is 0 that implies fetch entire sub-tree <!ATTLIST GetClassificatinTreeRequest depth CDATA '1' > A.13 GetClassificatinTreeRespnse Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; The respnse includes a ClassificatinNdeRefList which includes nly immediate ClassificatinNdeRef children ndes if depth attribute in GetClassificatinTreeRequest was 1, therwise the decendent ndes upt specifed depth level are returned. <!ELEMENT GetClassificatinTreeRespnse (ClassificatinNdeRefList ebxmlerrr )> A.14 GetClassifiedObjectsRequest Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; Get refs t all managed bject cntents that are classified by all the ClassificatinNdeRef specified by ManagedObjectRefList. RegistryServicesSpecificatin v0-8.dc 10/2/0032

33 Nte this is an implicit lgical AND peratin <!ELEMENT GetClassifiedObjectsRequest (ManagedObjectRefList )> bjecttype attribute can specify the type f bjects that the registry client is interested in, that is classified by this ClassificatinNde. It is a String that matches a chice in the type attribute f ManagedObject. The default value f '*' implies that client is interested in all types f managed bject cntents that are classified by the specified ClassificatinNde. <!ATTLIST GetClassifiedObjectsRequest bjecttype CDATA "*"> A.15 GetClassifiedObjectsRespnse Message DTD <!ENTITY % classificatinnde SYSTEM "ClassificatinNde.dtd"> %classificatinnde; The respnse includes a ManagedObjectRefList which has zer r mre references t ManagedObjects that are classified by the ClassificatinNdeRef specified in the GetClassifiedObjectsRequest. <!ELEMENT GetClassifiedObjectsRespnse (ManagedObjectRefList ebxmlerrr )> Appendix B TPA Between Registry Client And Registry Appendix C Example XML fr Submitting a Classificatin Tree The fllwing XML message submits the classificatin tree fr the classificatin tree example in [3]. <?xml versin = "1.0"?> <!DOCTYPE ClassificatinNde SYSTEM "ClassificatinNde.dtd"> This is a sample XML that is used t submit a Classificatin tree t the Registry. Nte that this is a recursive schema definitin. The parent attribute f a nde in tree is implied by the enclsing ClassificatinNde The children ndes f a nde are implied by enclsing immediate child elements f type ClassificatinNde. <ClassificatinNde name = "Industry"> <ClassificatinNde name = "Autmtive"> <ClassificatinNde name = "Gegraphy"> <ClassificatinNde name = "US"/> <ClassificatinNde name = "Eurpe"/> RegistryServicesSpecificatin v0-8.dc 10/2/0033