Browse Prior Art Database

Service Endpoint Invocation via XPath Over Different Channels

IP.com Disclosure Number: IPCOM000125370D
Original Publication Date: 2005-May-31
Included in the Prior Art Database: 2005-May-31
Document File: 5 page(s) / 75K

Publishing Venue

IBM

Abstract

In this disclosure, we described an automated method that transforms URL request as well as any format of service request into OAGIS BOD using XPath mapping. This transformation is not limited as XML to XML. The transformation can be XML to Java object as well.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 5

Service Endpoint Invocation via XPath Over Different Channels

There is disclosed an automated method for transforming a known format of service request into OAGIS BOD using XPath mapping. Both request data from a channel and a service data object can be considered as graphs. A graph can be represented by a set paths, therefore, we can use a configuration file to map a set of XPaths that describe request data to a set of XPaths that describe service data. The XPaths can be associated with actions to indicate how service data is to updated. The disclosed technique creates service data objects based on the mappings in the configuration file and the corresponding request data, and then dispatches appropriate services to process the constructed service data objects. This provides a uniform yet simple mechanism to invoke services for different channels. No matter how a channel takes user input, it can simply map the input data to a service data with a set of XPaths, and then invoke one or more services within one request. The mapping is easy, because no special cases such as how to specify partial update compared with complete update, need to be handled, and the mapping can be specified declaratively. It also minimizes the cost of writing the code that calls services for each channel, because the logic of calling services can be automated and be driven by a configuration file. When new services or new channel requests are added, invocation logic does not need to be changed just add new mappings to configuration, which is convenient and of low cost.

     The data to be processed by services should be put into a service data object. A service data object is an object that contains a set of data. A service data object can also contain one or more other service data objects. Therefore, a service data object forms a graph of data. For example, a gift registry has a name, an event date, a registry id, a list of registrant, and a shipping address. A registrant has first name, last name, and a login ID. An address has street number, city, and zip code. We can use a service data object to represent a gift registry, an address, and a registrant, respectively. The data graph may look as follows:

1

Page 2 of 5

Service Data Object Example

GiftRegistry

name = 'Wedding Registry' eventDate = '2005-03-21' registryId = 10001

RegistrantList

RegistrantList

Registrant

lastName = 'Smith' firstName = 'Jack Smith' loginId = 'jsmith'

Registrant

lastName = 'Smith' firstName = 'Jack Smith' loginId = 'jsmith'

Registrant

lastName = 'Simpon' firstName = 'Homer' loginId = 'shomer'

Registrant

lastName = 'Simpon' firstName = 'Homer' loginId = 'shomer'

Shipping

streetNumber = city = 'Markham' zipCode = 'L6C2

Figure 1. A gift registry service data object

Since a graph can be represented as a set of paths, XPaths can be used to fully represent a service data object. That is, each object in a service data object can be uniquely identified by an XPath. For example, the last name...