A Grid Based Specifications of ebXML Bahareh Rahmanzadeh Heravi Computer Engineering and Information Technology Department, Amirkabir University of Technology, Hafez Avenue, Tehran, Iran, [email protected] Mohammadreza Razzazi Computer Engineering and Information Technology Department, Amirkabir University of Technology, Hafez Avenue, Tehran, Iran, [email protected]

Abstract:

discover these services. As the Grid Service is a kind of Web Service, UDDI can be used to store details of the Grid Service too. In the context of Grid computing, a registry may contain the WSDL or GWSDL document about particular services, their current location, or access right to them [7]. Here, it is decided to consider some of ebXML key components as Grid Services. In this context, we will use UDDI for registering and discovering ebXML grid services. It is also decided to let an ebXML trading partner provide generic Grid Services as their own services. These generic Grid Services should also be stored in UDDI. We will demonstrate that while UDDI is a universal technology for publication and discovery of services metadata, it can also be used for the discovery of ebXML Grid Services. Trading partners and their Grid Services and ebXML infrastructures will be able to interact, using UDDI as a common registry. We will also show how to model ebXML and generic Grid Services to match UDDI data structures to use UDDI as ebXML Registry.

ebXML enables enterprises of any size and in any geographical location to conduct business over the Internet. Grid technologies, on the other hand, support the sharing and coordinated use of diverse resources in dynamic Virtual Organizations. As the aim of both entities is to be independent of geographical locations, it will be desirable to utilize the grid as the environment for ebXML. UDDI is a standard protocol for publishing and discovering information about Web Services. As the Grid Service is a kind of Web Service, UDDI can also be used to store details of the Grid Service. In this paper we investigate the features of grid services, ebXML and UDDI registry and explain how to use ebXML on the grid, concentrating on the registry and discovery of ebXML components on the Grid using UDDI registry.

1. Introduction ebXML (Electronic Business using eXtensible Markup Language), is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes [9]. Grid technologies, on the other hand, support the sharing and coordinated use of diverse resources in dynamic Virtual Organizations [4]. That is, the creation of virtual computing systems from geographically and organizationally distributed components. As the aim of both entities is to be independent of geographical locations, it will be desirable to utilize the grid as the environment for ebXML. Grid technology uses web services on the Grid environment, called ‘Grid Services’, that is defined by OGSA (Open Grid Service Architecture) as a Web Service that provides a set of interfaces and behaviors that determines how a client interacts with a Grid service and conforms to a set of conventions [6]. A major problem for a grid user is to discover currently available services. UDDI can be used to

0-7803-9521-2/06/$20.00 ©2006 IEEE.

1.1. ebXML ebXML was started in 1999 as an initiative of OASIS and the United Nations/ECE agency CEFACT. The original project envisioned and delivered five layers of substantive data specification, including XML standards for the following [7]: • Business Process Specification Schema BPSS is an XML-based specification language that formally defines ‘public’ business processes. It focus on the collaboration of trading partners, the binary collaboration that these trading partners are engaged in bilaterally, and the business transaction activities they perform in the context of those collaboration [14]. • Core Components A Core Component is a basic, reusable building block that contains information representing a business concept [15]. • Registry/Repository The ebXML Registry is central to the ebXML

292

architecture. The registry manages and maintains the shared information as objects in a repository. Repositories provide trading partners with the shared business semantics, such as business process models, core components, messages, trading partner agreements, schemas, and other objects that enable data interchange between companies. The ebXML registry is an interface for accessing and discovering shared business semantics [15]. • Collaboration Protocol Profiles and Agreements (CPP/A) The CPP describes the specific capabilities that a trading partner supports. The CPP contains essential information about the trading partner including, but not limited to: contact information, supported Business Processes, Interface requirements and Messaging Service requirements. A CPA is a document that represents the intersection of two CPP’s and is mutually agreed upon by both trading partners [17]. • Messaging Service The ebXML Message Service Specification is designed for the secure, reliable exchange of ebusiness information [15].

that conforms to a particular set of specifications, transports, and protocols, references to the tModels that represent these concepts are placed in the bindingTemplate. In such a way, tModels can be reused by multiple bindingTemplates. It is important to note that such technical documents and the supporting documentation necessary to a developer using Web services are not stored within the UDDI registry itself. A UDDI tModel simply contains the addresses where those documents can be found. A tModel, however, contains more than just URLs; it also stores metadata about the technical documents and an entity key that identifies that tModel. Because tModels can represent any unique concept or construct, they can be used to represent other concepts within the UDDI information model, such that metadata concepts are reused throughout the model [11]. The relationship between these entities is shown in figure 1 below: businessEntity businessService

