Chapter 18 - Service Conﬁguration in the IMS

Chia sẻ: Nguyễn Văn Chiến | Ngày: | Loại File: PDF | Số trang:15

Thêm vào BST

Báo xấu

84
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Chapter 17 provided a description of the protocols at the user’s disposal for conﬁguring services on the Internet. We saw that the service conﬁguration architecture assumes an XML document stored on a server. The client retrieves a copy of the XML document, makes changes to it, and sends the delta back to the server. In IMS, the architecture for service conﬁguration architecture is developed around the XML Document Management (XDM) architecture created by the Open Mobile Alliance (OMA) in the XDM [244] set of speciﬁcations. ...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chapter 18 - Service Conﬁguration in the IMS

Chapter 18 Service Conﬁguration in the IMS Chapter 17 provided a description of the protocols at the user’s disposal for conﬁguring services on the Internet. We saw that the service conﬁguration architecture assumes an XML document stored on a server. The client retrieves a copy of the XML document, makes changes to it, and sends the delta back to the server. In IMS, the architecture for service conﬁguration architecture is developed around the XML Document Management (XDM) architecture created by the Open Mobile Alliance (OMA) in the XDM [244] set of speciﬁcations. XDM allows a user to modify XML documents stored in remote network servers. It also allows the local copy of those XML documents in the IMS terminal to be synchronized with the copy stored in network servers, so that if the user makes changes to one XML document from a given IMS terminal, other terminals are updated with the latest changes. Last, the XDM architecture also provides limited support for searches of information stored in these XML documents. 18.1 XDM architecture Let us describe the XDM architecture with the help of Figure 18.1. The XDM architecture assumes a terminal that implements the role of an XCAP client, and one or more servers, called XDM servers, that implement the role of XCAP servers. XML documents are stored in any of the servers and kept synchronized with the copy in the client. When a user wants to change a conﬁguration setting in a service, such as adding a friend to a presence list, the user changes the local copy of the XML document in the client and sends the change to the server, which applies it, and stores an updated version of the XML conﬁguration document. The XDM architecture introduces the following concepts. XDM client (XDMC). This is an XCAP client running in the IMS terminal. The XDMC implements the core XDM features and some application-speciﬁc features. Aggregation proxy. This is an HTTP proxy that is conﬁgured as an HTTP reverse proxy. The Aggregation Proxy authenticates the XDMC towards an XDMS. It may also route XCAP requests towards an XDMS or towards an Aggregation Proxy located in remote network. It also routes search requests towards the Search proxy. When receiving responses, it can compress the body of the response. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı © 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 390 Figure 18.1: XDM architecture Search proxy. This is an HTTP proxy that processes search requests received from XDMCs towards XDMSs or remote Aggregation Proxies. On received responses, the Search proxy combines the results of the responses received from XDMSs and remote Aggregation Proxies before forwarding them to the XDMC. Shared XDM servers. XDM servers (XMDSs) that are used by several applications. Shared XDMSs are effectively XCAP servers. There are specialized shared XDMSs: shared list XDMS, shared group XDMS, shared proﬁle XDMS, and shared policy XDMS. XDMSs. This is an application-speciﬁc server for service conﬁguration purposes. Effec- tively, XDMSs are XCAP servers that serve a single application. Most of the interfaces of the XDM architecture are implemented with XCAP. This is the case of the interfaces XDM-3, XDM-4, XDM-8. However, interfaces XDM-1 and XDM-2 are used for subscription to changes in XML documents, based on the XCAP event package for SIP. Consequently, XDM-1 and XDM-2 are SIP interfaces. Interfaces XDM-5, XDM-6, XDM- 7, and XDM-9 implement the Limited XQuery over HTTP protocol. Unnamed interfaces in Figure 18.1 are deﬁned by their respective applications, but they typically consist of XCAP, SIP for subscriptions to XCAP event packages, and Limited XQuery over HTTP. The XDM architecture considers different applications that can be customers of the XDM service (or enabler, as it is called by the OMA). For example, the presence service is a customer of XDM, because the list of watchers, the authorization policies, etc., are all stored in XML documents managed by XDM. Other services that use XDM include Push-to-talk
18.2. DOWNLOADING AN XML DOCUMENT, ATTRIBUTE, OR ELEMENT 391 over Cellular and PSTN/ISDN simulation services. Owing to this diversity of customers of XDM, the XDM architecture considers the existence of different XDM servers, each one perhaps specialized in serving a given application. An XDMS is a logical representation of the service conﬁguration aspects of a service or application. In real products, it is expected that XDM servers are integrated into the speciﬁc server (e.g., presence server, PoC server, etc.). Similarly, XDMCs are not really new entities, but just the logical representation of an XDM client in an IMS terminal. 18.2 Downloading an XML Document, Attribute, or Element When an XDMC wants to receive an XML document, or a part of it, e.g., an attribute or element, it invokes the HTTP GET request in XCAP. The basic HTTP GET operation according to the XDM architecture is shown with the help of Figure 18.2. The XDMC sends an HTTP GET request (1) to the Aggregation Proxy. It is assumed that the address of the Aggregation Proxy is pre-provisioned in the IMS terminal. An example of this HTTP GET request (1) is shown in Figure 18.3. The Request-URI is set to the part of the XCAP URI that is identiﬁed in HTTP, thus, excluding the host name. Of relevance in the HTTP GET request is the inclusion of an X-3GPP-Intended-Identity header ﬁeld that is populated with the identity that the user wants to present to the Aggregation Proxy. The HTTP X-3GPP-Intended-Identity header ﬁeld is speciﬁed in 3GPP TS 24.109 [9] and contains a SIP Public User Identity of the user. This Public User Identity is also present as a username in the XCAP URI of the GET request. Figure 18.2: XDM: basic GET operation GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1 Host: xdm.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 04 Mar 2008 22:10:45 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Accept-Encoding: gzip Figure 18.3: HTTP GET request (1)
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 392 The Aggregation Proxy ﬁrst needs to authenticate the user. There are several approaches to authenticate a user. One of them consist of using the Generic Authentication Architecture (GAA, speciﬁed in 3GPP TS 33.222 [15]). Essentially, GAA uses HTTP over TLS (speciﬁed in RFC 4346 [121]), for security purposes, and then either a certiﬁcate in the client or a share password. So, if GAA is used, all of the authentication takes place at the TLS level and not at the HTTP level. However, Figure 18.2 shows another authentication mechanism based on HTTP Digest Authentication (speciﬁed in RFC 2617 [145]). The Aggregation Proxy receives an HTTP GET request (1) and issues a 401 (Unauthorized) response (2) that contains a challenge in the WWW-Authenticate header ﬁeld. As a minimum, the challenge contains the realm where the user will be authenticated, and a nonce, which is a random value that prevents against replay attacks. An example of this 401 (Unauthorized) response is shown in Figure 18.4. HTTP/1.1 401 Unauthorized Server: XDM-proxy/OMA2.0 Date: Thu, 04 Mar 2008 22:10:46 GMT WWW-Authenticate: Digest realm="home1.com", qop=auth-int, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" Content-Length: 0 Figure 18.4: HTTP 401 (Unauthorized) response (2) The IMS terminal receives the 401 (Unauthorized) response (2), extracts the challenge, computes the response to that challenge (considering the username, realm, password, and nonce), and generates a second HTTP GET request (3) that contains that response to the challenge in the Authorization header ﬁeld. An example of this HTTP GET request (3) is shown in Figure 18.5. GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1 Host: xdm.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 04 Mar 2008 22:10:49 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", username="sip:alice@home1.com", nc=00000001, uri="/resource-lists/users/sip:alice@home1.com/index", response="2c8ee200cec7f6e966c932a9242554e4", cnonce="3bb96fe6e98a02ccb4555609c1b1bb56" Figure 18.5: HTTP GET request (3) The Aggregation Proxy, upon receiving of this new HTTP GET request (3) that contains the credentials, ﬁrst evaluates the response to the presented challenge and computes if it matches the response provided by the XDMC. If the response to the challenge is correct, then it removes the Authorization header ﬁeld and continues processing the request. The Aggregation Proxy adds its own Via header ﬁeld, and preserves the X-3GPP-Intended-Identity header ﬁeld. Then it inspects the Request-URI, determines,
18.3. DIRECTORY RETRIEVAL 393 based on the Application Unique ID (AUID), the actual server that is responsible for serving the request, and forwards the HTTP GET request (4) to that server. In the example, the AUID is set to resource-list; the Shared List XDMS is responsible for that application, thus is the recipient of the HTTP GET request (4). An example of the forwarded request is shown in Figure 18.6. GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1 Host: xdm.home1.com Via: HTTP/1.1 proxy.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 04 Mar 2008 22:10:50 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Figure 18.6: HTTP GET request (4) The Shared List XDMS then provides the requested XML document, element, or attribute in a 200 (OK) response (5), and forwards the response back to the Aggregation Proxy. An example of this response is shown in Figure 18.7. HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Date: Thu, 04 Mar 2008 22:10:50 GMT Etag: "asd92d092" Content-Type: application/resource-lists+xml Content-Length: 238
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 394 HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Via: HTTP/1.1 proxy.home1.com Date: Thu, 04 Mar 2008 22:10:51 GMT Etag: "asd92d092" Authentication-Info: nextnonce="2a219bcb2ad25ae32cbe280c249f" Content-Encoding: gzip Content-Type: application/resource-lists+xml Content-Length: 159 [binary compressed data] Figure 18.8: 200 (OK) response (6) this type of operation. The mechanism is brieﬂy described in Figure 18.9, which for the sake of brevity shows only two shared XDMSs. Figure 18.9: Directory retrieval with XDM According to Figure 18.9, when the XDMC wants to obtain a directory retrieval for one or more applications, the XDMC sends an HTTP GET request (1) to its Aggregation Proxy. Figure 18.9 assumes that the user is in possession of the next nonce value, obtained in a previous HTTP operation, so the XDMC can compose a response to a challenge to authenticate towards the Aggregation Proxy. An example of this HTTP request (1) is shown in Figure 18.10. What makes the HTTP GET request (1) in Figure 18.10 different, so that it is interpreted as a directory retrieval operation? The Request-URI, which partially contains the URI of the resource, is the key. The Request-URI contains a special AUID called “org.openmobilealliance.xcap-directory”, which indicates the directory retrieval operation. In addition, the Request-URI refers to a special document called “directory.xml” which is available under the user’s tree. The OMA deﬁnes the structure of the XML document “directory.xml” in the XDM speciﬁcation [245]. The Aggregation Proxy, once it has veriﬁed the identity of the user, forwards the GET request (2, 3) to each of the XDMSs. Then, each XDMS returns a 200 (OK) response (4, 5) that contains a “directory.xml” document that lists all of the XML documents belonging to that user and stored in that server for that application usage. An example of one of the
18.3. DIRECTORY RETRIEVAL 395 GET /org.openmobilealliance.xcap-directory/users/sip:alice@home1.com /directory.xml HTTP/1.1 Host: xdm.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 05 Mar 2008 22:10:49 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="102b98b7102dd2f0e8b11d0f600bfb0c789", username="sip:alice@home1.com", nc=00000002, uri="/org.openmobilealliance.xcap-directory/users /sip:alice@home1.com/directory.xml", response="3a59fff43373a95592464948595c2e45", cnonce="abc123e6e98a02251455360951b1a900" Figure 18.10: Directory retrieval: HTTP GET request (1) 200 (OK) response (5) is shown in Figure 18.11. The “directory.xml” is identiﬁed with a MIME type of vnd.oma.xcap-directory+xml. HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Date: Thu, 05 Mar 2008 22:10:52 GMT Etag: "9sda09s" Content-Type: application/vnd.oma.xcap-directory+xml Content-Length: 432 Figure 18.11: Directory retrieval: 200 (OK) response (5) The Aggregation Proxy waits sufﬁcient time to receive all of the responses and then combines all the received “directory.xml” documents into a single one, which is included in a 200 (OK) response (6) to the XDMC (see Figure 18.12). Each folder element contains an auid attribute that indicates the application usage to which the included data pertains. This allows the XDMC to distinguish the application usages for which the user has XML documents, and the list of documents of each application usage. XDM not only allows a user to retrieve a directory of all of their documents stored in all servers, but also allows all user documents pertaining to a given XCAP application usage to be retrieved. This is done with a smart trick: XCAP allows a single element to be requested that is part of an XML document; the XDMC requests the folder element of the requested
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 396 HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Date: Thu, 05 Mar 2008 22:10:55 GMT Etag: "x98w2k920" Authentication-Info: nextnonce="3a2154334ce3409fd24e26872024" Content-Type: application/vnd.oma.xcap-directory+xml Content-Length: 599 Figure 18.12: Directory retrieval: Aggregated 200 (OK) response (6) application usage which is included in the overall directory.xml document. The ﬂow is shown in Figure 18.13. Figure 18.13: Directory retrieval with XDM for a given XCAP application usage The XDMC sends an HTTP GET (1) whose Request-URI includes the pointer to the folder element whose auid attribute matches the requested application usage in the directory.xml document. In order to request a fraction of the directory.xml document, the Request-URI also contains the special AUID org.openmobilealliance.xcap-directory as well as the special ﬁle “directory.xml”. Figure 18.14 shows an example of this HTTP GET request (1). The notation /xcap-directory/folder%5b@auid=%22resource-lists%22%5d
18.4. DATA SEARCH WITH XDM 397 is an escaped representation of /xcap-directory/folder[@auid="resource-lists"] which is the XCAP mechanism to indicate the folder element whose auid attribute is set to the value resource-lists. GET /org.openmobilealliance.xcap-directory/users/sip:alice@home1.com /directory.xml/~~/xcap-directory /folder%5b@auid=%22resource-lists%22%5d HTTP/1.1 Host: xdm.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 18 Mar 2008 00:14:33 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="a126802384820945208bp98c0808e0f8021", username="sip:alice@home1.com", nc=00000003, uri="/org.openmobilealliance.xcap-directory /users/sip:alice@home1.com/directory.xml /~~/xcap-directory /folder%5b@auid=%22resource-lists%22%5d", response="2143cc17309a58b37459b3745b38bb39", cnonce="c2948330a8530498d43309835d942531" Figure 18.14: Directory retrieval of a speciﬁc application usage: HTTP GET request (1) Upon receiving this HTTP GET request (1), the Aggregation Proxy veriﬁes the credentials included in the request, and forwards the request (2) to the appropriate server. The address of this server depends on the application usage. In this case, the Shared List XDMS is responsible for the resource-list application usage. The Shared List XDMS builds an XCAP document that contains the request element. This is a special XCAP MIME type application/xcap-el+xml that is used to denote an element of an XML document, as opposed to the complete XML document. Figure 18.15 shows an example of this 200 (OK) response (3). The Aggregation Proxy merely forwards this response to the XDMC (4). 18.4 Data Search with XDM XDM provides a limited search function, allowing XDMCs to search for data remotely stored in XDMSs. The search sequence ﬂow is shown in Figure 18.16. In general, search requests originated in an XDMC are sent to an Aggregation Proxy, which forwards it to an appropriate Search Proxy, which further forwards it to the appropriate XDMS. As usually, the architecture deﬁnes functional elements that, in real implementations, can be combined in single boxes. So, it is appropriate to combine the Aggregation Proxy and the Search Proxy into the same physical equipment. Then, the actual search takes place in the XDMS, which returns the results of the search operation in an HTTP response. When an XDMC wishes to search some data in one or more remotely stored XML document, the XDMC creates an HTTP POST request (1) that contains all of the details required to perform the search. This POST request encodes some details of the search operation in the Request-URI, but the complete detailed parameters of the search are included
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 398 HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Date: Thu, 18 Mar 2008 00:14:35 GMT Etag: "209d29d" Content-Type: application/xcap-el+xml Content-Length: 428 Figure 18.15: Directory retrieval of a speciﬁc application usage: 200 (OK) response (3) in a special XML document called the Search XML document, which is included as a body of the POST request. The search function reuses the XQuery 1.0 speciﬁcation [88]. XQuery provides mechanisms to extract and manipulate data from XML documents. In the context of XDM Search operations, XQuery expressions are included in Search XML documents which are transported in HTTP POST requests. One of the parameters that characterize the search operation consists of the list of input documents where the search takes place. The document or documents where the search takes place can be composed of either all documents of all users pertain- ing to a given XCAP application usage, all documents pertaining to a given applica- tion usage and a given user, or a particular document. For example, let AUID be the AUID, sip:alice@home1.com a Public User Identity, and mylist.xml an XML docu- ment. If the search takes place over all documents stored under the “users” directory of the AUID, the document list is encoded as “[AUID]/users/”; if the search is re- stricted to Alice’s documents for the AUID application, then the search is encoded as “[AUID]/users/sip:alice@home1.com/”; ﬁnally, if the search is restricted to a single user’s document, then the list of documents is encoded with the following pattern: “[AUID]/users/sip:alice@home1.com/mylist.xml”. So, where is this document list encoded in HTTP? It is encoded in two different places: in the Search XML document that is included in the HTTP POST request (1), and in the target parameter of the Request-URI of the same HTTP POST request (1). The reason for encoding the request in two places is twofold: on the one side, the Search XML document contains very detailed and extensive information of the search parameter, more than just the input documents, so, this justiﬁes the presence of search documents in the Search XML body; on the other side, the Search Proxy requires knowledge of the AUID and the user’s name for routing the HTTP POST request (1) to the appropriate XDMS. Making this routing information accessible, e.g., in a parameter of the Request-URI makes things easy for the Search Proxy that, otherwise, would need to open the body and parse the Search XML document to route the HTTP POST request (1).
18.4. DATA SEARCH WITH XDM 399 Figure 18.16: Searching data with XDM Let us continue the description of the search request included in the HTTP POST request (1) with the help of the HTTP POST request example of Figure 18.17. According to this ﬁgure, the Request-URI contains a special minted AUID set to the string “org.openmobilealliance.search”. This allows the Aggregation Proxy to identify this request as a search request and forward it to the Search Proxy. In addition, the Request-URI contains a target parameter whose main purpose is to aid the Search Proxy in routing the HTTP POST request to the appropriate XDMS. A second optional domain restricts the search query to either the home domain, any other particular domain, or all remote domains. The domain parameter defaults to the “home” value. In order to construct a search query, the XDMC creates an HTTP POST request addressed, in the Request-URI, to a specially constructed URI that identiﬁes the search operation and the main search parameters. In Figure 18.17 the Request-URI is set to /org.openmobilealliance.search? target=org.openmobilealliance.user-profile/users/ The ﬁrst part of the Request-URI, set to “/org.openmobilealliance.search”, merely indicates that this is a search request, and it is later used by the Aggregation Proxy to route the request to a Search Proxy. The target parameter indicates the collection of documents where the search takes place, including the AUID, which is set to the user-proﬁle AUID deﬁned by the OMA. The target parameter is used by the Search Proxy to route the request to the appropriate XDMS. The core parameters of the search are included in the Search XML document, which is identiﬁed with a MIME type of “application/vnd.oma-search+xml”. Let us take a closer look at the Search document with the help of the example in Figure 18.17. A Search XML document contains a root element search-set element that contains a single search element, which contains either a request or response element. The example of Figure 18.17 shows a request element, this is a request for data. Non-error responses contain a response element instead. The request element contains a query element that contains a limited or simpliﬁed XQuery expression according to the W3C XQuery 1.0 speciﬁcation [88]. The XQuery expression is enclosed in the CDATA section of the Search XML document. The XQuery expression begins with a preamble indicating the XQuery version number, and it deﬁnes a default namespace. Then it contains a simple “for” iteration loop that selects the collection of documents that serve as input to the search. In the example in Figure 18.17
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 400 POST /org.openmobilealliance.search? target=org.openmobilealliance.user-profile/users/ HTTP/1.1 Host: xdm.home1.com User-Agent: XDM-client/OMA2.0 Date: Thu, 21 Mar 2008 23:35:23 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="a126802384820945208bp98c0808e0f8021", username="sip:alice@home1.com", nc=00000003, uri="/org.openmobilealliance.search? target=org.openmobilealliance.user-profile/users/", response="390982098203984e0a84d0c410792ee0", cnonce="1a893b098385c674eef845098cc50a86" Accept-Encoding: gzip Content-Type: application/vnd.oma-search+xml Content-Length: 647 {$x/@uri}{$x/display-name} ]]> Figure 18.17: Search operation: HTTP POST request (1)
18.4. DATA SEARCH WITH XDM 401 HTTP/1.1 200 OK Server: XDM-serv/OMA2.0 Date: Thu, 21 Mar 2008 23:35:30 GMT Etag: "32092" Content-Type: application/vnd.oma-search+xml Content-Length: 537 Miguel Garcia Gonzalo Camarillo Figure 18.18: Search operation: HTTP 200 (OK) response (4) the value selects all of the documents for all users pertaining to the User Proﬁle application usage stored under the “users” tree in the Shared Proﬁle XDMS, and for each document, the element user-profile, which is a child of the user-profiles element, is selected. Note that this information is also present in the target parameter of the Request-URI of the HTTP POST request, however, there it is only used for routing purposes. The Search XML document then includes a “where” clause that indicates the condition that, in case it is evaluated as true, selects the data. In the example, the condition is set to those entries in the document where the data contains a profession element that includes a title element set to “Engineer” and the address element contains a country element set to “ES”. So, in human parlance, the Search document of Figure 18.17 is searching for a list of Spanish engineers across all of the user’s documents of the User Proﬁle application usage. Last, the “return” clause speciﬁes what should be returned in the response. In the example, the URI and display name of each match is returned. Let us continue with the description of the sequence ﬂow of Figure 18.16. The XDMC sends the HTTP POST request (1) to its Aggregation Proxy, which ﬁrst veriﬁes the credentials included in the Authorization header, and then inspect the Request-URI. Since the Request-URI contains an indication of a search request, the Aggregation proxy forwards the HTTP POST request (2) to a Search proxy. The Search Proxy inspects the target and domain parameters of the Request-URI for routing the request. This target parameter contains the application usage for the request, so the Search Proxy is able to determine, upon looking into an internal table, which is the XDMS responsible for that application usage. In the example in Figure 18.17, the User Proﬁle application usage is indicated, so the Search
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS 402 Figure 18.19: Subscription to changes in XML documents Proxy forwards the HTTP POST request (3) to the Shared Proﬁle XDMS. If the Request-URI had included a domain parameter set to a value different than the default value “home”, the Search Proxy would have forwarded the HTTP POST request to a remote Aggregation Proxy. The Search Proxy can also forward the request to different servers, including different servers located in different domains. When the Shared Proﬁle XDMS (or any other appropriate XDMS) receives the HTTP POST request (3), it inspects the Search XML document to establish the parameters of the search operation and the presentation of the results. The XDMS generates a 200 (OK) response (4) that contains a Search XML document. The Search XML document contains a response element that contains the list of matches formatted according to the return clause of the XQuery request. Figure 18.18 shows an example of the data returned by the Shared Proﬁle XDMS. The HTTP 200 (OK) response (4) is routed back to the Search Proxy. If the request was forwarded to several servers, the Search Proxy would collect all of the data from the different servers and aggregate it into a single response. Then, the Search Proxy forwards the HTTP
18.5. SUBSCRIBING TO CHANGES IN XML DOCUMENTS 403 200 (OK) response (5) to the Aggregation Proxy. The Aggregation Proxy can compress the payload, if supported by the XDMC, but in any case, it forwards the response (6) to the XDMC. The XDMC now parses the data and presents it to the user. 18.5 Subscribing to Changes in XML Documents XDM also provides a subscription/notiﬁcation mechanism to changes in XML documents stored in any of the XDMSs. The mechanism is a straight application of the XCAP-Diff event package that we described in Section 17.6. Consider the example in Figure 18.19. The SUBSCRIBE request (1) contains the list of documents to which subscriptions are required, as well as an indication of the desired “diff processing” model (see Section 17.6 for a detailed description of the “diff processing” model). An initial XCAP-Diff document is included in the NOTIFY request (7). When a document changes, a new XCAP-Diff document contains the list of changes a second NOTIFY request (13).