1.2. UDDI

bindingTemplate

UDDI is an OASIS standard protocol and provides a method for publishing and discovering information about Web Services. It’s registration information is comprised of the following main data structure types: • businessEntity The top-level structure, describing the business or other entity for which information is being registered. The other structures are related via references from this structure [16]. • businessService The name and description of the service being published [16]. • bindingTemplate information about the service, including an entrypoint address for accessing the service[16]. • tModel Technical Models, or tModels for short, are used in UDDI to represent unique concepts or constructs. They provide a structure that allows reuse, and thus, standardization within a software framework. The UDDI information model is based on this notion of shared specifications and uses tModels to engender this behavior. For this reason, tModels exist outside the parent-child containment relationships between the businessEntity, businessService and bindingTemplate structures. Each distinct specification, transport, protocol or namespace is represented by a tModel. Examples of tModels that enable the interoperability of Web services include those based on Web Service Description Language (WSDL), XML Schema Definition (XSD), and other documents that outline and specify the contract and behavior. To describe a Web service

0-7803-9521-2/06/$20.00 ©2006 IEEE.

References

bindingTemplate

tModel References

businessService bindingTemplate

tModel

tModel References

Figure 1. UDDI Data Structure

2. Assumptions Here it is assumed that some of the ebXML key components, namely, Collaboration Protocol Profile and Agreements, Business Process Specification Schema and Core Components can be Grid Services. It is also assumed that an ebXML trading partner can provide generic Grid Services as their own services. ebXML trading partners provide two types of Grid Services; ebXML Grid Services and generic Grid Services. ebXML Grid Services are aforementioned ebXML key components that are served on the Grid as services. By generic Grid Services, we mean standard services on the Grid. They can be either trading partners’ goods or services that they provide. In this context, we will use UDDI for registering and discovering both types of Grid Services and GWSDL for specifying generic Grid Services which will be stored in a specific place on the Grid. ebXML Grid services description will remain as standard ebXML components’ specifications and will be stored in the ebXML repositories or anywhere on the Grid and will be referenced via UDDI registry. UDDI is just a Registry,

293

referencing a specific service or data, but it does not store them.

• An ebXML Trading Partner, which is an instance of Organization class will be modeled as a businessEntity. • An ebXML Grid Service, which is an instance of Service class, will be modeled as a businessService. • A CPP/A will be modeled as a businessService belonging to the businessEntity. • A ServiceBinding will be modeled as bindingTemplate. • A SpecificationLink will be modeled as a tModelInstanceInfo that represents bindingTemplate entity-specific details for each tModel referenced. • A tModel will be created to represent each ebXML specification. The summary of the mapping ebXML Registry Classes to UDDI is shown in table 1 below:

3. Modeling ebXML key components in UDDI Registry In order to store ebXML components in UDDI, we will map ebXML Registry Information Models and key components to related UDDI entities. Related ebXML Registry Information Model (RIM) classes are shown in figure 2 below: Service

Service bindings 1

ServiceBinding

0..*

0..1

targetBinding 1

Association 0..* Organization

RegistryObject 0..* 0..*

0..*

SpecificationLinks

SepcificationLink

Table 1. Mapping related ebXML Registry Classes and modules to UDDI

0..*

0..1 Parent

Figure 2. Relationship between Grid Service related RIM classes The definitions of the related Information Model classes shown in figure 2 above are listed below [2]: • Class Service Service instances describe services, such as web services. • Class ServiceBinding ServiceBinding instances are RegistryObjects that represent technical information on a specific way to access a Service instance. An example is where a ServiceBinding is defined for each protocol that may be used to access the service. • Class SpecificationLink A SpecificationLink provides the linkage between a ServiceBinding and one of its technical specifications that describes how to use the service using the ServiceBinding. For example, a ServiceBinding may have SpecificationLink instances that describe how to access the service using a technical specification such as a WSDL document. • Class Organization Organization instances provide information on organizations such as a Submitting Organization. Each Organization instance may have a reference to a parent Organization. • Class RegistryObject The RegistryObject class extends the Identifiable class and serves as a common super class for most classes in the information model.

ebXML Registry Class Organization Service ServiceBinding

UDDI businessEntity businessService bindingTemplate

SpecificationLink CPP/A ebXML Specifications

tModelInstanceInfo businessService tModel

As mentioned above, a tModel for each ebXML Specification will be defined. There is a related Technical Note by OASIS that suggests defining three types of tModels as follows [5]: • Specifications Taxonomy tModel This taxonomy is used to categorize each ebXML specification represented by a Common ebXML tModel to aid in their discovery. • Common ebXML tModels These tModels refer to specific versions of ebXML specifications/concepts, such as CPP v2.0, UN/CEFACT BPSS v1.10, Message Service v2.0, and so on. • Proprietary tModels These tModels refer to specific instances or implementations of ebXML specifications. For instance, a particular business process, described in an ebXML BPSS, is an instance of BPSS, and it can be defined as a proprietary tModel. For the purposes of this paper, it is not necessary to detail Specification Taxonomy and Common ebXML tModels. Only an example of Proprietary tModel will be outlined. More information is available in the [5] technical note.

The basis for modeling UDDI as ebXML Registry will be as follows:

Proprietary tModel example Let’s assume that the BPSS instance is called ‘Process1’ and is located at

0-7803-9521-2/06/$20.00 ©2006 IEEE.

294

‘http://address/process1.bpss’. The Proprietary tModel will be as follows:



Process1 standard process #1 address/process1.bpss

To this point we have explained the concept as a web service. We will now demonstrate where and how the Grid Service can be utilized.

4. Storing Grid Services in UDDI The next step is to show how we could model Grid Services on UDDI registry.

4.1. Grid Services Grid Services are an extension to Web Services for operating in Grid environments. Like Web Services, Grid Services can be registered in a UDDI registry. However, there are a number of requirements for a Grid Service to be successfully registered and located in a UDDI registry. [7] One extension to Web Services that a Grid Service introduces is Service Data. Service Data provides the information about a service, which the interface alone cannot provide. Every Grid Service has a basic set of Service Data Elements (SDEs), which contain information about the service, its interface, and its location. UDDI's data model is adept at storing information about Web Services, however, lacking the ability to record the Service Data of a Grid Service [2]. To overcome this, a new data type called serviceData, which is the child of a single bindingTemplate, can be used to store Service Data. The serviceData type stores the current Service Data of the Grid Service described in the parent bindingTemplate. This is shown in Figure 3 below:

Each trading partner in ebXML must have at least one CPP. For registering a CPP in our case, the CPP Grid Service, itself will be defined as a businessEtity and its address will be defined as an Access Point in a businessService’s bindingTempalte in UDDI. The common ebXML tModel, an example of which has been defined above, will be referenced in tModelInstanceInfo. This is shown in the listing below: Company A … Company A's CPP … http://address/CPP.cpp A's CPP is here! ebxml-org:CPP:v2_0

0-7803-9521-2/06/$20.00 ©2006 IEEE.

businessEntity businessService bindingTemplate Contains

tModel References

serviceData

Figure 3. service data in UDDI structure

4.2. Web Service/ Grid Service Description The Web Service interface is described by WSDL (Web Services Description language) whose function is to explain how to use the service. A new tag GWSDL (Grid WSDL) has been added to the WSDL document for Grid Service description [3].

295

Table 2. Mapping WSDL elements to UDDI elements

WSDL breaks down Web services into a number of elements, which are as follows [16]: • Data types The data types—in the form of XML schemas or possibly some other mechanism—to be used in the messages • Message An abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation. • Operation: The abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message. • Port type An abstract set of operations mapped to one or more end points, defining the collection of operations for a binding; the collection of operations, because it is abstract, can be mapped to multiple transports through various bindings. • Binding The concrete protocol and data formats for the operations and messages defined for a particular port type. • Port A combination of a binding and a network address, providing the target address of the service communication • Service A collection of related end points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions.

WSDL element portType binding service port

UDDI element tModel tModel businessService bindingTemplate

For successful use of UDDI to register Grid Services, we need a method for exposing SDE’s in a UDDI registry. To achieve this, it is possible to use the general_keyword category tModel for a keyedReference. A KeyedReferences provide a mechanism to express additional metadata and to represent a relationship between two UDDI entities. If the tModelKey involved is "uddi:uddi-org:general_keywords", the keyName must match (wildcard matching rules apply if the approximateMatch findQualifier is used). Omitted keyNames are treated as empty keyNames. Otherwise, keyNames are not significant unless so indicated in the individual API sections below [11] . In this case the keyName would be the namespace and name for the SDE and the keyValue would be the actual value:

In the Figure 4 below the mapping between GWSDL and UDDI is shown. GWSDL

GWSDL extends WSDL by introducing SDEs to WSDL PortType element. To all intents and purposes an SDE is a property or attribute of the Web Service (comparable to properties of classes and objects). Static SDEs are used to convey metadata about the Grid Services used for discovery purposes [7]. It also extends WSDL by introducing the concept of PortType inheritance. A PortType can inherit operations (and SDEs) from other PortTypes. [7]

UDDI

service

businessService

port

bindingTemplate

binding

binding tModel

portType tModel

portType

serviceData

SDD

For registering both, WSDL and GWSDL in UDDI registry, it is needed to map their data structure to UDDI data structure.

portType

portType

portType tModel

portType tModel

SDD

SDD

serviceData

serviceData

Figure 4. Mapping GWSDL to UDDI

4.3. Mapping WSDL/GWSDL to UDDI

The listing below shows How to model ebXML Grid Services and also a generic Grid Service belonging to Company A in UDDI:

At first we look at the mapping of WSDL and UDDI, and then we will investigate how to map GWSDL to UDDI for registering Grid Services.

Company A … Company A's CPP

Mapping between WSDL and UDDI is as follow:

0-7803-9521-2/06/$20.00 ©2006 IEEE.

296

6. References:

… Company A’s generic Grid Service1 http://GS address/GS1

[1] ebXML, “OASIS/ebXML Registry Services Specification”, V3.0, May 2005. [2] ebXML, “OASIS/ebXML Registry Information Model” V3.0, May 2005. [3] Liang-Jie Zhang, Jen-Yao Chung ,Qun Zhou, “Developing Grid computing applications, Part 1”, IBM, March 2005, http://www-128.ibm.com/developerworks/library/gr-grid1/. [4] Foster, I., Kesselman, C. and Tuecke, S. “The Anatomy of the Grid: Enabling Scalable Virtual Organizations”, International Journal of High Performance Computing A p p l i c a t i o n s , 2001, http://www.globus.org/research/papers/anatomy.pdf. [5] Keisuke Kibakura, “UDDI as the Registry for ebXML components”, OASIS Technical Note, 2004. [6] Steven Tuecke, Karl Czajkowski, Ian Foster, Jeffrey Frey, Steve Graham, Carl Kesselman, “Grid Service Specification“, Global Grid Forum, 2002. [7] Ahmar Abbas, Grid Computing: A Practical Guide to Technology and Applications, Firewall Media, 2004. [8] OASIS, "Introduction to UDDI: Important Features and Functional Concepts”, October 2004. [9] ebXML, http://www.ebXML.org [10] John Colgrave, Karsten Januszewski, “Using WSDL in a UDDI Registry, Version 2.0.2 - Technical Note [11] UDDI Spec TC, “UDDI Version 3.0.2”, OASIS, 2004, http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. [12] Edward Benson, Glenn Wasson and Marty Humphrey, “Evaluation of UDDI as a Provider of Resource Discovery Services for OGSA-based Grids”, 2005, http://www.cs.virginia.edu/~humphrey/papers/UDDI_Grids.pdf.

[13] Brian Gibb, Suresh Damodaran, ebXML : Concepts and Application, Wiley, 2002. [14] Duane Nickull, Jean-Jacques Dubray, Colleen Evans, …, Professional ebXML Foundations, Wrox Press, 2001.

5. Conclusion

[15] Eric Chiu, Eric Chiu, ebXML Simplified: A Guide to the New Standard for Global E Commerce, Wiley, 2002.

We demonstrated how to use ebXML on the grid. We also noted that one of the most important issues in this exercise is the registry of ebXML components and services. The first choice for registering and storing ebXML components is ebXML Registry/Repository. However, in this paper, UDDI registry is chosen for this purpose. The reason is that UDDI is more popular and is being used as a registry more frequently than ebXML Registry. Another reason for this choice is the existing research activities in the context of using UDDI on the grid and as ebXML components registry. The next step is to utilize ebXML Registry for this purpose, in order to achieve an integrated e-business framework on the Grid. This will be the subject of our future research.

0-7803-9521-2/06/$20.00 ©2006 IEEE.

[16] Eric Newcomer, Understanding Web Services, XML, WSDL, SOAP and UDDI, Addison Wesley, 2002. [17] ebXML, “Technical Architecture Specification” v1.0.4, 2001. [18]OGSA-WG, Open Grid Service Infrastructure Primer, Global Grid Forum , 2004, http://www.ggf.org/ogsi-wg.

297