Embed Size (px)
Citation preview
Design and Implementation of a Web Service Application for SCM
A dissertation submitted to The University of Manchester for the degree of
Master of Science in the Faculty of Engineering and Physical Sciences
2009
ZHANGMIN LU
SCHOOL OF COMPUTER SCIENCE
1
List of Contents
List of Contents.................................................................................................................................. 1 List of Figures .................................................................................................................................... 4 List of Examples................................................................................................................................ 6 List of Tables...................................................................................................................................... 7 Abstract .............................................................................................................................................. 8 Declaration......................................................................................................................................... 9 Copyright Statement....................................................................................................................... 10 Acknowledgement.............................................................................................................................11 Abbreviations................................................................................................................................... 12 Chapter 1 Introduction ................................................................................................................... 13
1.1 Overview..................................................................................................................................... 13
1.2 Outline of the Scope and Context of Investigation ................................................................. 14
1.3 Definition of the Problem.......................................................................................................... 16
1.3.1 The need for implementing SCM as Web Services...................................................... 16 1.3.2 Resource modelling technique for RESTful Web Services......................................... 17
1.4 The prototype............................................................................................................................. 17
1.5 Structure of the dissertation..................................................................................................... 18
Chapter 2 Background.................................................................................................................... 19
2.1 Web Services.............................................................................................................................. 19
2.1.1 SOAP and RESTful Web Services................................................................................. 19 2.1.2 Business Model of Supply Chain is Document-centric ................................................ 23 2.1.3 RESTful Web Services and Document Exchange enable Loose Coupling................ 24 2.1.4 Resource Modelling for RESTful Web Services........................................................... 25
2.2 ebXML – The e-Business Framework...................................................................................... 27
2.3 Standard Business Vocabulary – Universal Business Language........................................... 29
2.4 The SCOR Model...................................................................................................................... 31
2.5 Summary.................................................................................................................................... 32
Chapter 3 Investigation Methods and Business Analysis............................................................. 33
3.1 Research Methodology.............................................................................................................. 33
3.2 Research Approach.................................................................................................................... 34
3.2.1 Analysis............................................................................................................................ 34 3.2.2 Design.............................................................................................................................. 34 3.2.3 Implementation............................................................................................................... 35
3.3 Expected Results........................................................................................................................ 36
3.4 Limitations ................................................................................................................................. 36
2
3.5 Business Analysis....................................................................................................................... 37
3.5.1 Requirements Definition................................................................................................ 37 3.5.2 Business Activity Modelling........................................................................................... 40
3.6 Summary.................................................................................................................................... 43
Chapter 4 Prototype Design............................................................................................................ 44
4.1 System Architecture Overview................................................................................................. 44
4.2 System Design............................................................................................................................ 45
4.2.1 RESTful Web Services Design....................................................................................... 45 4.2.1.1 The Seller System......................................................................................................45 4.2.1.2 The Buyer System..................................................................................................... 50 4.2.1.3 The Third Party Warehouse System......................................................................... 52 4.2.1.4 Basic Model for URI in RESTful Web Services...................................................... 53
4.2.2 ebBP Design..................................................................................................................... 54 4.2.3 ebCPPA Design............................................................................................................... 57 4.2.4 UBL Document Design................................................................................................... 60
4.3 Summary.................................................................................................................................... 62
Chapter 5 Prototype Implementation............................................................................................ 63
5.1 Project Tools............................................................................................................................... 63
5.2 Implementation Server Side of Seller System......................................................................... 64
5.2.1 Server Side of Seller System.......................................................................................... 64 5.2.1.1 Item Inquiry.............................................................................................................. 64 5.2.1.2 Request for Quote..................................................................................................... 66 5.2.1.3 Order Processing....................................................................................................... 70 5.2.1.4 Receive Receipt Advice............................................................................................. 76
5.3 Implementation Client Side of Buyer System......................................................................... 78
5.3.1 Graphic User Interfaces................................................................................................. 78 5.3.2 Implementation of Basic Model for RESTful URI – Treetop in Ruby....................... 80
5.4 Implementation of ebXML Registry/Repository Server ........................................................ 82
5.5 Summary.................................................................................................................................... 84
Chapter 6 Testing and Evaluation.................................................................................................. 85
6.1 Testing......................................................................................................................................... 85
6.1.1 Command Line Testing.................................................................................................. 85 6.1.2 GUI Testing..................................................................................................................... 86
6.2 Evaluation.................................................................................................................................. 88
6.2.1 Strengths.......................................................................................................................... 88 6.2.1.1 Simplicity................................................................................................................... 88 6.2.1.2 Scalability.................................................................................................................. 89 6.2.1.3 Usability.................................................................................................................... 89
6.2.2 Limitations ...................................................................................................................... 89 6.2.2.1 Security...................................................................................................................... 89
3
6.2.2.2 Lack of support of complex URI.............................................................................. 90 6.2.2.3 Lack of automated tool............................................................................................. 90
6.3 Summary.................................................................................................................................... 90
Chapter 7 Conclusions.................................................................................................................... 91
7.1 Critical Analysis......................................................................................................................... 91
7.2 Reflection.................................................................................................................................... 92
7.3 Future Work............................................................................................................................... 92
References......................................................................................................................................... 93 Appendix A – ebXML Business Process Schema............................................................................. 96 Appendix B – ebXML CPP and CPA............................................................................................. 102 Appendix C – UBL Documents......................................................................................................125
Total Word Count: 20,705
4
List of Figures
Figure 2-1 SOAP Web Services request to server............................................................................21 Figure 2-2 RESTful Web Services request to server.......................................................................23 Figure 2-3 OASIS ebXML framework Overview............................................................................28 Figure 3-1 Business Activity Model...................................................................................................41 Figure 4-1 Prototype Architecture....................................................................................................44 Figure 4-2 DFD – Process Item Inquiry............................................................................................45 Figure 4-3 RESTful Resource Model – Process Item Inquiry ........................................................46 Figure 4-4 DFD – Process Quote.......................................................................................................46 Figure 4-5 RESTful Resource Model – Process Quote....................................................................47 Figure 4-6 DFD – Process Order.......................................................................................................47 Figure 4-7 RESTful Resource Model – Process Order....................................................................47 Figure 4-8 DFD – Process Order Inquiry.........................................................................................48 Figure 4-9 RESTful Resource Model – Process Order Inquiry ......................................................48 Figure 4-10 DFD – Order Cancellation............................................................................................49 Figure 4-11 RESTful Resource Model – Order Cancellation .........................................................49 Figure 4-12 DFD – Order Change.....................................................................................................49 Figure 4-13 RESTful REST Resource Model – Order Change......................................................50 Figure 4-14 DFD – Receive Receipt Advice......................................................................................50 Figure 4-15 RESTful Resource Model – Receive Receipt Advice...................................................50 Figure 4-16 DFD – Process Despatch Advice...................................................................................51 Figure 4-17 REST Resource Model – Process Despatch Advice.....................................................51 Figure 4-18 DFD – Process Receipt Advice......................................................................................51 Figure 4-19 REST Resource Model – Process Receipt Advice........................................................51 Figure 4-20 DFD – Receive Invoice...................................................................................................52 Figure 4-21 REST Resource Model – Receive Invoice....................................................................52 Figure 4-22 DFD – Receive Despatch Advice...................................................................................52 Figure 4-23 REST Resource Model – Receive Despatch Advice.....................................................53 Figure 4-24 Basic structure of ebBP instance...................................................................................55 Figure 4-25 FreebXMLBP Editor .....................................................................................................55 Figure 4-26 FreebXML CPPA Editor ...............................................................................................58 Figure 4-27 UBL Documents in Business Activity Model................................................................61 Figure 5-1 Main GUI window of buyer system................................................................................79 Figure 5-2 GUI window of business operation.................................................................................79 Figure 5-3 Welcome page of freebxml registry and repository.......................................................82 Figure 5-4 Search results of ebXML cppa objects...........................................................................83 Figure 5-5 Detail of ebXML cppa object ..........................................................................................83 Figure 5-6 Repository item e.g. ebXML CPP profile.......................................................................84 Figure 6-1 Curl command line testing sample 1..............................................................................85 Figure 6-2 Curl command line testing sample 2..............................................................................86 Figure 6-3 Change Order GUI testing sample 1..............................................................................86 Figure 6-4 Change Order GUI testing sample 2..............................................................................86 Figure 6-5 Change Order GUI testing sample 3..............................................................................87
5
Figure 6-6 Change Order GUI testing sample 4..............................................................................88
6
List of Examples
Example 2-1 SOAP-RPC Web Services request/response sample..................................................19 Example 2-2 RESTful Web Services request/response sample.......................................................22 Example 2-3 EBNF sample................................................................................................................27 Example 2-4 OASIS UBL Quotation document sample..................................................................30 Example 4-1 EBNF Grammar for Basic Model of URI in RESTful Web Services.......................53 Example 4-2 Samples of URI.............................................................................................................54 Example 4-3 Sample ebBP instance document................................................................................55 Example 4-4 Excerpt of seller’s CPP................................................................................................58 Example 4-5 CPA template................................................................................................................60 Example 5-1 Excerpt of index.xml.builder of item data source......................................................65 Example 5-2 Excerpt of show.xml.builder of item data source......................................................65 Example 5-3 Excerpt of items_controller.rb....................................................................................66 Example 5-4 Model of Quote.............................................................................................................67 Example 5-5 Model of QuoteLine.....................................................................................................67 Example 5-6 Excerpt of create.xml.builder of quote data source...................................................68 Example 5-7 Excerpt of quotes_controller.rb..................................................................................69 Example 5-8 Model of Order.............................................................................................................70 Example 5-9 Model of OrderLine.....................................................................................................70 Example 5-10 Excerpt of create.xml.builder of order data source.................................................72 Example 5-11 Excerpt of index.xml.builder of order data source..................................................73 Example 5-12 Authetication function of order data source controller...........................................74 Example 5-13 Excerpt of orders_controller.rb................................................................................74 Example 5-14 Model of Receipt.........................................................................................................76 Example 5-15 Model of ReceiptLine.................................................................................................76 Example 5-16 Excerpt of create.xml.builder of receipt advice data source...................................77 Example 5-17 Excerpt of receipts_controller.rb ..............................................................................78 Example 5-18 Treetop grammar of Basic Model for RESTful URI ...............................................80 Example 5-19 Using treetop grammar in Ruby...............................................................................82
7
List of Tables
Table 2-1 Supply-Chain Operations Reference-model....................................................................31 Table 3-1 Requirements Catalogue...................................................................................................40 Table 5-1 Project Software Development Tools................................................................................64
8
Abstract
In the Supply Chain Management (SCM) world, Electronic Data Interchange (EDI) has
been adopted by the large enterprises for business transactions such as placing orders,
sending despatch advice, and receiving invoices. However, the cost and effort required to
deploy traditional EDI is significant for small and medium-size enterprises.
Fortunately, new standards and methodologies have been developed to provide better
business solutions. Among these emerging techniques, Web Services, Electronic
Business eXtensible Markup Language (ebXML), and Universal Business Language
(UBL) are leading ones for e-Business integration. Instead of using traditional SOAP
Web Services approach, this project investigates the alternative lightweight and
document-centric RESTful Web Services approach based on the REpresentational State
Transfer (REST) architectural style of the World Wide Web in order to implement supply
chain activities as a set of Web Services.
While Web Services establish the means of communication, ebXML is the framework for
e-Business integration and collaboration including business registries, processes, profiles,
and agreements. In addition, UBL is a universal XML library designed for business
document exchange. With these advanced technologies, this project aims to develop a
prototype using lightweight and document-centric RESTful Web Services, ebXML
framework, and UBL standard business documents for SCM, thus demonstrating the
benefits of applying and integrating modern techniques into business scenarios.
9
Declaration
No portion of the work referred to in the dissertation has been submitted in support of an
application for another degree or qualification of this or any other university or other
institute of learning.
10
Copyright Statement
Copyright in text of this dissertation rests with the author. Copies (by any process) either
in full, or of extracts, may be made only in accordance with instructions given by the
author. Details may be obtained from the appropriate Graduate Office. This page must
form part of any such copies made. Further copies (by any process) of copies made in
accordance with such instructions may not be made without the permission (in writing)
of the author.
The ownership of any intellectual property rights which may be described in this
dissertation is vested in the University of Manchester, subject to any prior agreement to
the contrary, and may not be made available for use by third parties without the written
permission of the University, which will prescribe the terms and conditions of any such
agreement.
Further information on the conditions under which disclosures and exploitation may take
place is available from the Head of the School of Computer Science.
11
Acknowledgement
First, I would like to take this opportunity to thank my supervisor Dr. Sandra Sampaio
for her professional guidance and advice, and I really appreciate her inspiring and
constant support during this project. I also would like to thank my MSc program director
Dr. Thierry Scheurer for his help during my study in University of Manchester. Finally, I
would like to thank my family who always support and encourage me during this year.
12
Abbreviations
ABIE Aggregate Business Information Entity ACL Access Control List API Application Programming Interface BBIE Basic Business Information Entity Cac Common Aggregate Components Cbc Common Basic Components CGI Common Gateway Interface CORBA Common Object Requesting Broker Architecture CPA Collaboration Protocol Agreement CPP Collaboration Protocol Profile CRM Customer Relationship Management CRUD Create, Read, Update, and Delete DCOM Distributed Component Object Model DFD Data Flow Diagram ebBP ebXML Business Process ebCPPA ebXML Collaboration Protocol Profile and Agreement EBNF Extended Backus–Naur Form e-Business Electronic Business ebXML Electronic Business eXtensible Markup Language EDI Electronic Data Interchange ERP Enterprise Resource Planning HTTP Hypertext Transfer Protocol ICT Information and Communication Technology ISO International Organization for Standardization OASIS Organization for the Advancement of Structured Information
Standards OWL Web Ontology Language RDF Resource Description Framework REST REpresentational State Transfer RPC Remote Procedure Call SCM Supply Chain Management SCOR Supply-Chain Operations Reference SKOS Simple Knowledge Organization System SOAP Simple Object Access Protocol SSADM Structured Systems Analysis and Design Method UBL Universal Business Language UN/CEFACT United Nations Centre for Trade Facilitation and Electronic
Business URI Universal Resource Identifier VAN Value Added Network WMS Warehouse Management System XML Extensible Markup Language
13
Chapter 1 Introduction
This chapter gives an overview of the research areas this project is interested in, and then
outlines the scope and context of the investigation. After that, it introduces the problem
to be solved, and introduces prototype developed during this project. Finally, the
structure of dissertation is presented with a brief introduction of each following chapter.
1.1 Overview
The Internet has become the most effective world-wide communication channel. The
World Wide Web is the most successful use over the Internet, people use web sites to buy
books and CDs (Amazon), retrieve information (Wikipedia), build up social network
(Facebook, MySpace), search other web sites (Google, Yahoo!), buy and sell their
merchandise (eBay), and so on.
In the trading world, the new business model over Internet is the so-called Electronic
Business (e-Business). The evolutionary e-Business model covers a wide span and
focuses on streamlining the entire value chain network including supply chain,
automating business transactions, and collaboration between business partners. The main
task of e-Business integration is automation of commercial and administrative operations
between partners within a value chain network.
In emerging e-Business technologies, Web Services technology provides an important
means to support interoperation between different computer applications running on
diverse platforms. The objective of Web Services is to provide interfaces to enable
distributed systems to communicate with each other, and Web Services utilise standards
such as HTTP (Hypertext Transfer Protocol), URI (Universal Resource Identifier), and
XML (Extensible Markup Language) to share and exchange information via Internet. By
constructing and deploying Web Services in the distributed computing environment,
applications can be connected seamlessly across heterogeneous environments.
14
Business registries, processes, profiles, and agreements are other important elements of
e-Business collaboration. A business registry is a repository service where organisations
can register and search for Web Services like Yellow Pages for telephone numbers.
Business processes services are used to define and promote a reference model of
business information exchange. Business profiles and agreements services provide a
means for business partners to interact through their technical capabilities.
Document exchange is at the centre of e-Business transactions. XML has claimed to have
solved the standard for document exchange; however, with XML only one cannot resolve
the issue of semantics of business documents. As a result, there is a demand for a
standard business vocabulary to tackle semantic conflicts of the data in different
situations or contexts, and define conceptual models for semantics of business
documents using XML syntax.
Supply Chain Management (SCM) is the cross-discipline management of a network of
interconnected business processes, which has been in existence and evolving for several
decades. There is a public recognition that SCM is one crucial area that affects every
business irrespective of size, sector or location ranging over suppliers, customers, and
business partners who work collaboratively to deliver goods or services as required. In
this sense, a common cross-industry standard reference model of SCM would help to
address and improve supply chain best practices, and enhance the communication
between cooperative supply chain parties.
1.2 Outline of the Scope and Context of Investigation
Currently, there are two main approaches to implement Web Services; these two
approaches are the traditional SOAP Web Services approach and the alternative
lightweight and document-centric RESTful Web Services approach. SOAP Web Services
approach encapsulates business operations as remote procedure calls (RPCs) into SOAP
message envelope, e.g. getting weather temperature information by sending request to a
Web Service to perform a ‘GetTemp’ procedure with some parameters [33]. This
15
approach is flexible to define customised service interfaces, but it requires extra server
layer to parse the SOAP envelope. Furthermore, because business function names are
application dependent, communicating parties must understand those functions
beforehand in order to implement SOAP service clients. Nevertheless, SOAP is a
sophisticated and powerful mechanism to integrate complex corporate-level applications
in a stable environment where business relationships are very close.
On the other hand, RESTful Web Services approach is lightweight, which just simply
uses standard protocol HTTP, universal naming and addressing scheme URIs to
exchange (XML) documents between senders and receivers [3]. For example, a buyer
(customer) can place a purchase order to a seller (supplier) by sending an XML
document to a particular URI using the HTTP POST method. In addition, RESTful Web
Services conform to three architectural basics of the World Wide Web [34]:
• Identification – identifying resources via URIs.
• Interaction – Web agents communicating via standardised protocols e.g. HTTP.
• Formats – using Internet media type for representation e.g. XHTML, XML.
RESTful Web Services approach like the World Wide Web is suitable for open
environment communication, and is affordable for small and medium businesses to
implement because it is an easy and cheap technology utilising the proved .design
principles behind the modern Web.
Electronic Business eXtensible Markup Language (ebXML) [12] is an e-Business
framework that includes a suite of standards such as ebXML Registry/Repository for
storing and sharing business registries, ebXML Business Process (ebBP) for designing
business process models, ebXML Collaboration Protocol Profile and Agreement
(ebCPPA) for setting up an individual entity’s technical capabilities and establishing the
contract between entities.
Universal Business Language (UBL) [21] is the first International effort and
specification for e-Business document exchange. It consists of a royalty-free XML
16
library of standard business documents such as purchase order and invoice. UBL directly
supports the existing business by eliminating the data re-entering in current paper-based
supply chains. More important, UBL provides a standard business vocabulary for
partners to communicate based on a common understanding of the semantics of
documents.
Supply-Chain Operations Reference (SCOR) [23] model is a global industrial initiative
in the supply chain domain. Lead by the International non-profit consortium
Supply-Chain Council and embraced by thousands of organisations, SCOR establishes a
common reference model to manage supply chain processes and improvements covering
source, make, deliver processes etc.
1.3 Definition of the Problem
1.3.1 The need for implementing SCM as Web Services
Advances in Information and Communication Technology (ICT) have lead to
fundamental changes in the way companies conduct and manage their businesses. With
sophisticated solutions like ERP (Enterprise Resource Planning), CRM (Customer
Relationship Management), and WMS (Warehouse Management System), the efficiency
of internal operations of an individual organisation has been improved greatly. However,
these solutions do not help in the automation, integration, and collaboration for the entire
supply chain. With the fast-paced and ever changing global market, mass customisation,
agile product development, and extensive outsourcing, companies are experiencing more
and more pressure on their supply chains.
EDI technology has been developed and adopted for many years. However, while about
95% of Fortune 1000 enterprises are using EDI, there are only 2% of small and
medium-size enterprises that can afford to use it [1]. Thus, EDI has been commonly
recognised as an expensive and complex solution because of its obscure syntax and the
difficult supporting applications, high cost of implementation via proprietary VAN
(Value Added Network), and the rigid structure. Therefore, the low-investment,
17
easy-to-start (HTTP and XML), communication-via-Internet approach of implementing
supply chain management processes as Web Services is imperative to cut cost, and raise
competitiveness of enterprise, its suppliers, and business partners.
1.3.2 Resource modelling technique for RESTful Web Services
Simple is beautiful, something like CRUD (Create, Read, Update, and Delete) is a major
part of nearly all computer software. There is one example that has proved the power of
few methods and that is SQL, the famous SELECT, UPDATE, INSERT, and DELETE
can manipulate the database effectively. Similar to SQL, HTTP – the standard protocol
used by RESTful Web Services also has uniform interfaces GET, POST, PUT, and
DELETE [2]. However, developing HTTP-based RESTful Web Services to support and
automate business activities requires sophisticated system analysis and design. In
particular, in order to expose application capabilities through resources with limited
uniform interfaces, a ‘resource modelling’ technique is required which can help to
program the services that fulfil the required capabilities.
1.4 The prototype
Instead of following the traditional SOAP-RPC approach, this project explores the
document-centric lightweight RESTful Web Services based on HTTP+URI+XML, and
open international standards ebXML e-Business framework and UBL business
documents to make partner-facing Web Services simple and affordable for enterprises of
any size in supply chain domain. This combined solution has not been found in the initial
literature review; and it is worth investigating and testing.
This project investigates and evaluates technologies introduced in this chapter, and then
implements a prototype by integrating RESTful Web Services, ebXML framework, and
UBL business document standard in the context of a small fictional SCM scenario. The
SCOR model is used as reference in the implementation. The participants include a PC
manufacturer company PCMaker, its PC components supplier, and PCMaker’s third
party warehouse operator. The aims of this project are:
18
• Analysis and design of RESTful Web Services for supply chain activities, and
relevant technologies – ebXML specifications and UBL business documents.
• Implementation of a lightweight and integrated solution for supply chain
management using RESTful Web Services, ebXML framework, and UBL.
• Research of the resource modelling technique for RESTful Web Services.
1.5 Structure of the dissertation
• Chapter 2 conducts literature review of the project, and introduces background of
relevant technologies such Web Services, ebXML framework, UBL business
document library, and the SCOR model.
• Chapter 3 introduces research method, research approach, expected results and
limitations of this project first. Then it illustrates the business analysis of this
project.
• Chapter 4 describes the design of the prototype system including RESTful Web
Services design, ebXML framework design, and UBL document design.
• Chapter 5 unveils the implementation detail of the prototype system; knowledge
to Ruby language and Ruby on Rails web application framework is helpful to
understand some aspects of the implementation.
• Chapter 6 demonstrates the system testing procedure including command line
testing and GUI testing, and then it presents the evaluation of this project.
• Chapter 7 is the conclusion chapter, it summarises the study of this project, and
suggests some future work to improve the system.
19
Chapter 2 Background
The background chapter discusses and evaluates some of the current contemporary
technologies. Firstly, two approaches for Web Services are outlined, including a
traditional SOAP-RPC based one, and another alternative called RESTful Web Services.
Secondly, the ebXML framework comprising of a set of standards for e-Business
integration and collaboration, is described. Thirdly, the business document exchange
specification UBL is presented. Finally, the Supply-Chain Operations Reference-model
(SCOR) is introduced.
2.1 Web Services
2.1.1 SOAP and RESTful Web Services
The current generation of Web Services are built on SOAP with the intention of being an
interoperable protocol in the Internet world equivalent to the DCOM (Distributed
Component Object Model) or CORBA (Common Object Requesting Broker Architecture)
in the inter-application world. An example of a typical SOAP-RPC Web Services request
and response is shown in example 2-1. The customised request function ‘getinfo’ and its
parameter are defined by existing application and encapsulated in SOAP message
envelope’s ‘Body’ element, and the response information ‘getinfoResponse’ is also
customised and is embedded in SOAP message ‘Body’.
Example 2-1 SOAP-RPC Web Services request/response sample
Request:
POST /temp HTTP/1.1
Host: www.harddisk.com
Content-Type: application/soap+xml
SOAPAction: "http://www.harddisk.com/temp"
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/ soap-envelope">
<env:Body>
<m:getinfo env:encodingStyle="http://www.w3.org/200 3/05/soap-encoding"
xmlns:m="http://www.harddisk.com/">
<m:partnumber>HD-150G</m:partnumber>
</m:getinfo>
20
</env:Body>
</env:Envelope>
Response:
HTTP/1.1 200 OK
Content-Type: application/soap+xml
SOAPAction: "http://www.harddisk.com/temp"
<?xml version="1.0"?>
<env:Envelope xmlns:env=http://www.w3.org/2003/05/s oap-envelope>
<env:Body>
<m:getinfoResponse env:encodingStyle="http:// www.w3.org/2003/05/soap-encoding"
xmlns:m="http://www.harddisk.com/">
<Name>150G Harddisk</Name>
<Description>This part is 150GB 7200RPM SAT A Harddisk</Description>
<UnitCost currency="GBP">15</UnitCost>
</m:getinfoResponse>
</env:Body>
</env:Envelope>
As it can be seen from example 2-1, the URI used in SOAP-RPC approach is not to
identify the target resource, but rather to point to a SOAP server. An additional SOAP
server is required to look inside the SOAP message to check which resource is being
targeted as in Figure 2-1 [35] [36]. SOAP-RPC approach provides flexibility for business
partners to implement customised business functions, but this approach brings
complexity into the integration process because different suppliers may use different
interface names for a similar function e.g. getOrder, getOrderInfo, or retrieveOrder for an
order inquiry function. In general, when implementing Web Services in a family like
business community, SOAP-RPC approach is a rigorous solution to support mass
customisation and connect applications for business partners having long-term and
well-established business relationships. For example, Austrian Ministry Of Justice
worked with BundesRechenZentrum GmbH (BRZ) and IBM to deploy SOAP Web
Services interfaces for their web application service providers such as Telekom Austria
Group to enable complicated integration between external applications and internal
legacy systems, thus offering efficient Government to Business (G2B) and Government
to Citizen (G2C) services [42].
21
Figure 2-1 SOAP Web Services request to server
RESTful Web Services is getting popular because it is simple and based on REST
architectural style introduced by Dr. Roy Fielding in his PhD dissertation in 2000 which
outlines several design constraints behind the modern Web architecture [6] [34].
Architecture of the World Wide Web [34] is a W3C (World Wide Web Consortium)
recommendation published in 2004 to illustrate core design components of today’s Web
including identification of resources (URI), representation of resource state (e.g. HTML,
XHTML), and the protocols (e.g. HTTP) that formalise and support the interaction
between agents and resources in the Web’s information space [34]. URI is a cornerstone
of the Web which has been deployed successfully to build a global identification system
to enable information sharing across global communities. By design constraint, URIs
should identify a single resource and avoid URI collision by using the same URI to
identify different resources. Web agents may use a URI to access a referenced resource
through standardised interaction protocols e.g. HTTP. For example, retrieving a
representation of a resource (via HTTP GET), creating or updating a representation of a
resource (via HTTP POST or PUT), deleting a representation of a resource (via HTTP
DELETE). Data formats e.g. HTML, XHTML, and RDF/XML embody correct
interpretation of representation data, and a representation is data that present information
about resource state. Agents transfer representations across the Web via interaction
protocols to share information with any other peers. By promoting separation of content,
presentation, and interaction, the Web has become a heterogeneous environment where a
wide range of agents provide access to content to users with different capabilities [34].
22
Not surprisingly, REST is the architectural style behind the modern Web. REST treats
information as resource, and any information can be a resource such as a document, an
image, or a service [6]. REST identifies a particular resource by a unique resource
identifier to be used in an interaction between components. The additional constraint
distinguishes the REST style from other network-based architectural styles is the uniform
interface between components, which emphasises the generality of component interface.
Thus overall system architecture is simplified and implementations are decoupled from
the services they provide. REST components perform manipulation on a resource by
using a representation to capture state of that resource and transferring that
representation between components. All these design principles are all adopted in the
design of the modern Web, especially in specifications like HTTP and URI [6].
RESTful Web Services which conform to REST style use HTTP, URI and XML to
implement services to transfer XML documents between business partners. Example 2-2
shows a RESTful Web Service request and response sample. The request is just a simple
HTTP GET method to a specified URI, and the response is just a plain XML document.
Here, the XML document is representation of a product resource, and it is the purpose of
business interaction. Therefore RESTful Web Services reflect the document-centric view
which coheres better with the use case of applying services in open environment [33].
Example 2-2 RESTful Web Services request/response sample
Request:
GET /parts/HD_150G HTTP/1.1
Host: www.harddisk.com
Accept: application/xml
Response:
HTTP/1.1 200 OK
Content-Type: application/xml
<?xml version="1.0"?>
<part>
<id>HD_150G</id>
<Description>This part is 150GB 7200RPM SATA H arddisk</Description>
<UnitCost currency="GBP">15</UnitCost>
</part>
23
As shown in example 2-2, in RESTful Web Services, URI identifies the resource that is
desired (e.g. /parts/HD_150G), so a Web server can easily route the request based upon
the identified resource as in Figure 2-2. Furthermore, for RESTful Web Services with
explicit URI means system/network administrators can apply Access Control Lists
(ACLs) to secure services because each of them has a specific URI. Moreover, HTTP
method used in RESTful Web Services enables the administrators to protect services by
enforcing access control policies like disabling certain operations (e.g. PUT or DELETE).
The dotted lines in Figure 2-2 give an example of access control for RESTful Web
Services.
Figure 2-2 RESTful Web Services request to server
Amazon’s Simple Storage Service (S3) is a typical application of RESTful Web Services.
Amazon S3 provides storage for the Internet and makes web-scale computing easier for
everyone. It gives any user access to the same highly reliable, fast, and inexpensive
computing infrastructure that Amazon uses to run its own web sites in a global network
environment. The REST API of Amazon S3 is a simple HTTP interface which supports
standard HTTP requests to create (POST), read (GET), and delete (DELETE) buckets
and objects [43].
2.1.2 Business Model of Supply Chain is Document-centric
For more than two thousand years, information has been organised in meaningful and
self-descriptive package called document. From pottery to parchment, and paper to
24
electronic document, the technology used for encoding and exchanging documents has
advanced significantly. However, the concept of a document itself has remained
unchanged in most of the circumstances. Common models of business organisations such
as supply chains and business-to-business marketplaces can be assembled from simpler
two-party patterns of document exchanges [37].
The Internet and some related technologies like World Wide Web, XML and Web
Services bring great efficiencies and flexibility into business collaborations. But making
full uses of these new technologies involves viewing a document as an abstract model
and in a technology-neutral way. In a supply chain context, when a buyer asks a seller to
provide a product catalogue, or when a seller sends an invoice to a buyer, they focus on
what they need to accomplish through document exchanges. For this reason, enterprise
applications involving document exchanges should expose their business interfaces as
document-centric models so that they can interoperate in heterogeneous environments. A
document-centric philosophy uses patterns for document exchanges to ensure that
applications and services are robust and adaptable when technology or business
conditions change [37].
2.1.3 RESTful Web Services and Document Exchange enable Loose Coupling
A relationship is called loosely coupled when the participants avoid dependencies on
each other, so that any change made by one party has no impact on the other. RESTful
Web Services use URIs to identify resources (services) which is similar to the old and
classic loose coupling techniques – telephones and fax machines. Telephones and fax
machines enable businesses to exchange information with each other anywhere in the
world even if they have no existing relationship. One does not need to know the other’s
technical detail of telephone or fax equipment. International and industrial standards for
how these devices connect to the phone network make them same to the other side [37].
Likewise, RESTful Web Services use URIs to hide technical implementations.
Requesting agents do not need to understand the type of server software used to process
the request and send the responding representation data.
25
With Web Services alone can not easily extract the important information about the
business activity. Standardisation of document exchange is essential in maintaining a
loosely coupled relationship. Document exchange as a mechanism for business
transaction lets the business parties focus on what they want to achieve in business rather
than how they must technically do it. Two business organisations need mutual
understanding of the meaning of documents to be exchanged and on the business
processes carried out with them, but they do not need to know anything about the
technology the other party used to create and process the documents [37].
For instance, suppose a buyer sends a request for quote document to a seller; if the seller
can fulfil it, they respond with a quote response document. As long as the buyer and
seller agree on the meaning of each other’s documents and can generate and respond
with appropriate documents for each other’s business activities, they do not need to care
how they create the outgoing documents or how they process the incoming documents.
The documents are the technology-neutral and visible interfaces to their respective
business activities [37].
2.1.4 Resource Modelling for RESTful Web Services
The advantages of RESTful Web Services are that they are document-centric, relatively
easy to build, and trivial to test using a browser or common tools such as curl and wget.
However, REST is not a silver bullet, and REST emphasises a software design discipline
of many URIs and few methods [8]. Hence, the challenge to RESTful Web Services is to
find an effective mechanism to map business logics to resources and limited uniform
interfaces. This requires that application designers need to take a fundamental shift to
rethink their problems in terms of manipulations of addressable resources rather than the
traditional object-oriented way of manipulating objects and functions [8] [9]. This may
be the most difficult part to implement for the programmers who are familiar with the
RPC approach of integrating existing applications through unrestricted user-defined
APIs.
26
Therefore, this project investigates a resource modelling technique to help practitioners
of RESTful Web Services build up the application’s resource model. Since it is the
application’s responsibility to understand the format of information (i.e. content types),
this project focuses on the research of resource modelling on the identifier of the
resource, and the action required for an application to interact with a resource [10]. The
data flow modelling technique used in SSADM (Structured Systems Analysis and Design
Method) [11] provides a reference model for the resource modelling development,
because it shows the processing needed in an information system to maintain (create,
read, update, and delete) the data.
A data flow model is composed of processes, external entities, and data stores. Each data
flow from an external entity to a process can represent one of two operations: 1) an event
with data items to perform an update on the data, 2) a triggering of an enquiry on the data
[11]. These operations can be mapped to the HTTP GET, POST, PUT, and DELETE
methods based on the nature of the processes and links between processes and data stores.
In addition, data stores in the data flow model are the bases for constructing URIs of
resources in RESTful Web Services.
Furthermore, in RESTful Web Service, URI is the most important component which
expresses the resource exposed on the Web as a service. Currently, there is no formal
way to describe the basic model of RESTful Web Service URI. Therefore, this project
proposes a novel way to describe RESTful Web Service URI basic model by adopting
the metasyntax notation Extended Backus – Naur Form (EBNF) published in ISO/IEC
14977 [38]. In this proposal, an EBNF grammar is created to describe the basic model
for RESTful Web Service URI, and suggests a sophisticated way to build up the complex
query. This proposal does not involve the description of general portion of HTTP URI
format e.g. host name, domain name and port number because it has been defined
officially in RFC 2616 Hypertext Transfer Protocol – HTTP/1.1 [39]. Second, in this
project, the proposal follows common practice for object names (i.e. tables and columns
contain letters, digits and underscore only).
27
Following example 2-3 is simple sample of EBNF for describing normalised integer,
expressions that repeat zero-or-more time(s) can be represented through curly brackets
{…}, an optional expression is represented through squared brackets [...].
Example 2-3 EBNF sample sign = "+"|"-";
non_zero_digit = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"| "9";
digit = "0"|non_zero_digit;
normalised-integer = "0"|[sign], non_zero_digit, { digit};
2.2 ebXML – The e-Business Framework
Electronic Business is a buzzword in the ICT industry which covers all aspects of the
value chain. Electronic Business using eXtensible Markup Language (ebXML) is a joint
initiative by OASIS (Organization for the Advancement of Structured Information
Standards) and UN/CEFACT (United Nations/ECE agency CEFACT) to enable the
enterprises of any size to conduct businesses over the Internet; it defines a family of
XML-based specifications to support global use of electronic business transactions in an
interoperable manner by all trading partners [12].
Firstly, the ebXML Registry/Repository is a platform independent technology for storing
and sharing of business artefacts, discovering businesses, and facilitating business
exchanges via collaboration profiles [13]. To use an informal analogy, the ebXML
Registry/Repository is to digital artefacts, what a library is to books. While the registry is
analogous to the index of books in the library, the repository is analogous to the book
shelves in the library [14] [15]. For Web Services, ebXML Registry/Repository can be
used as a database to publish and discover services, thus enabling cooperation across
organizational boundaries. ISO has approved the ebXML Registry as an ISO standard
under name of ISO/TS 15000, parts 3 and 4 [16].
Secondly, ebBP (ebXML Business Process), previously called the ebXML Business
Process Specification Schema (ebBPSS), is an OASIS technical specification for
designing collaborative business processes [17]. It defines a standard process definition
28
language to configure business systems to support the collaboration between partners
rather than the processing accomplished within one individual business entity [18]. An
ebBP definition describes interoperable business processes that allow collaborating
parties to cooperate and achieve a shared business objective, which contains business
roles, business documents exchanged in a business transaction, and choreography of
business transaction(s) that comprise business collaboration [19]. Web Services software
components can be specified to work with ebBP technical specification to execute
business collaborations effectively.
Finally, the ebXML Collaboration Protocol Profile and Agreement (ebCPPA, aka ISO/TS
15000-1) standard provides two sets of information for business collaborations. One set –
CPP (Collaboration Protocol Profile) expresses data about a single business partner’s
technology capabilities such as delivery channels and transport bindings to engage in
e-Business collaborations with other partners. The second set – CPA (Collaboration
Protocol Agreement) defines the capabilities that two parties have agreed bilaterally to
use in the business collaboration protocols [20].
An overview of the OASIS ebXML e-Business framework is shown in Figure 2-3. The
first step is to design the business process model for a specific industry. Then, the second
step is about implementing and registering the profiles (CPPs). After reaching the
agreement (CPA), the partners can exchange business documents.
Figure 2-3 OASIS ebXML framework Overview
29
2.3 Standard Business Vocabulary – Universal Business Language
Documents are widely used in business transactions such as orders and invoices. Every
document has its purpose and contains adequate information for a particular transaction.
It provides the interfaces for people and interfaces to business processes. XML has been
accepted as the standard mechanism for document exchange. But, in order to conduct
business, partners need to understand the semantics of the documents. Universal
Business Language (UBL) is a language to capture business information and abstract
common patterns of business documents. It is an international initiative to define an open
royalty-free standard XML documents library for e-Business which is developed by an
experienced and accountable OASIS technical committee with a variety of industry
participants [21].
The OASIS UBL specification is intended to meet the requirements of industries by
defining a generic extensible XML vocabulary for business documents interchange.
Specifically, UBL consists of the following elements: (1) a library of XML schemas for
frequently-used data components of everyday business documents such as ‘Address’,
‘Item’, and ‘Price’, (2) a set of XML schemas that are composed by the UBL library
components for common business documents such as ‘Order’, ‘Despatch Advice’, and
‘Invoice’ which can be used in generic supply chain context [22]. UBL is the first
international implementation which is compliant with the ebXML Core Components
Technical Specification (i.e. ISO/TS 15000-5). UN/CEFACT has recognised UBL as the
first-generation XML documents for e-Business collaboration which means UBL can be
safely adopted for now and into the future [21].
Example 2-3 is a simple UBL Quotation document. Two important concepts here are the
‘cbc’ (Common Basic Components) and ‘cac’ (Common Aggregate Components)
schemas. The former defines the Basic Business Information Entities (BBIEs) that are
used as ‘leaf nodes’ throughout UBL, and the latter defines the Aggregate Business
Information Entities (ABIEs) that are used to construct the main documents [22].
30
Example 2-4 OASIS UBL Quotation document sample
<?xml version="1.0" encoding="UTF-8"?>
<Quotation xmlns="urn:oasis:names:specification:ubl :schema:xsd:Quotation-2"
xmlns:cbc="urn:oasis:names:specification:ubl:s chema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:s chema:xsd:CommonAggregateComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-in stance"
xsi:schemaLocation="urn:oasis:names:specificat ion:ubl:schema:xsd:Quotation-2
UBL-Quotation-2.0.xsd">
<cbc:ID>1</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cbc:Note>Sample</cbc:Note>
<cac:RequestForQuotationDocumentReference>
<cbc:ID>G867B</cbc:ID>
</cac:RequestForQuotationDocumentReference>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:QuotedMonetaryTotal>
<cbc:PayableAmount currencyID="GBP">27300< /cbc:PayableAmount>
</cac:QuotedMonetaryTotal>
<cac:QuotationLine>
<cbc:ID>1</cbc:ID>
<cbc:Note>Sample line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:Quantity unitCode="EA">100</cbc:Q uantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP"> 45</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>
Seagate(R) Barracuda(TM) 250 GB Internal hard drive
</cbc:Description>
<cbc:ModelName>SGBARHD250G </cbc:M odelName>
</cac:Item>
</cac:LineItem>
</cac:QuotationLine>
</Quotation>
31
2.4 The SCOR Model
Supply-Chain Operations Reference-model (i.e. SCOR) is a de facto standard reference
model for supply chain management across the whole industry [23]. It has been
developed by the Supply-Chain Council to establish a unique framework to define
business process into a unified structure to support the communication between business
partners and to improve the productivity of the entire supply chain. SCOR has been
designed to use common process building blocks to describe simple or complex supply
chain activities, thus enabling all interested parties to be linked to describe the operations
of virtually any supply chain [24]. Table 2-1 shows some components in the three levels
of the SCOR model.
Level Description Components
1 – Top Level Process Types Plan (P), Source (S), Make (M), Delivery (D),
Return (R)
2 – Configuration Level Process Categories D1 – Delivery Stocked Product
D2 – Delivery Make-to-Order Product
D3 – Delivery Engineer-to-Order Product
3 – Process Element Level Decompose Processes D1.1: Process Inquiry & Quote
D1.2: Receive, Enter & Validate Order
D1.11: Load Product & Generate Shipping Docs
D1.13: Receive & Verify Product by Customer
D1.15: Invoice
Table 2-1 Supply-Chain Operations Reference-model
As indicated in table 2-1 showing three levels of supply chain process detail, the SCOR
model is hierarchical. For example, D1.2 is a notation that represents a third level
process element. In this case, it is a Delivery (D = Level 1 Delivery) element that is
concerned with delivering stocked product (D1 = Level 2 Deliver Stocked Product), and
is specific to receiving and validating order (D1.2 = Level 3 Receive, Enter & Validate
Order).
32
2.5 Summary
This chapter has described the background of relevant technologies including two views
of Web Services – RPC-centric view and document-centric view; ebXML e-Business
framework components – Registry/Repository, Business Process, and Collaboration
Profile and Agreement; the XML document-based business language UBL, and the
SCOR supply chain reference model. Next chapter presents the investigation methods
and system analysis used in this project.
33
Chapter 3 Investigation Methods and Business Analysis
This chapter outlines the research methodology and approach at first. Then, the expected
results and limitations are discussed in section 3.3 and 3.4 respectively. Finally, business
analysis of the project is conducted in the last section.
3.1 Research Methodology
The constructive research methodology is adopted for this project. The constructive
research approach is a typical research procedure in computer science field for designing,
implementing, and evaluating a software construction, intended to solve domain
problems faced in real world, and by that means, to create knowledge and make a
contribution to the theory of discipline [25]. The constructive research methodology
includes practical relevance and theoretical relevance, the former indicates that the
construction should produce a solution for a domain problem in practice; the latter
indicates that the research should generate some related theoretical knowledge to refine a
theory, even develop a new one. By using the constructive research methodology, this
project will analyse, design, and implement an integrated solution for supply chain
management with document-centric and lightweight RESTful Web Services, and the
open royalty-free standards ebXML and UBL. Meanwhile, the project is investigating a
novel resource modelling technique as an improvement for RESTful Web Services
development.
This project uses another common methodology in computer science – software
prototyping to implement the solution. A software prototype is different from a full-scale
software system; it is just a partial implementation of a system with the purpose of
exploring the problem to be solved or testing a solution to that problem. In particular, the
experimental prototyping approach is used for this project to verify a possible solution to
the domain problem [26]. In experimental prototyping, the basic functionality is
understood but some of design issues need to be resolved. An experimental prototype can
implement any subset of the target system. This project only focuses on several process
34
elements in the delivery process of the entire supply chain operations reference model.
3.2 Research Approach
The research approach of this project is divided into three phases including analysis,
design, and implementation.
3.2.1 Analysis
Computerised business information systems do not exist in isolation. They are developed
to help and support the main business functions of an organisation. In order to design a
computerised business system inerrably, we must first to understand and analyse the
business context which the system will reside. This project uses Requirements Catalogue
and Business Activity Modelling techniques to help ensure that the final system meets
the requirements and fits the objectives of an organisation [11]. The SCOR reference
model for supply chain management is referred in the analysis process.
3.2.2 Design
The design phase transforms the requirements gathered during the analysis phase into a
computer system design, which details what the system is required to do [11]. This
project is decomposed into a Web Services design task, a business process design task, a
collaboration profile and agreement design task, and a business document design task.
The design of RESTful Web Services for supply chain management forms the basis of
the design phase. The REST architectural style for Web Services development for supply
chain management is investigated to suggest a model in which individual data sources
and services can be tied together on demand to generate a desired result with minimal
effort. Orchestrating a different configuration with new processes or partners will not be
costly and complicated. Every raw material in the system (i.e., data) can be identified as
a resource and referenced via the identifier of resource. By analysing the concepts of
modern Web architecture described in Dr. Roy Fielding’s thesis [6], it is sensible for
enterprises to implement and expose URI-addressable RESTful Web Services to external
35
partners, thus supporting sophisticated supply chain collaboration across organisational
boundaries.
Particular design is conducted for the resource modelling technique for RESTful Web
Services development. In a RESTful application, resource is the key abstraction of
information, and the uniform interface between components is a unique feature [6]. The
challenge for a RESTful Web Services design is to model the business processes around
resources and few methods. Therefore, this project analyses the data flow modelling,
which is a technique for graphically representing the processes on data stores including
creating a new an entity (add), retrieving an entity (read), updating an entity (change or
modify), and deleting an entity.
Ancillary designs are performed on ebXML framework for e-Business and UBL
specification. Within the ebXML framework, the ebBP Business Process specification,
and the ebCPPA Collaboration Protocol Profile and Agreement standard are studied. For
UBL, the theoretical rationale is analysed in general, and documents needed to support
business processes are investigated for the implementation of this project.
3.2.3 Implementation
The system design provides the architecture, components, modules, interfaces, and data
for building and testing the new system. It is during the implementation phase, the design
is converted into computing source code as a program, software component, or other
computer system. This project delivers following main components:
• A prototype of RESTful Web Services for supply chain management, this
includes: 1) a set of Web Services for the seller to process the item inquiry,
respond to quote, receive new order, process order e.g., inquiry, cancellation or
change, and receive receipt advice from the buyer, 2) a couple of Web Services
for the buyer to process despatch advice from seller, process receipt advice from
third party warehouse operator, and receive invoice from seller, and 3) a Web
Service for the third party warehouse operator to receive despatch advice from
buyer.
36
• A prototype of RESTful clients, which includes: 1) a client for the buyer to
inquire item information, issue quote, place order, review, change or cancel order,
2) a client for the seller to despatch order, and send invoice, and 3) a client for
the third party warehouse to process and send receipt advice.
• An ebXML Registry/Repository server is implemented to provide the storage for
sharing business process document, collaboration profiles and agreements, and
relevant document schemas.
3.3 Expected Results
The analysis, design, and implementation of this project are used to test the following
expected results:
• It is possible to use document-centric and lightweight RESTful Web Services to
implement a sophisticated supply chain solution.
• It is possible to derive a resource modelling technique for RESTful Web Services
development from the data flow modelling technique.
• It is possible to apply the Universal Business Language (UBL) as a common
business vocabulary for the supply chain interactions.
3.4 Limitations
This project has following limitations:
• The scope of this project only covers a few process elements of one subset of
delivery process in the SCOR model. The implementation of complete SCOR
model would be more complex.
• The research of resource modelling technique focuses on the identifier of
resource and application interfaces, and uses XML as the sole representation.
• This project just uses the public samples of CPP, CPA, and UBL from the OASIS
web sites as the templates with slightly modification to test various scenarios in
the project.
• The HTTP basic security/authentication is adopted, while in real world, more
sophisticated security/authentication mechanism is enforced.
37
3.5 Business Analysis
3.5.1 Requirements Definition
The objective of system analysis is to identify and describe the requirements of the new
system. In other words, we must first define what is required for the system to do before
starting to design how the system will work. In SSADM, descriptions of requirements
are recorded in a central Requirements Catalogue which is cross-referenced with other
techniques. The catalogue is largely text-based, covers all aspects of the new system in
detail, and acts as a primary reference document for other steps [11]. Table 3-1 shows the
Requirements Catalogue for this project.
Requirements Catalogue
Requirement ID 001
Requirement Name Process Item Inquiry
Description Inquiry function providing item information, including item id, item
description, and item price and so on. There are three types of item
inquiries; they are item list, item detail, and specific items.
Reference Source SCOR model D1.1 – Process Inquiry & Quote
Owner Seller
Related Document UBL Catalogue XML document
Requirement ID 002
Requirement Name Process Quote
Description Quote function processing request for quote from buyer, and sending the
quote message back
Reference Source SCOR model D1.1 – Process Inquiry & Quote
Owner Seller
Related Document UBL Request for Quote and Quote XML documents
Requirement ID 003
Requirement Name Process Order
38
Description Order function processing order request from buyer, and sending the order
response back
Reference Source SCOR model D1.2 – Receive, Enter & Validate Order
Owner Seller
Related Document UBL Order and Order response XML documents
Requirement ID 004
Requirement Name Order Inquiry
Description Order inquiry function providing order information, including order id,
order note, address etc. There are three types of order inquiries; they are
order list, order detail, and specific orders.
Reference Source SCOR model D1.2 – Receive, Enter & Validate Order
Owner Seller
Related Document UBL Order response XML document
Requirement ID 005
Requirement Name Order Cancel
Description Order cancel function allowing a particular order to be cancelled by buyer
Reference Source SCOR model D1.2 – Receive, Enter & Validate Order
Owner Seller
Related Document Not Applicable
Requirement ID 006
Requirement Name Order Change
Description Order change function giving buyer the ability to change an existing order
by submitting an order change request
Reference Source SCOR model D1.2 – Receive, Enter & Validate Order
Owner Seller
Related Document UBL Order change and Order response XML documents
39
Requirement ID 007
Requirement Name Process Despatch Advice
Description Buyer processes despatch advice sent by seller, and forwards it to the third
party warehouse operator
Reference Source SCOR model D1.11 – Load Product & Generate Shipping Docs
Owner Buyer
Related Document UBL Despatch advice XML document
Requirement ID 008
Requirement Name Receive Despatch Advice
Description Third party warehouse operator receives despatch advice forwarded by
buyer
Reference Source SCOR model D1.11 – Load Product & Generate Shipping Docs
Owner Third party warehouse operator
Related Document UBL Despatch advice XML document
Requirement ID 009
Requirement Name Process Receipt Advice
Description Buyer processes receipt advice completed by third party warehouse
operation, and forwards it to seller
Reference Source SCOR D1.13 – Receive & Verify Product by Customer
Owner Buyer
Related Document UBL Receipt Advice XML document
Requirement ID 010
Requirement Name Receive Receipt Advice
Description Seller receives receipt advice sent by buyer, and prepares the invoice for
buyer
Reference Source SCOR D1.13 – Receive & Verify Product by Customer
Owner Seller
40
Related Document UBL Receipt Advice XML document
Requirement ID 011
Requirement Name Receive Invoice
Description Receive invoice function processing invoices sent by seller
Reference Source SCOR D1.15 – Invoice
Owner Buyer
Related Document UBL Invoice XML document
Table 3-1 Requirements Catalogue
3.5.2 Business Activity Modelling
Business Activity Modelling is a technique for analysing the activities that are supported
by business information system. Because it is necessary to prevent delivering a wrong
system to users, it is recommended by SSADM as an essential step in the task for
constructing the right system [11]. This project illustrates typical B2B
(Business-to-Business) trading activities conducted by business partners. It involves
three kinds of parties: the buyer (PC Manufacturer), the seller (Computer Hardware
Components Supplier), and the third party warehouse operator as shown in Figure 3-1.
Business activity model outlines the business context and scope of the prototype. The
business activity modelling technique comprises a diagram describing the business
activities and their relationships, and complemented by a textual documentation about
the business events and rules. The relationships between activities indicate that each
activity is responsible for transferring information to other activity. The purpose of
business activity modelling is to provide the basis for constructing the new system by
depicting the distinct activities, events and rules [11]. This project uses the UML Activity
Diagram to model the business activities between three parties as illustrated in following
Figure 3-1.
41
Figure 3-1 Business Activity Model
42
Similar to most system analysis methods, business activity modelling focuses on finding
out the high-level picture of the system, and what the users can do in the context of
business environment. For this project, the business activities can be categorized into
several groups:
• Item information inquiry. First of all, the buyer needs to find out information
about item(s) (Activity 1). There are three types of item information the buyer
may be interested in: 1) the item list for sale, 2) the detail information for one
particular item e.g. description, list price and specification, and 3) the items
matching certain criteria. According to the item information retrieved from the
sellers (Activity 2, 3), the buyer may place an order immediately (Activity 7), or
issue a quote for special price (Activity 4), or just hold back.
• Request for Quote. The buyer may not satisfy with the list price offered by the
seller. So in day-to-day businesses, it is quite common for the buyer to issue a
quote to seller for special price (Activity 4). For example, the buyer may order a
large amount of one item, or they want to place one package order with
considerable value. In both cases, the buyer is expecting a special discount. Base
on the response from the seller (Activity 5, 6), the buyer may go to send a new
order, or just walk away.
• Order processing. If the buyer accepts the price of product, they will send order
to the seller with certain information e.g. item number, quantity and request date
(Activity 7). The seller will then return the new created order number to buyer
(Activity 8) for inquiry later on (Activity 9 – 12). Depending on the seller’s
business rules, the buyer may be able to cancel (Activity 13 – 15) or change
(Activity 16 – 18) the order they have placed.
• Delivery. The seller will deliver the order according to request date to the buyer,
and send the despatch advice to them (Activity 19). Then, the buyer will process
the despatch advice and pass it on to their 3rd party warehouse operator (Activity
20). The 3rd party warehouse operator will check the despatch advice with the
actual goods they received (Activity 21), and send the receipt advice to the buyer
(Activity 22). After processing the receipt advice in their system (Activity 23),
the buyer will return the receipt advice back to the seller (Activity 24).
43
• Invoicing. The seller then will send the invoice to the buyer (Activity 25) by
examining the order, despatch advice and receipt advice. Buyer receives invoice
(Activity 26), and will pay the seller in another accounting system (out of scope
of this project).
3.6 Summary
This chapter briefly introduced the constructive research and software prototype
methodologies, and research approach including analysis, design, and implementation of
this project. Then it discussed the expected results and limitations of the project. At last,
requirement catalogue and business activity modelling techniques for doing business
analysis of this project were elaborated. Following chapter goes into the design stage of
the project.
44
Chapter 4 Prototype Design
This chapter describes the design of the prototype. It illustrates the overall architecture of
the prototype and design tasks. There are several design tasks for developing the
prototype. First, the design of RESTful Web Services providers and requestors is a
primary task. In order to describe the design of RESTful Web Services properly, a
resource modelling technique and a basic model of URI used in RESTful Web Services
are suggested in this project. Second, the design tasks of ebXML framework and UBL
documents focus on logical design aspects rather than detailed physical implementations.
4.1 System Architecture Overview
The prototype of this project involves three actor roles: buyer, seller, and buyer’s third
party warehouse operator. These actors all have separate systems to interact with each
other through the Internet platform (by using HTTP, URI and XML), and they publish
and discovery business artefacts e.g. ebBP business document, ebCPPA profiles and
agreements in the online ebXML Registry. Figure 4-1 shows user case of prototype
architecture.
Figure 4-1 Prototype Architecture
45
4.2 System Design
4.2.1 RESTful Web Services Design
For the sake of simplicity, every activity needs to be exposed as RESTful Web Service in
the business activity model (Figure 3-1) is decomposed into a data flow diagram (DFD),
and then the DFD is converted to a resource model of RESTful Web Service. There are
several rules for converting a DFD to a resource model in this project:
• Data store name in DFD is used as identifier of a collection of resources.
• If a business process is to retrieve information only, it should use HTTP GET
method.
• If a business process is to create a new member resource, HTTP POST method is
recommended.
• If a business process is to update an existing member resource, it should call
HTTP PUT method.
• If a business process is to delete an existing member resource, HTTP DELETE
should be used.
• There are three types of resources in the prototype: collection of resources,
individual member resource, and specific list of resources. Member resource and
specific list of resources use curly bracket to enclose variable resource identifiers.
• External entity name remains same in DFD and resource model.
• Process label in resource model begins with ‘R’ means it is a resource identifier.
4.2.1.1 The Seller System
The seller system is involved in most of the business processes in the prototype. It
provides services from item inquiry to order management. Following figures and
paragraphs illustrate DFD and resource model of each service in detail.
Item Inquiry
ResponseBuyer ItemsD1
1
Process Item Inquiry
Figure 4-2 DFD – Process Item Inquiry
In DFD above, the external entity ‘Buyer’ represents a customer or client who wants to
46
buy something from a seller. They send ‘Item Inquiry’ request to seller’s ‘Process Item
Inquiry’ business function to get item information (Figure 3-1, Activity 2). The ‘Item
Inquiry’ can be in one of three forms: 1) buyer wants to have the whole list of items on
sale, 2) buyer wants to get information about a specified item, or 3) buyer wants to know
the items by defining certain conditions. The ‘Process Item Inquiry’ function then
retrieves information from ‘Items’ data store according to the type of ‘Item Inquiry’, and
returns it back to buyer e.g. a list of items, or detail item information.
HTTP GET
Buyer ItemsD1
R1.1
/itemsResponse
R1.2
/items/{itemid}
R1.3
/items?{querystring}
HTTP GET
Response
HTTP GET
Response
Figure 4-3 RESTful Resource Model – Process Item Inquiry
The Process Item Inquiry Web Service provides item information for buyer to inquire, it
includes three resources URIs:
• R1.1: /items, buyer issues a HTTP GET request to this URI, and the server
returns a list of items by XML contains item id, price, and description to buyer.
• R1.2: /items/{itemid}, buyer issues a HTTP GET request to this URI with a
specified item id, and the server returns detail information of that item in XML.
• R1.3: /items?{querystring}, buyer issues a HTTP GET request to this URI with a
query, the server returns a list of items matched the query criteria in XML format.
Quote Detail
ResponseBuyer
2
Process QuoteQuotesD2
Figure 4-4 DFD – Process Quote
In DFD above, buyer sends quote detail e.g. item number and quantity to seller’s
47
‘Process Quote’ business function. Then ‘Process Quote’ function returns response
quotation with special price to buyer base on the business rules implemented by seller e.g.
quantity discount or order amount discount, and writes the new quote to the ‘Quotes’
data store (Figure 3-1, Activity 5).
HTTP POSTBuyer QuotesD2
R2
/quotesResponse
Figure 4-5 RESTful Resource Model – Process Quote
The Process Quote service provides the quotation information for the buyer:
• R2: /quotes, buyer issues a HTTP POST request to this URI with a request for
quotation XML document, and the server returns quotation response in XML.
Order Detail
ResponseOrdersD3Buyer
3
Process Order
Figure 4-6 DFD – Process Order
In DFD above, buyer sends a new order to seller’s ‘Process Order’ business function.
The ‘Process Order’ function validates the incoming order detail and saves it to ‘Orders’
data store, then returns the response with new order number to buyer (Figure 3-1,
Activity 8).
HTTP POSTBuyer OrdersD3
R3
/ordersResponse
Figure 4-7 RESTful Resource Model – Process Order
The Process Order service provides the function for buyer to place order to seller:
• R3: /orders, buyer issues a HTTP POST request to this URI with an order XML
document, and the server returns response with the new order in XML.
48
Order Inquiry
ResponseBuyer
4
Process Order InquiryOrdersD3
Figure 4-8 DFD – Process Order Inquiry
In DFD above, buyer sends ‘Order Inquiry’ request to seller’s ‘Process Order Inquiry’
business function to get order information (Figure 3-1, Activity 11). There are three types
of inquiries of ‘Order Inquiry’: 1) buyer needs to get a list of orders they have placed, 2)
buyer needs to check information about a particular order, or 3) buyer needs to find the
orders matching specified criteria. The ‘Process Order Inquiry’ function then looks up
the ‘Orders’ data store to retrieve information according to the type of ‘Order Inquiry’,
and returns it back to buyer e.g. list of orders, or detail order information.
Buyer OrdersD3
R4.1
/orders
R4.2
/orders/{orderid}
HTTP GET
Response
R4.3
/orders?{querystring}
HTTP GET
Response
HTTP GET
Response
Figure 4-9 RESTful Resource Model – Process Order Inquiry
The Process Order Inquiry service provides order list or one order detail for buyer to
inquire:
• R4.1: /orders, buyer issues a HTTP GET request to this URI, and then the server
returns a list of orders by XML contains order number can be used to retrieve
order detail information.
• R4.2: /orders/{orderid}, buyer issues a HTTP GET request to this URI with a
specified order id, and the server returns detail information of that order in XML.
• R4.3: /orders?{querystring}, buyer issues a HTTP GET request to this URI with a
query, the server returns a list of orders matched query criteria in XML format.
49
Response
Order CancellationBuyer
5
Order CancellationOrdersD3
Figure 4-10 DFD – Order Cancellation
In DFD above, buyer sends an order cancellation request to seller’s ‘Order Cancellation’
business function. The ‘Order Cancellation’ function validates the request and decides
whether the order can be cancelled base on the business rules, and then returns response
message to buyer. If the order can be cancelled, it deletes the order from ‘Orders’ data
store (Figure 3-1, Activity 14).
Buyer OrdersD3
R5
/orders/{orderid}
HTTP DELETE
Response
Figure 4-11 RESTful Resource Model – Order Cancellation
The Order Cancellation service provides the function for buyer to delete the order
placed:
• R5: /orders/{orderid}, buyer issues a HTTP DELETE request to this URI with a
specified order id, the server removes the order according to business rules, and
returns response message.
Order Change
ResponseBuyer
6
Order ChangeOrdersD3
Figure 4-12 DFD – Order Change
In DFD above, buyer sends an order change request to seller’s ‘Order Change’ business
function. The ‘Order Change’ function validates the request and checks the order status
to see whether the order can be changed according to the business rules, then returns
response message to buyer. If the order can be changed, it modifies the order in ‘Orders’
data store (Figure 3-1, Activity 17).
50
Buyer OrdersD3
R6
/orders/{orderid}
HTTP PUT
Response
Figure 4-13 RESTful REST Resource Model – Order Change
The Order Change service provides the function for buyer to modify the order placed:
• R6: /orders/{orderid}, buyer issues a HTTP PUT request to this URI with a
specified order id, the server updates the order according to business rules, and
returns updated order information in XML.
Receipt Advice
ResponseBuyer
10
Receive ReceiptAdvice
Receipts(Seller)D7
Figure 4-14 DFD – Receive Receipt Advice
In DFD above, buyer passes receipt advice information to seller’s ‘Receive Receipt
Advice’ business function. The ‘Receive Receipt Advice’ function returns response back
to buyer, and then updates the new receipt advice to seller’s ‘Receipts’ data store (Figure
3-1, Activity 24).
HTTP POSTBuyer Receipts(Seller)D7
R10
/receiptsResponse
(At the Seller server side)
Figure 4-15 RESTful Resource Model – Receive Receipt Advice
The Receive Receipt Advice service provides the function for buyer to forward receipt
advice information to seller:
• R10: /receipts, buyer issues a HTTP POST request to this URI with a receipt
advice XML document, and the server returns response message.
4.2.1.2 The Buyer System
The buyer system in this project is responsible for forwarding despatches to third party
warehouse, forwarding receipts to buyer, and receiving invoices from seller. Following
figures and paragraphs give detail designs of RESTful Web Services provided by the
buyer system.
51
Despatch Advice
ResponseSeller
7
ProcessDespatch Advice
Despatches(Buyer)
D4
Figure 4-16 DFD – Process Despatch Advice
In DFD above, seller sends the despatch advice information e.g. items, quantities shipped
and delivery date to buyer’s ‘Process Despatch Advice’ business function. Then ‘Process
Despatch Advice’ function returns response message to seller, and writes the new
despatch advice to buyer’s ‘Despatches’ data store (Figure 3-1, Activity 20).
HTTP POSTSeller
Despatches(Buyer)
D4
R7
/despatchcesResponse
(At the buyer server side)
Figure 4-17 REST Resource Model – Process Despatch Advice
The Process Despatch Advice service provides the despatch advice information from
seller to buyer:
• R7: /despatches, seller issues a HTTP POST request to this URI with a despatch
advice XML document, and the server returns the response message.
Receipt Advice
Response3rd WH
9
Process ReceiptAdvice
Receipts(Buyer)D6
Figure 4-18 DFD – Process Receipt Advice
In DFD above, third party warehouse operator sends receipt advice information e.g.
items and quantities received to buyer’s ‘Process Receipt Advice’ business function. The
‘Process Receipt Advice’ function returns response to third party warehouse, and then
writes new receipt advice to buyer’s ‘Receipts’ data store (Figure 3-1, Activity 23).
HTTP POST3rd WH Receipts(Buyer)D6
R9
/receiptsResponse
(At the buyer server side)
Figure 4-19 REST Resource Model – Process Receipt Advice
The Process Receipt Advice service provides receipt advice information from third party
52
warehouse operator to buyer:
• R9: /receipts, third party warehouse operator issues a HTTP POST request to this
URI with a receipt advice XML document, and the server returns response
message.
Invoice
ResponseSeller
11
Receive InvoiceInvoicesD8
Figure 4-20 DFD – Receive Invoice
In DFD above, seller sends invoice to buyer’s ‘Receive Invoice’ business function. The
‘Receive Invoice’ function returns the response to seller, and creates the new invoice to
‘Invoices’ data store (Figure 3-1, Activity 26).
HTTP POSTSeller InvoicesD8
R11
/invoicesResponse
Figure 4-21 REST Resource Model – Receive Invoice
The Receive Invoice service provides the invoice information from seller to the buyer:
• R11: /invoices, seller issues a HTTP POST request to this URI with a new
invoice XML document, and the server returns the response message.
4.2.1.3 The Third Party Warehouse System
The third party warehouse system is relatively simple in this project as shown below.
Despatch Advice
ResponseBuyer
Despatches(3rd WH)
D5
8
ReceiveDespatch Advice
Figure 4-22 DFD – Receive Despatch Advice
In previous DFD, buyer forwards despatch advice information to third party warehouse
operator’s ‘Receive Despatch Advice’ business function. Then ‘Receive Despatch
Advice’ function returns the response to buyer, and updates the new despatch advice to
the operator’s ‘Despatches’ data store (Figure 3-1, Activity 21).
53
HTTP POSTBuyer
Despatches(3rd WH)
D5
R8
/despatchesResponse
(At the 3rd PartyWarehouse server side)
Figure 4-23 REST Resource Model – Receive Despatch Advice
The Receive Despatch Advice service provides the function for buyer to forward the
despatch advice information to third party warehouse operator:
• R8: /despatches, buyer issues a HTTP POST request to this URI with a despatch
advice XML document, and the server returns response message.
4.2.1.4 Basic Model for URI in RESTful Web Services
According to the designs of RESTful Web Services, there are three forms of URI
involved in this project. In order to describe these types of URI in a formal format, an
EBNF grammar is created to represent a basic model of URI in RESTful Web Services.
Example 4-1 EBNF Grammar for Basic Model of URI in RESTful Web Services 01:REST_URI = "/", Collection, [("/", Member)|(" ?", QueryString)];
02:Collection = Character1, {Character1};
03:Member = Character1, {Character1};
04:QueryString = ConditionExpression, {SP, JoinSym bol, SP, ConditionExpression};
05:ConditionExpression= Condition|ConditionGroup;
06:JoinSymbol = "AND"|"and"|"OR"|"or";
07:Condition = Name, ComparisonSymbol, Value;
08:ConditionGroup = "(", QueryString, ")";
09:Name = Character1, {Character1};
10:ComparisonSymbol = (("<"|">"),["="])|(["!"], "=" );
11:Value = ("'", Character2, {Character2}, "'")| (Digitlist, [".", Digitlist]);
12:Character1 = Letter|Digit|Underscore;
13:Character2 = Character1|Otherchar;
14:Digitlist = Digit, {Digit};
15:Letter = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|" j"|"k"|"l"|"m"
|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"| "y"|"z"
|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"| "L"|"M"
|"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"| "Y"|"Z";
16:Digit = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|" 9";
17:Underscore = "_";
18:Otherchar = "~"|"!"|"@"|"#"|"$"|"^"|"&"|"*"|"( "|")"|"+"|"-"|"="
|"{"|"}"|"["|"]"|"|"|"<"|">"|","|"."|":"|";"| "?"|"/"|SP;
19:SP = " ";
54
In example above, ‘Collection’ and ‘Member’ contain one or more characters from
character set 1 which includes letter, digit or underscore. ‘QueryString’ is a set of
conditions joined together by following the rest of rules, and ‘Value’ in the ‘Condition’
rule can have any character from character set 2 including some other special characters.
Example 4-2 shows several samples of URI conform to the EBNF grammar defined
above.
Example 4-2 Samples of URI 1. Collection: /items
2. Member: /items/1
3. QueryString: /items?(brandname='Intel' OR brandn ame='AMD') AND priceamount<110
In the case of third sample in example 4-2, rule ‘REST_URI’ is applied first (“/”), and
then followed by ‘Collection’ rule (“items”). After that, rule ‘QueryString’ is selected
(“?”), and then ‘ConditionGroup’ (“(brandname=’Intel’ OR brandname=’AMD’)”) and
‘Condition’ (“priceamount<110”) rules are used subsequently.
4.2.2 ebBP Design
From a high level point of view, an ebBP instance specifies all the business documents
that are exchanged between business collaboration roles. An ebBP instance typically is
composed of several elements including Business documents, Business collaborations,
Business transactions, and Business roles [13]. Figure 4-24 shows the basic structure of
ebBP instance this project is adopted. Solid lines in figure 4-24 represent the parent/child
relationship between elements, and dotted lines represent the reference relationship
between elements.
This project uses FreebXMLBP editor [40] to design the ebBP instance for the fictional
SCM scenario. Figure 4-25 shows the screen of FreebXMLBP editor, and example 4-3
shows excerpt of the ebBP instance, the complete ebBP instance document is available in
appendix.
55
Business Collaboration
Business Transaction Activity
Roles
Business Transaction
RequestingBusinessActivity RespondingBusinessActivity
Performs Roles
Business Document
Requesting Role Responding Role
Document Envelope
Figure 4-24 Basic structure of ebBP instance
Figure 4-25 FreebXMLBP Editor
Example 4-3 Sample ebBP instance document <?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification xmlns="http://docs.oasis-open .org/ebxml-bp/ebbp-2.0"...>
<BusinessDocument name="OrderBD" nameID="Order BD_ID">
<Specification name="OrderBDSchema" nameID="OrderBD Schema_ID"
location="http://localhost/xsd/UBL-Order-2.0.xsd" t ype="schema"/>
</BusinessDocument>
<BusinessDocument name="OrderResBD" nameID="Or derResBD_ID">
<Specification name="OrderResBDSchema" nameID="Orde rResBDSchema_ID"
56
location="http://localhost/xsd/UBL-OrderResponse-2. 0.xsd" type="schema"/>
</BusinessDocument>
...
<Package name="SimpleSCMPK" nameID="SimpleSCMP K_ID">
<BusinessCollaboration isInnerCollaboration="false" name="SimpleSCMBC"
nameID="SimpleSCMBC_ID">
<Role name="Buyer" nameID="Buyer_ID"/>
<Role name="Seller" nameID="Seller_ID" />
<Role name="ThirdWH" nameID="ThirdWH_I D"/>
<TimeToPerform/>
<Start name="Start of Collaboration Si mpleSCMBC" nameID="st-SimpleSCMBC_ID">
<ToLink toBusinessStateRef="ItemIn quiryBTA_ID"/>
</Start>
<BusinessTransactionActivity businessTransactionRef ="ProcessOrderRR_ID"
hasLegalIntent="true" isConcurrent="true" name="Pro cessOrderBTA"
nameID="ProcessOrderBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID"
performsRoleRef="ProcessOrderRequester_ID"/>
<Performs currentRoleRef="Seller_ID"
performsRoleRef="ProcessOrderResponder_ID"/>
</BusinessTransactionActivity>
...
</BusinessCollaboration>
<RequestResponse isGuaranteedDeliveryRequired="true " name="ProcessOrderRR"
nameID="ProcessOrderRR_ID">
<RequestingRole name="ProcessOrderRequester"
nameID="ProcessOrderRequester_ID"/>
<RespondingRole name="ProcessOrderResponder"
nameID="ProcessOrderResponder_ID"/>
<RequestingBusinessActivity name="ProcessOrderReque stBA"
nameID="ProcessOrderRequestBA_ID" isAuthorizationRe quired="true">
<DocumentEnvelope name="ProcessOrderReqDE"
nameID="ProcessOrderReqDE_ID" businessDocumentRef=" OrderBD_ID"
isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ProcessOrderRespo nseBA"
nameID="ProcessOrderResponseBA_ID">
<DocumentEnvelope name="ProcessOrderResDE" nameID=" ProcessOrderResDE_ID"
businessDocumentRef="OrderResBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
...
</Package>
</ProcessSpecification>
57
In example 4-3, two business document XML schemas are defined first, one is for order
submission – UBL-Order-2.0.xsd, and the other is for order response –
UBL-OrderResponse-2.0.xsd. They both belong to the standard UBL business document
library. Then, business collaboration for SCM is described which defines business roles
and business transaction activities. Business transaction activity refers to business
transaction defined afterwards, and sets the perform roles to link the roles in business
collaboration and business transaction. The business transaction illustrated in this
example is a ‘RequestResponse’ pattern, which defines the requesting role and
responding role, and the documents exchanged between interactive business partners.
The documents refer to the business document schemas defined in the beginning of the
example.
4.2.3 ebCPPA Design
In a dynamic e-Business infrastructure, the business collaboration agreements used to
automate the business process are often called electronic trading partner agreements. The
ebCPPA specification is such a facility of implementing trading partner agreements in
ebXML framework [13]. A CPP or a CPA is an XML document that conforms to the
schema for CPP or CPA document. While a CPP document defines the e-Business
capabilities of a single business entity and provides a set of options for negotiation with
potential business partners, a CPA is a mechanism for two organisations to implement
variable properties or override default options specified in the business process
specification document [13]. The structure of CPP and CPA documents is similar, and
this project uses the FreebXML CPPA editor to design CPP and CPA instances as shown
in figure 4-26.
58
Figure 4-26 FreebXML CPPA Editor
Example 4-4 illustrates the excerpt of seller’s CPP, and example 4-5 describes the basic
template used in this project for CPA. Basically, CPA contains information extracted
from two CPPs, plus status and valid date control. Full implementations of CPP and CPA
are listed in appendix.
Example 4-4 Excerpt of seller’s CPP <?xml version="1.0"?>
<tp:CollaborationProtocolProfile
xmlns:tp=”http://www.oasis-open.org/committees/eb xml-cppa/schema/cpp-cpa-2_0.xsd”...>
<!-- Party info for CompanySupplier1-->
<tp:PartyInfo
tp:partyName="CompanySupplier1"...>
<tp:PartyId
tp:type="urn:oasis:names:tc:ebxml-cppa:partyi d-type:duns">200000001</tp:PartyId>
<tp:PartyRef xlink:href="http://CompanySupplier 1.com/about.html"/>
<tp:CollaborationRole>
<tp:ProcessSpecification tp:version="2.0" tp: name="SimpleSCM Process Specification"
xlink:type="simple" xlink:href="http://loca lhost/SimpleSCMPS.xml"/>
<tp:Role tp:name="Buyer" xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xm l#Seller_ID"/>
<tp:ServiceBinding>
<tp:Service>urn:...:bpss:v1_00</tp:Service>
59
...
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID6" tp:actio n="Order Inquiry Action"
tp:packageId="CompanySupplier1_Response Package2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext tp:binaryCollaboratio n="SimpleSCMBC"
tp:businessTransactionActivity="Order InquiryBTA"
tp:requestOrResponseAction="OrderInqu iryResponseBA"/>
<tp:ChannelId>syncChannelB5</tp:Channel Id>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
</tp:ServiceBinding>
</tp:CollaborationRole>
<!-- A synchronous delivery channel -->
...
<tp:DeliveryChannel tp:channelId="syncChannelB5 " tp:transportId="transportB5"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:Transport tp:transportId="transportB5">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP </tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAu thentication>
<tp:Endpoint tp:uri="http://supplier1/order s" tp:type="allPurpose"/>
<tp:Endpoint tp:uri="http://supplier1/order s/{id}" tp:type="allPurpose"/>
<tp:Endpoint tp:uri="http://supplier1/order s?querystring" tp:type="allPurpose"/>
</tp:TransportReceiver>
</tp:Transport>
</tp:PartyInfo>
<!-- SimplePart corresponding to a request action -->
...
<tp:SimplePart tp:id="CompanySupplier1_Response2" tp:mimetype="application/xml">
</tp:SimplePart>
<!-- Request message packages-->
<tp:Packaging tp:id="CompanySupplier1_ResponsePac kage2">
<tp:ProcessingCapabilities tp:parse="true" tp: generate="true"/>
<tp:CompositeList>
<tp:Composite tp:id="CompanySupplier1_Respons eMsg2" tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_ Response2"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Comment xml:lang="en-US">Seller1's Collaborat ion Protocol Profile</tp:Comment>
</tp:CollaborationProtocolProfile>
60
In example 4-4, organisational information is provided first such as party name and
collaboration role in the business process specification. After that, ‘SeviceBinding’
element defines services of this party, and refers to the business process specification for
business transaction activity type, and request or response action type. Then,
‘DeliveryChannel’ and ‘Transport’ elements describe actual service’s endpoint, type, and
authentication method. Finally, ‘SimplePart’ and ‘Packaging’ elements outline the MIME
type information of message payload.
Example 4-5 CPA template <?xml version="1.0"?>
<!-- Copyright UN/CEFACT and OASIS, 2002. All Right s Reserved. -->
<tp:CollaborationProtocolAgreement
xmlns:tp=”http://www.oasis-open.org/committees/eb xml-cppa/schema/cpp-cpa-2_0.xsd”...
tp:cpaid="uri:PCMaker-and-Supplier1-cpa" tp:versi on="2_0b"/>
<tp:Status tp:value="proposed"/>
<tp:Start>2009-05-20T07:21:00Z</tp:Start>
<tp:End>2010-05-20T07:21:00Z</tp:End>
<tp:PartyInfo
<!-- Information about the Company one ... -->
</tp:PartyInfo>
<tp:PartyInfo
<!-- Information about the Company two ... -->
</tp:PartyInfo>
<tp:SimplePart
<!-- Constituents used to make up composite mes sages -->
</tp:SimplePart>
<tp:Packaging>
<!-- Information about packaging of message pay load -->
</tp:Packaging>
<tp:Comment xml:lang="en-US">...</tp:Comment>
</tp:CollaborationProtocolAgreement>
4.2.4 UBL Document Design
The design of UBL extends the business activity model (Figure 3-1) and applies UBL
documents into business transaction requests and responses. For example, an item
inquiry response message is presented by a UBL ‘Catalogue’ document, the place order
activity submits ‘Order’ document to seller, and receives an ‘Order Response’ document.
Figure 4-27 shows UBL documents adopted in the business activity model.
61
Figure 4-27 UBL Documents in Business Activity Model
62
Some activities do not use document when making request like ‘Item Inquiry’ or ‘Inquire
Order’ because the request is very simple without requiring any message payload. There
is one activity – ‘Cancel Order’ has no response document representation because after
the order is cancelled, the resource itself is deleted. Hence, no representation is returned
in this case. Examples of UBL documents for this project are available in appendix.
4.3 Summary
This chapter elaborated the design of the prototype. First, RESTful Web Services design
was illustrated involving the resource model design based on the business activity model
and DFD. Then, the basic model of URI used in RESTful Web Services was defined in
EBNF format. After that, the business process specification, collaboration profile and
agreement in ebXML framework were described with examples. Finally, UBL
documents were adopted in the business activity model to support document-centric
RESTful Web Services implementation for supply chain collaboration. After this chapter,
it is the implementation chapter which elaborates technical detail of the prototype.
63
Chapter 5 Prototype Implementation
Following the design chapter, this chapter describes the implementation tools used and
activities undertaken to build the prototype for this project. The implementation is split
into three parts including server side, client side of Web Services application in Ruby and
Ruby on Rails framework, and ebXML Registry/Repository server for storing and
sharing business artefacts. For the sake of avoiding redundancy, seller system is used to
demonstrate the implementation of server side, and buyer system is used to demonstrate
the implementation of client side.
5.1 Project Tools
There two types of tools are used in this project, one is the hardware tools, and the other
is the software tools. The hardware tools provide the physical environment for the
applications. A laptop computer with Intel Core2 Duo 1.8 GHz CPUs and 1 GB of RAM
is used to carry out the development of this project. However, the prototypes
implemented by this project should work on an older hardware configuration which
meets the minimum requirement of the software development tools. Although there are
three roles – buyer, seller, and third party warehouse operator, it is sufficient to use one
computer to host the server and clients together.
In order to enable other interested researchers or parties to replicate or use the work of
this project, all the software development tools chosen for the implementation are
licensed under either free software licence or open source licence as in Table 5-1.
Tool name Description License
Canonical Ubuntu GNU/Linux Computer Operating System
used for this project
GNU General Public License
and other licenses
Ruby Cross-platform, general purpose
interpreted and object-oriented
language
Ruby License, GNU General
Public License
Ruby on Rails Open source web application
framework
MIT License (Free software
license)
MySQL RDBMS for web applications GNU General Public License
64
Freebxml ebBP Editor Design generic or specific
business process specification
freebxml License, Open Source
Software,
Freebxml ebCPP Editor Create ebXML Collaboration
Protocol Profile (CPP)
freebxml License, Open Source
Software
Freebxml Registry Free reference implementation
of ebXML Registry standard
freebxml License, Open Source
Software
Netbeans IDE 6.1 Netbeans integrated software
development environment
Common Development and
Distribution License and GNU
General Public License with
Classpath exception
XML Copy Editor Free validating XML editor GNU General Public License
Treetop Free parsing tree grammar Ruby License
Curl Free URL command line tool MIT License
Table 5-1 Project Software Development Tools
5.2 Implementation Server Side of Seller System
5.2.1 Server Side of Seller System
The implementation of server side of seller system follows the MVC (Model, View, and
Controller) pattern provided by the Ruby on Rails web application framework [44].
Every data source of seller system has its own model, view, and controller modules for
processing requests and sending responses. Following sections describe implementation
of MVC modules of every data source in detail.
5.2.1.1 Item Inquiry
A. Model
The model module of item data source has no special setting because external parties are
not supposed to update the item data source.
B. View
The view module of item data source contains two important XML document builders,
one is for presenting the list of items (index.xml.builder), and the other is for presenting
the detail of a particular item (show.xml.builder). Example 5-1 and example 5-2 show
excerpt of these two XML builders respectively, the former provides the price
information and item description only, and the latter provides more specific detail for a
single item including item name, classification, minimum order quantity etc.
65
Example 5-1 Excerpt of index.xml.builder of item data source
for item in @items
xml.tag!("cac:CatalogueLine"){
xml.tag!("cbc:ID", item.id)
xml.tag!("cac:RequiredItemLocationQuantity"){
xml.tag!("cac:Price"){
xml.tag!("cbc:PriceAmount",item.priceamount,
"currencyID"=>"#{item.currencyid}")
}
}
xml.tag!("cac:Item"){
xml.tag!("cbc:Description", item.description)
}
}
End
Example 5-2 Excerpt of show.xml.builder of item data source
xml.tag!("cac:CatalogueLine"){
xml.tag!("cbc:ID", @item.id)
xml.tag!("cac:RequiredItemLocationQuantity"){
xml.tag!("cbc:MinimumQuantity", @item.minimumquan tity)
xml.tag!("cac:Price"){
xml.tag!("cbc:PriceAmount",@item.priceamount,
"currencyID"=>"#{@item.currencyid}")
xml.tag!("cbc:BaseQuantity",@item.basequantity,
"unitCode"=>"#{@item.unitcode}")
}
}
xml.tag!("cac:Item"){
xml.tag!("cbc:Description", @item.description)
xml.tag!("cbc:AdditionalInformation", @item.addit ionalinformation)
xml.tag!("cbc:BrandName", @item.brandname)
xml.tag!("cbc:ModelName", @item.name)
xml.tag!("cac:CommodityClassification"){
xml.tag!("cbc:CommodityCode", @item.commoditycod e)
xml.tag!("cbc:ItemClassificationCode", @item.ite mclassificationcode)
}
}
}
C. Controller
The controller module of item data source is the backbone which contains the application
logic. Ruby on Rails framework fully supports RESTful Web Services interface, and
66
HTTP standard methods [44]. Example 5-3 shows the two functions in items controller.
The ‘index’ function is responsible for providing a list of items. When the query string is
not empty, it searches the items matching the condition. If there is no query string, it
returns all the items available for sale. The ‘respond_to’ and ‘format.xml’ statements call
the ‘index’ XML builder in the view module to send an XML document. The ‘show’
function is relatively simple. It is used to process requests of inquiring a single item, and
send response back. This function takes the item id as parameter, and uses ‘show’ XML
builder to generate the response XML document.
Example 5-3 Excerpt of items_controller.rb
# GET /items
def index
if request.query_string.length > 0
unesc_querystring = URI.unescape(request.query_st ring)
sqlstring = "SELECT * FROM items WHERE " + unesc_ querystring
@items = Item.find_by_sql sqlstring
else
@items = Item.all
end
respond_to do |format|
format.xml # index.xml.builder
end
end
…
# GET /items/1
def show
@item = Item.find(params[:id])
respond_to do |format|
format.xml # show.xml.builder
end
end
5.2.1.2 Request for Quote
A. Model
By following common practice, the quote data source is supported by two database
tables, one is used to store quote header information (Quote), and the other is used to
store quote line detail information (QuoteLine). The model of ‘Quote’ indicates one
67
quote may have multiple quote lines, and defines the function to add quote lines as
shown in example 5-4. The model of ‘QuoteLine’ indicates one quote line belongs to one
quote, and defines the function to save detail of quote lines as shown in example 5-5. In
addition, this model has the business logic for discount calculation.
Example 5-4 Model of Quote class Quote < ActiveRecord::Base
has_many :quote_lines
def add_quote_lines(rfqlines)
rfqlines.each do |rfqline|
ql = QuoteLine.from_rfqline(rfqline)
quote_lines << ql
end
end
end
Example 5-5 Model of QuoteLine class QuoteLine < ActiveRecord::Base
belongs_to :quote
belongs_to :item
def self.from_rfqline(rfqline)
ql = self.new
ql.customer_line_id = rfqline[:id]
ql.quote_line_note = rfqline[:note]
ql.item_id = rfqline[:line_item][:id]
ql.quantity = rfqline[:line_item][:quantity]
if ql.quantity >= 500
discount = 0.7
elsif ql.quantity >= 300
discount = 0.8
elsif ql.quantity >= 100
discount = 0.9
else
discount = 1
end
qlitem = Item.find(:first, :conditions => {:id => rfqline[:line_item][:id]})
if qlitem.nil?
ql.item_description = "Item Not Found"
ql.price = 0
else
ql.unitcode = qlitem.unitcode
68
ql.item_description = qlitem.description
ql.item_name = qlitem.name
ql.price = (qlitem.priceamount) * discount
ql.currencyid = qlitem.currencyid
end
ql
end
end
B. View
The view module of quote data source is responsible for returning the quote response
XML document to the requestor. Example 5-6 shows excerpt of the XML builder
(create.xml.builder); first part presents the quote header information, and second parts
presents the quote detail lines information.
Example 5-6 Excerpt of create.xml.builder of quote data source xml.Quotation("xmlns" => "urn:oasis:names:specifica tion:ubl:schema:xsd:Quotation-2"...){
xml.tag!("cbc:ID", @quote.id)
xml.tag!("cbc:IssueDate", (@quote.created_at).strf time('%Y-%m-%d'))
xml.tag!("cbc:Note", @quote.rfqnote)
xml.tag!("cac:RequestForQuotationDocumentReference "){
xml.tag!("cbc:ID", @quote.rfqid)
}
xml.tag!("cac:SellerSupplierParty"){
xml.tag!("cac:Party"){
xml.tag!("cac:PartyName"){
xml.tag!("cbc:Name", "Supplier1")
}
}
}
...
for ql in @quote.quote_lines
xml.tag!("cac:QuotationLine"){
xml.tag!("cbc:ID", ql.customer_line_id)
xml.tag!("cbc:Note", ql.quote_line_note)
xml.tag!("cac:LineItem"){
xml.tag!("cbc:ID", ql.item_id)
xml.tag!("cbc:Quantity", ql.quantity, "unitCode" => ql.unitcode)
xml.tag!("cac:Price"){
xml.tag!("cbc:PriceAmount", ql.price, "currency ID" => ql.currencyid)
}
xml.tag!("cac:Item"){
xml.tag!("cbc:Description", ql.item_description )
69
xml.tag!("cbc:ModelName", ql.item_name)
}
}
}
end
}
C. Controller
The function of controller module of quote data source is straightforward. It takes
parameters through parsing the incoming XML document sent by requestor using HTTP
POST method, and saves them to quote header table, then calls the ‘add_quote_lines’
function. After that, it sends the response XML representation back to the requestor.
Example 5-7 Excerpt of quotes_controller.rb # POST /quotes
def create
if request.content_type() == Mime::XML
party = params[:request_for_quotation][:originato r_customer_party][:party]
@quote = Quote.new(:rfqid => params[:request_for_ quotation][:id],
:rfqnote => params[:request_for_quotation][:not e],
:customername => party[:party_name][:name],
:streetname => party[:postal_address][:street_n ame],
:buildingnumber => party[:postal_address][:buil ding_number],
:cityname => party[:postal_address][:city_name] ,
:postalzone => party[:postal_address][:postal_z one],
:addressline => party[:postal_address][:address _line][:line],
:countrycode => party[:postal_address][:country ][:identification_code])
rfqlines = params[:request_for_quotation][:reques t_for_quotation_line]
@quote.add_quote_lines(rfqlines)
else
@quote = Quote.new(params[:quote])
end
respond_to do |format|
if @quote.save
format.xml { render :xml => @quote, :template =>
'quotes/create.xml.builder', :status => :created, : location => @quote }
else
format.xml { render :xml => @quote.errors , :status => :unprocessable_entity }
end
end
end
70
5.2.1.3 Order Processing
A. Model
Similar to quote data source, order data source has two supporting tables. Besides the
‘add_order_lines’ function for adding new order lines, the model of ‘Order’ has another
‘update_order_lines’ function for updating existing order lines. Likewise, the model of
‘OrderLine’ has two functions, one is for saving order detail lines, and the other is for
updating order lines. Example 5-8 and example 5-9 show the excerpt of models of
‘Order’ and ‘OrderLine’ respectively. There is one more extra point in model of ‘Order’,
the ‘:dependent => :destroy’ property in ‘has_many’ statement indicates when the order
is destroyed, and the related order lines are deleted accordingly.
Example 5-8 Model of Order class Order < ActiveRecord::Base
has_many :order_lines, :dependent => :destroy
def add_order_lines(orderlines)
orderlines.each do |orderline|
ol = OrderLine.from_orderline(orderline)
order_lines << ol
end
end
def update_order_lines(order_id, orderlines)
orderlines.each do |orderline|
ol = OrderLine.update_orderline(order_id, orderl ine)
end
end
end
Example 5-9 Model of OrderLine class OrderLine < ActiveRecord::Base
belongs_to :order
belongs_to :item
def self.from_orderline(orderline)
ol = self.new
ol.orderline_note = orderline[:note]
ol.item_id = orderline[:line_item][:id]
ol.quantity = orderline[:line_item][:quantity]
if ol.quantity >= 500
71
discount = 0.7
elsif ol.quantity >= 300
discount = 0.8
elsif ol.quantity >= 100
discount = 0.9
else
discount = 1
end
olitem = Item.find(:first, :conditions => {:id => orderline[:line_item][:id]})
if olitem.nil?
ol.item_description = "Item Not Found"
else
ol.unitcode = olitem.unitcode
ol.item_description = olitem.description
ol.item_name = olitem.name
ol.price = (olitem.priceamount) * discount
ol.currencyid = olitem.currencyid
end
ol
end
def self.update_orderline(order_id, orderline)
ol = self.find(:first, :conditions => { :order_id = > order_id, :item_id =>
orderline[:line_item][:id]})
ol.orderline_note = orderline[:note]
ol.save
end
end
B. View
The view module of order data source includes four XML builder files for responding a
request of retrieving a list of orders (index.xml.builder), a request of getting detail of a
specific item (show.xml.builder), a request of order creation (create.xml.builder), or a
request of updating an order (edit.xml.builder). However, three of them
(show.xml.builder, create.xml.builder, and edit.xml.builder) are identical in this project
because they all use UBL order response document schema as template. The reason of
keeping them in separate files is that these xml builders may be modified respectively in
future. Example 5-10 and example 5-11 show the excerpt of create.xml.builder and
index.xml.builder.
72
Example 5-10 Excerpt of create.xml.builder of order data source xml.OrderResponse("xmlns"=>"urn:oasis:names:specifi cation:ubl:schema:xsd:OrderResponse-2”
...){
xml.tag!("cbc:ID", @order.id)
xml.tag!("cbc:IssueDate", (@order.created_at).strf time('%Y-%m-%d'))
xml.tag!("cbc:Note", @order.ordernote)
xml.tag!("cac:OrderReference"){
xml.tag!("cbc:ID", @order.orderrefid)
}
xml.tag!("cac:SellerSupplierParty"){
xml.tag!("cac:Party"){
xml.tag!("cac:PartyName"){
xml.tag!("cbc:Name", "Supplier1")
}
}
}
xml.tag!("cac:BuyerCustomerParty"){
xml.tag!("cac:Party"){
xml.tag!("cac:PartyName"){
xml.tag!("cbc:Name", @order.customername)
}
xml.tag!("cac:PostalAddress"){
...}
xml.tag!("cac:Contact"){
...}
}
}
xml.tag!("cac:Delivery"){
...
}
for ol in @order.order_lines
xml.tag!("cac:OrderLine"){
xml.tag!("cbc:Note", ol.orderline_note)
xml.tag!("cac:LineItem"){
xml.tag!("cbc:ID", ol.item_id)
xml.tag!("cbc:Quantity", ol.quantity, "unitCode" => ol.unitcode)
xml.tag!("cac:Price"){
xml.tag!("cbc:PriceAmount", ol.price, "currency ID" => ol.currencyid)
}
xml.tag!("cac:Item"){
xml.tag!("cbc:Description", ol.item_description )
xml.tag!("cbc:ModelName", ol.item_name)
}
}
}
73
end
}
Example 5-11 Excerpt of index.xml.builder of order data source xml.ApplicationResponse("xmlns"=>"urn:oasis:names:s pecification:ubl:schema:xsd:Applicatio
nResponse-2"...){
xml.tag!("cbc:ID", "A01")
xml.tag!("cbc:IssueDate", Date.today.to_s)
xml.tag!("cac:SenderParty"){
xml.tag!("cac:PartyName"){
xml.tag!("cbc:Name", "Supplier1")
}
}
xml.tag!("cac:ReceiverParty"){
xml.tag!("cac:PartyName"){
xml.tag!("cbc:Name", @customername)
}
}
for order in @orders
xml.tag!("cac:DocumentResponse"){
xml.tag!("cac:Response"){
xml.tag!("cbc:ReferenceID", order.orderrefid)
}
xml.tag!("cac:DocumentReference"){
xml.tag!("cbc:ID", order.id)
}
}
end
}
C. Controller
The controller module of order data source is the most complicated one in this prototype
because it supports four HTTP methods all together. Moreover, it has authentication
control in place to prevent unauthorised access to customer’s order information. Example
5-12 gives the part of authentication function in this controller, and example 5-13
illustrates the excerpt of the controller. One thing is worth mentioning is that the
‘destroy’ function has no XML representation, and uses HTTP header status code as
response only.
74
Example 5-12 Authetication function of order data source controller class OrdersController < ApplicationController
USERNAME = 'jack'
PASSWORD = '9d4e1e23bd5b727046a9e3b4b7db57bd8d6ee68 4'
before_filter :authenticate
def authenticate
authenticate_or_request_with_http_basic do |u sername, password|
if (username == USERNAME && Digest::SHA1.he xdigest(password) == PASSWORD)
@customername = "PCMaker Corporation"
return true
end
end
return false
end
end
Example 5-13 Excerpt of orders_controller.rb # GET /orders
def index
if request.query_string.length > 0
unesc_querystring = URI.unescape(request.query_st ring)
sqlstring = "SELECT * FROM orders WHERE customernam e=" + "'" + @customername + "'"
+ " AND " + unesc_querystring
@orders = Order.find_by_sql sqlstring
else
@orders = Order.find(:all, :conditions => [ "cust omername = ?", @customername])
end
respond_to do |format|
format.xml #{ render :xml => @items }
end
end
# GET /orders/1
def show
@order = Order.find(:first, :conditions => [ "id = ? AND customername = ?", params[:id].to_i,
@customername])
if @order.nil?
respond_to do |format|
format.xml { head :not_found }
end
else
respond_to do |format|
format.xml # show.xml.builder
end
75
end
end
# POST /orders
def create
if request.content_type() == Mime::XML
party = params[:order][:buyer_customer_party][:pa rty]
req_delivery = params[:order][:delivery][:request ed_delivery_period]
@order = Order.new(:orderrefid => params[:order][ :id]...)
orderlines = params[:order][:order_line]
@order.add_order_lines(orderlines)
else
@order = Order.new(params[:order])
end
respond_to do |format|
if @order.save
format.xml { render :xml => @order, :template =>
'orders/create.xml.builder', :status => :created, : location => @order }
else
format.xml { render :xml => @order.error s, :status => :unprocessable_entity }
end
end
end
# PUT /orders/1
def update
@order = Order.find(:first, :conditions => [ "id = ? AND customername = ?", params[:id].to_i,
@customername])
if @order.nil?
respond_to do |format|
format.xml { head :not_found }
end
else
if request.content_type() == Mime::XML
@order.update_attributes(:ordernote => params[:o rder_change][:note])
orderlines = params[:order_change][:order_line]
@order.update_order_lines(params[:order_change][:or der_reference][:id],
orderlines)
respond_to do |format|
format.xml { render :xml => @order, :template =>
'orders/edit.xml.builder', :status => :ok, :locatio n => @order }
end
end
end
end
76
# DELETE /orders/1
def destroy
#@order=Order.find(params[:id])
@order = Order.find(:first, :conditions => [ "id = ? AND customername = ?", params[:id].to_i,
@customername])
if @order.nil?
respond_to do |format|
format.xml { head :not_found }
end
else
@order.destroy
respond_to do |format|
format.xml { head :ok }
end
end
end
5.2.1.4 Receive Receipt Advice
A. Model
The model modules of receipt advice data source are simple, and follow the same pattern
as quote data source. Example 5-14 and example 5-15 show the code of them.
Example 5-14 Model of Receipt class Receipt < ActiveRecord::Base
has_many :receipt_lines
def add_receipt_lines(receiptlines)
receiptlines.each do |receiptline|
rl = ReceiptLine.from_receiptline(receiptline)
receipt_lines << rl
end
end
end
Example 5-15 Model of ReceiptLine class ReceiptLine < ActiveRecord::Base
belongs_to :receipt
def self.from_receiptline(receiptline)
rl = self.new
rl.receiptline_id = receiptline[:id]
rl.receivedqty = receiptline[:received_quantity]
rl.despatchline_id = receiptline[:despatch_line_r eference][:line_id]
77
rl.docref = receiptline[:document_reference][:id]
rl.item_name = receiptline[:item][:model_name]
rl
end
end
B. View
The view module of receipt advice data source is responsible for returning receipt advice
response XML document to requestor. Example 5-16 shows the excerpt of the XML
builder file of receipt advice.
Example 5-16 Excerpt of create.xml.builder of receipt advice data source xml.ReceiptAdvice("xmlns"=>"urn:oasis:names:specifi cation:ubl:schema:xsd:ReceiptAdvice-2"
...){
xml.tag!("cbc:ID", @receipt.id)
xml.tag!("cbc:IssueDate", (@receipt.created_at).st rftime('%Y-%m-%d'))
xml.tag!("cac:DeliveryCustomerParty"){
...}
xml.tag!("cac:DespatchSupplierParty"){
...}
for rl in @receipt.receipt_lines
xml.tag!("cac:ReceiptLine"){
xml.tag!("cbc:ID", rl.receiptline_id)
xml.tag!("cbc:ReceivedQuantity", rl.receivedqty)
xml.tag!("cac:DespatchLineReference"){
xml.tag!("cbc:LineID", rl.despatchline_id)
}
xml.tag!("cac:DocumentReference"){
xml.tag!("cbc:ID", rl.docref)
}
xml.tag!("cac:Item"){
xml.tag!("cbc:ModelName", rl.item_name)
}
}
end
}
C. Controller
The controller module of receipt advice data source receives request from buyer, and
then processes the request and returns XML response document to buyer. Example 5-17
78
illustrates excerpt of this controller.
Example 5-17 Excerpt of receipts_controller.rb # POST /receipts
def create
if request.content_type() == Mime::XML
customer=params[:receipt_advice][:delivery_cust omer_party][:party][:party_name][:name]
supplier=params[:receipt_advice][:despatch_supp lier_party][:party][:party_name][:name]
@receipt = Receipt.new(:customername => custome r, :suppliername => supplier)
receiptlines = params[:receipt_advice][:receipt _line]
@receipt.add_receipt_lines(receiptlines)
else
@receipt = Receipt.new(params[:receipt])
end
respond_to do |format|
if @receipt.save
format.xml { render :xml => @receipt, :template =>
'receipts/create.xml.builder', :status => :create d, :location => @receipt }
else
format.xml { render :xml => @receipt.errors, :status => :unprocessable_entity }
end
end
end
5.3 Implementation Client Side of Buyer System
Client side of buyer system covers most requests in this prototype. From item inquiry,
request for quote, order management to despatch and receipt advices processing.
5.3.1 Graphic User Interfaces
Graphic user interface (GUI) is an important constituent of most computer applications.
In this prototype, it provides friendly interfaces for users to execute business operations,
select business transaction files if required, and check response messages. Figure 5-1
illustrates the main GUI window of buyer system, the ‘Supplier Operations’ section
includes business operations which are related to seller, and the ‘Third Warehouse
Operations’ section lists business operation(s) which are related to third party warehouse
operator.
79
Figure 5-1 Main GUI window of buyer system
Figure 5-2 describes a typical GUI window of a business operation (Place Order). User
can enter the Internet resource they want to access into ‘Hostname’ and ‘URL Path’,
select business transaction file by clicking the ‘Open’ button. And if the resource is
access controlled, use needs provide ‘Username’ and ‘Password’, and then clicks the
‘Send’ button to submit the request. Responding message is displayed in following text
box.
Figure 5-2 GUI window of business operation
80
5.3.2 Implementation of Basic Model for RESTful URI – Treetop in Ruby
In section 4.2.4, a basic model for RESTful URI was discussed and defined in the form
of EBNF grammar (Example 4-1). Within the implementation stage, this project chose
‘Treetop’ [48], a language of describing tree grammar syntax in Ruby to realise this
function. Example 5-18 shows the treetop grammar conforms to the EBNF grammar. In
treetop format, ‘/’ is used for ordered choice, ‘?’ is used for optional expression, ‘+’ is
used for matching an expression one or more times, and character classes like [a-zA-Z]
and [0-9] are surrounded by square brackets.
Example 5-18 Treetop grammar of Basic Model for RESTful URI grammar RestUrl
rule rest_url
"/" collection (("/" member) / ("?" querystring)) ?
end
rule collection
character1+
end
rule member
character1+
end
rule querystring
conditionexpression (sp joinsymbol sp conditionex pression)?
end
rule conditionexpression
condition / conditiongroup
end
rule joinsymbol
"AND" / "and" / "OR" / "or"
end
rule condition
name comparisonsymbol value
end
rule conditiongroup
"(" querystring ")"
end
81
rule name
character1+
end
rule comparisonsymbol
(("<" / ">") "="?) / ("!"? "=")
end
rule value
("'" character2+ "'") / (digitlist ("." digitlist )?)
end
rule character1
letter / digit / underscore
end
rule character2
character1 / otherchar
end
rule digitlist
digit+
end
rule letter
[a-zA-Z]
end
rule digit
[0-9]
end
rule underscore
"_"
end
rule otherchar
"~" / "!" / "@" / "#" / "$" / "^" / "&" / "*" / "(" / ")" / "+" / "-" / "=" / "{"
/ "}" / "[" / "]" / "|" / "<" / ">" / "," / "." / " :" / ";" / "?" / "/" / sp
end
rule sp
" "
end
end
82
Example 5-19 demonstrates portion of code describing how treetop grammar is used in
Ruby code.
Example 5-19 Using treetop grammar in Ruby require 'treetop'
urlstring = entry2.value # URL Path
Treetop.load "resturl" # Load treetop grammar
parser = RestUrlParser.new
if parser.parse(urlstring) # Parse the URL Path
puts 'success'
puts urlstring
else
puts 'failure'
# Display error message
msgBox = Tk.messageBox('type' => "ok", 'icon' = > "error",
'title' => "URI string invalid",
'message' => "URI String Invalid! Please use '/col lection[/id|?querystring]' format.")
text1.delete(1.0, 'end') # Clear response message box
return
end
5.4 Implementation of ebXML Registry/Repository Server
ebXML is a public central storage for business parties to publish and discover others’
services. Figure 5-3 shows the welcome page of freebxml registry Web UI browser.
Users can create user account or publish new registry object through this page.
Figure 5-3 Welcome page of freebxml registry and repository
83
Certain registry objects can be found by using the ‘Search’ or ‘Explore’ tab, and
displayed in the right-hand frame as shown in figure 5-4.
Figure 5-4 Search results of ebXML cppa objects
By clicking ‘Details’ link of the registry object, users can check the detail of the registry
object, and view the repository item content by following the hyperlink as illustrated in
figure 5-5. Usually, the repository item is an XML document, and is opened in a web
browser such as an ebXML CPP profile as displayed in figure 5-6.
Figure 5-5 Detail of ebXML cppa object
84
Figure 5-6 Repository item e.g. ebXML CPP profile
5.5 Summary
In this chapter, the implementation detail of the prototype was discussed. Ruby and Ruby
on Rails framework were used to implement the server side and client side of the
prototype. UBL XML business documents were chosen as the main representation of
data exchanged between business parties. An ebXML Registry/Repository server was
installed to provide an interactive tool to host business artefacts such as collaboration
profiles, and allow business parties to discover services. In the next chapter (chapter 6), a
short testing and evaluation of the prototype system are made, strengths of the
implementation are discussed along with its limitations.
85
Chapter 6 Testing and Evaluation
This chapter illustrates the testing to describe how the prototype system was tested
during the project development progress first. Then, a short evaluation is conducted to
discuss the overall implementation regarding strengths and limitations.
6.1 Testing
6.1.1 Command Line Testing
During the development process, command line testing tool is one of common useful
tools for quick testing and troubleshooting. Curl [49] is a true open source and free
software which is adopted in this project to test RESTful Web Services through its
powerful command line functionality. Figure 6-1 and figure 6-2 show two curl
commands used to get item list and send request for quote respectively. In these
examples, the option ‘-H’ defines HTTP request header information. In both cases, it
indicates that the accepted response format is ‘application/xml’. In second example, it
indicates it is a HTTP POST request by using options ‘-d’ and ‘@’, and the HTTP POST
payload content type is set to ‘application/xml’.
Figure 6-1 Curl command line testing sample 1
86
Figure 6-2 Curl command line testing sample 2
6.1.2 GUI Testing
As the development progressing, GUI was designed and programmed to fulfil the
functionality of the prototype. In order to demonstrate most functionalities, the ‘Order
Change’ GUI window is chosen here to illustrate the GUI testing. Figure 6-3 gives the
scenario of access control function, and figure 6-4 shows ‘Record Not Found’ screen. In
these examples, ‘401’ and ‘404’ are standard HTTP status codes [39].
Figure 6-3 Change Order GUI testing sample 1
Figure 6-4 Change Order GUI testing sample 2
87
Figure 6-5 represents a normal request and response screen of the prototype. ‘Hostname’
and ‘URL Path’ are used for entering server host name and resource path on the server.
‘Open File’ textbox and ‘Open’ button are used for selecting XML document.
‘Username’ and ‘Password’ are used for controlling access to the resource, and ‘Send’
button is used for sending the request. If the request is successful as shown in figure 6-5,
response message is displayed in the dedicated text area. However, the HTTP status code
(200 OK) is not shown as it is unnecessary.
Figure 6-5 Change Order GUI testing sample 3
Figure 6-6 shows situation when users enter invalid URL path string, and then system
prompts an error message to inform users must modify the URL path and follow the
correct pattern of URL path string according to the basic model of URL for RESTful
Web Services defined in section 4.2.1.4.
88
Figure 6-6 Change Order GUI testing sample 4
6.2 Evaluation
6.2.1 Strengths
6.2.1.1 Simplicity
This project suggested a relatively simple solution for implementing Web Services
application by integrating RESTful Web Services, ebXML framework, and UBL
standard business documents library. Among them, RESTful Web Services support XML
document transfer across the ubiquitous Internet information space linked by URIs
through HTTP uniform interfaces. In the prototype of this project, only one web server
(Ruby on Rails) is used to provide services without any other extra layer. ebXML
framework and UBL business documents library are both OASIS standard specifications,
these technologies are based on XML and easy to construct through open source free
design tools [40] or XML editors [47].
89
6.2.1.2 Scalability
HTTP and URI are two main components of RESTful Web Services, and it has been
proven that they underpin the infrastructure of modern World Wide Web, the most
successful scalable network application [6][34] in the world. In this project, service
interfaces are provided through URI and HTTP which allow the prototype system take
full advantage of these two standards. ebXML framework and UBL are XML-based, so
they are extensible as well. For example, in ebBP business process specification, it is
easy to extend business collaboration by adding new business activities and related
business document schemas.
6.2.1.3 Usability
There are more and more web sites start to support RESTful Web Services including
Google [51], Yahoo [50] and Amazon [43]. In addition, there are three popular web
frameworks – Ruby on Rails (Ruby), Restlet (Java) [52], Django (Python) [53] have
been developed to simplify the design of RESTful Web Services [3]. Rails web
framework is used in this project because it supports quick prototyping, easy
development, embedded Model-View-Controller pattern, and elegant mapping
mechanism from a relational database. However, RESTful Web Services can be written
in other frameworks such as Restlet and Django, and even traditional Java servlet or CGI
script technologies.
6.2.2 Limitations
6.2.2.1 Security
As illustrated in section 5.2.1.3, the security control method adopted in this project is
HTTP basic authentication method, and it is very simple. However, in e-Business over
the Internet environment, security is a big concern for all business organisations.
Unauthorised access, Internet fraud, and information leaking are just a few examples of
security problem. Therefore, more strong and sophisticated solution is required to protect
resources from being attacked. In addition, digital signature functionality is also needed
for non-repudiation validation purpose.
90
6.2.2.2 Lack of support of complex URI
The basic model for URI introduced in section 4.2.1.4 is a simplified assumption because
it only supports two levels e.g. /items or /items/1. In real business scenario, this model
may be not flexible enough and needs to be modified to support more levels such as
/items/cpu/intel or /items/monitor/samsung/lcd. Hence, a more complicated model is
required to enable flexible construction of RESTful Web Services URI. Moreover, the
server which is responsible for parsing the complex URI has to be capable to understand
it, route it, and process it accordingly.
6.2.2.3 Lack of automated tool
Due to the lack of time, this project did not implement an automated tool to generate
RESTful Web Services client application from collaboration protocol profile and
agreement. Such an automated tool is very helpful to make it easy to design RESTful
Web Services client.
6.3 Summary
This chapter demonstrated two testing methods used in this project, command line
testing using curl, and GUI testing with the example of ‘Order Change’. After that, an
evaluation of the implementation was discussed from two aspects. One is strengths such
as simplicity, scalability, and usability; the other is limitations such as security, lack of
support of complex URI, and lack of automated tool. In next last chapter, conclusions are
made and future work is proposed.
91
Chapter 7 Conclusions
The conclusions chapter briefly conducts a critical analysis on the technologies used in
this project. Then it discusses the reflection of the project, followed by the discussion of
future work.
7.1 Critical Analysis
RESTful Web Services, ebXML framework, and UBL are the technologies used in this
project. Among them, ebXML and UBL are both International standards for e-Business
recommended by OASIS and UN/CEFACT. The core technology analysed here is the
RESTful Web Services, or simply REST.
REST is not a silver bullet, it has strengths and weaknesses. The strengths of REST
include: (1) simplicity, because the uniform interface is invariant and there is no problem
of breaking clients, (2) scalability, because the separation of concerns principle allows
the client and server to evolve independently, (3) visibility, because the communication is
stateless, and a system does not need to look beyond a single request to understand it, (4)
interoperability, because REST advocates standards make today’s Web successful like
HTTP, URI, HTML, and XML [6], (5) REST conforms the Axioms of Web architecture
[27]. The weaknesses of REST include the challenge to identify and model the resources
appropriately in the web applications, and informal semantics and syntax are just mainly
for human readers to use.
Likewise, the adoption of RESTful Web Services has opportunities and threats. Due to
the complexity of SOAP, 85% of Amazon’s Web Services usage was of the REST
interface in 2003 [28], and Google deprecated its SOAP Search API in 2006 [29]. The
low entry barriers and grassroots approach give the opportunity to RESTful Web
Services to thrive on the Web. However, commercial hype over SOAP and lack of
support and tools for REST mean REST is still largely unknown to enterprises.
92
7.2 Reflection
This project established an integrated e-Business solution for supply chain management
with RESTful Web Services, ebXML framework, and UBL business document standard
including a set of RESTful Web Services for supply chain management process, a
prototype of REST client to utilise the services, an ebBP business process model base on
the SCOR model, a couple of ebCPPA profiles and agreements, an ebXML
Registry/Repository server, and UBL business documents for supply chain interactions.
In the meantime, a pragmatic resource modelling technique has been investigated as
supplementary improvement for RESTful Web Services design. The data flow modelling
technique which is to maintain (create, read, update, and delete) an information system is
used as reference model for the design of resource modelling technique. And EBNF
grammar is used to suggest the basic model of URI.
7.3 Future Work
The current approach requires a certain amount of human agreement for services
construction and consumption. Therefore, Simple Knowledge Organization System
(SKOS) [30] built on Resource Description Framework (RDF) [31] is worth researching
to allow automatic registration and discovery of Web Services. Unlike the formal
knowledge representation language – Web Ontology Language (OWL) [32], SKOS
provides a simpler standard, low-cost approach for existing knowledge representations
such as thesauri, classification schemes, and taxonomies to be used in the Semantic Web.
Furthermore, SKOS defines a family of lightweight languages for developing and
sharing new concept schemas (e.g., taxonomies, structured controlled vocabularies, etc.),
thus enabling data sharing across a variety of applications [30].
93
References
[1] Waldt, D. (2003). ebXML Web Services & EDI. http://www.ebxml.org/presentations/ws_ebxml_
london_may03.pdf. XML Europe 2003, London.
[2] Prescod, P. (2002). Second Generation Web Services. http://webservices.xml.com/pub/a/ws/2002/02
/06/rest.html
[3] Richardson, L. and S. Ruby (2007). RESTful Web Services. Sebastopol, California, O'Reilly.
[4] W3C Recommendation (2007). SOAP Version 1.2 Part 0: Primer (Second Edition). http://www.w3.
org/TR/2007/REC-soap12-part0-20070427/
[5] W3C Recommendation (2007). SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/
[6] Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures.
Doctoral dissertation, University of California, Irvine, http://www.ics.uci.edu/~fielding
/pubs/dissertation/top.htm
[7] Tilkov, S. (2008). Addressing Doubts about REST. http://www.infoq.com/articles/tilkov-rest-doubts
[8] Prescod, P. (2002). REST and the Real World. http://webservices.xml.com/pub/a/ws/2002/02
/20/rest.html
[9] Manes, A. T. (2008). REST is about Resources. http://apsblog.burtongroup.com/2008/03/rest-is
-about-r.html
[10] Wikipedia (Accessed on 09/04/2009). Representational State Transfer. http://en.wikipedia.org/wiki
/Representational_State_Transfer
[11] Weaver, P. L., N. Lambrou, et al. (2002). Practical business systems development using SSADM : a
complete tutorial guide. Harlow, Financial Times Prentice Hall.
[12] OASIS ebXML.org (Accessed on 10/04/2009). About ebXML. http://www.ebxml.org/geninfo.htm
[13] Chappell, D. A. (2001). Professional EbXML foundations. Birmingham, Wrox Press.
[14] Freebxml.org (Accessed on 10/04/2009). ebXML Registry/Repository Overview. http://ebxmlrr.
sourceforge.net/wiki/index.php/Overview
[15] OASIS/ebXML Registry Technical Committee (2002). OASIS/ebXML Registry Services
Specification v2.0. http://www.oasis-open.org/committees/regrep/documents /2.0/specs/ebrs.pdf
[16] ISO TC 154 (Accessed on 10/04/2009). Processes, data elements and documents in commerce,
industry and administration. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.
htm?commid=53186&published=on
[17] OASIS Standard ebXML Business Process Technical Committee (2006). ebXML Business Process
Specification Schema Technical Specification v2.0.4. http://docs.oasis-open.org/ebxml-bp/2.0.
4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.pdf
[18] OASIS ebXML Joint Committee (2006). The Framework for eBusiness. http://www.oasis
-open.org/committees/download.php/17817/ebxmljc-WhitePaper-wd-r02-en.pdf
[19] OASIS ebBP Technical Committee (Accessed on 11/04/2009). Frequently Asked Questions (FAQs).
http://www.oasis-open.org/committees/download.php/21792/ ebxmlbp -v2.0.4-faq-os-en.htm
[20] OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee (2002).
Collaboration-Protocol Profile and Agreement Specification Version 2.0. http://www.oasis-open.org
/committees/download.php/204/ebcpp-2.0.pdf
[21] OASIS Universal Business Language Technical Committee (Accessed on 12/04/2009). Frequently
Asked Questions (FAQs). http://www.oasis-open.org/ committees/ubl/faq.php
94
[22] OASIS Universal Business Language Technical Committee (2006). Universal Business Language
v2.0. http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html
[23] Supply-Chain Council (2008). SCOR 9.0 Overview. http://www.supply-chain.org/galleries/public
-gallery/SCOR%209.0%20Overview%20Booklet.pdf
[24] Supply-Chain Council (Accessed on 17/04/2009). SCOR Model. http://www.supply-chain.org/cs
/root/scor_tools_resources/scor_model/scor_model
[25] Lukka, K. (2003). The constructive research approach. In: L. Ojala, O-P. Hilmola. (eds.) Case study
research in logistics. Publications of the Turku School of Economics and Business Administration, Series
B 1: 2003, p. 83-101.
[26] Yovits, M. C. and M. V. Zelkowitz (1995). Advances in computers, volume 40. London, Academic
Press.
[27] Berners-Lee, T. (1996). Universal Resource Identifiers -- Axioms of Web Architecture.
http://www.w3.org/DesignIssues/Axioms.html
[28] O'Reilly, T. (2003). REST vs. SOAP at Amazon. http://www.oreillynet.com/pub /wlg/3005
[29] Google Code (Accessed on 23/04/2009). Google SOAP Search API. http://code.google.com/apis
/soapsearch/
[30] W3C Candidate Recommendation (2009). SKOS Simple Knowledge Organization System Reference.
http://www.w3.org/TR/skos-reference/
[31] W3C Recommendation (2004). Resource Description Framework (RDF): Concepts and Abstract
Syntax. http://www.w3.org/TR/rdf-concepts/
[32] W3C Recommendation (2004). OWL Web Ontology Language Reference. http://www.w3.org/TR
/owl-ref/
[33] Singh, Munindar P. and Huhns, Michael N. (2005). Service-oriented computing : semantics, processes,
agents. Chichester, Wiley.
[34] W3C Recommendation (2004). Architecture of the World Wide Web, Volume One. http://www.w3.
org/TR/webarch/
[35] W3C (2003). SOAP 1.2 Implementation Summary. http://www.w3.org/2000/xp/Group/2/03/soap1.2
implementation.html
[36] Englander, R. (2002). Java and SOAP. Sebastopol, California, O'Reilly.
[37] Glushko, Robert J. and McGrath, T. (2005). Document engineering analyzing and designing
documents for business informatics and Web Services. Cambridge, MIT Press.
[38] International Organization for Standardization (1996). Information technology – Syntactic
Metalanguage – Extended BNF. http://standards.iso.org/ittf/PubliclyAvailableStandards /s026153_ISO_
IEC_14977_1996(E).zip
[39] The Internet Engineering Task Force (IETF) (1999). RFC 2616. http://www.ietf.org/rfc/rfc2616.txt
[40] FreebXMLBP Editor (2006). http://freebxmlbp.sourceforge.net/wiki/index.php/Main_Page
[41] Gregorio, J. (2008). URI Template. http://tools.ietf.org/html/draft-gregorio-uritemplate-03
[42] IBM (Accessed on 17/08/2009). Austrian Ministry Of Justice Case Study. http://www-900.ibm.com
/cn /smb/industries/gov/govdig_justice _c.shtml
[43] Amazon (Accessed on 17/08/2009). Amazon Simple Storage Service (Amazon S3).
http://aws.amazon.com/s3/
[44] Ruby on Rails (Accessed on 19/08/2009). Ruby on Rails. http://rubyonrails.org/
[45] Ruby (Accessed on 19/08/2009). Ruby Language. http://www.ruby-lang.org/
[46] Netbeans (Accessed on 20/8/2009). Netbeans IDE. http://www.netbeans.org/
[47] SourceForge.net(Accessed on 29/08/2009). XML Copy Editor. http://xml-copy-editor.sourceforge.net/
[48] Rubyforge.org (Accessed on 30/08/2009). Treetop. http://treetop.rubyforge.org/
95
[49] Haxx (Accessed on 01/09/2009). Curl. http://curl.haxx.se/
[50] Yahoo (Accessed on 01/09/2009). Yahoo! Developer Network - Frequently Asked Questions.
http://developer.yahoo.com/faq/
[51] Google (Accessed on 02/09/2009). Google AJAX Search API Developer’s Guide.
http://code.google.com/apis/ajaxsearch/documentation/
[52] Restlet.org (Accessed on 02/09/2009). Restlet framework. http://www.restlet.org/
[53] Django (Accessed on 02/09/2009). Django project. http://www.djangoproject.com/
96
Appendix A – ebXML Business Process Schema <?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification xmlns="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0"
xmlns:bp1="http://www.ebxml.org/BusinessProcess"
xmlns:bp2="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0"
specificationVersion="2.0" nameID="idProcessSpecification01"
name="SimpleSCMItemInquiry"
uuid="urn:ebusiness:specification:interchange:simplescm:xml:bpss:v1_00"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0 http://docs.oasis-open.org/ebxml-bp/2.0.4/ebbp-2.0.4.xsd">
<BusinessDocument name="BlankBD" nameID="BlankBD_ID">
<Specification name="BlankBDSchema" nameID="BlankBDSchema_ID" location=http://localhost/xsd/blank.xsd
type="schema"/>
</BusinessDocument>
<BusinessDocument name="ItemInquiryBD" nameID="ItemInquiryBD_ID">
<Specification name="ItemInquiryBDSchema" nameID="ItemInquiryBDSchema_ID"
location="http://localhost/xsd/UBL-Catalogue-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="RFQBD" nameID="RFQBD_ID">
<Specification name="RFQBDSchema" nameID="RFQBDSchema_ID"
location="http://localhost/xsd/UBL-RequestForQuotation-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="QuoteBD" nameID="QuoteBD_ID">
<Specification name="QuoteBDSchema" nameID="QuoteBDSchema_ID"
location="http://localhost/xsd/UBL-Quotation-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="OrderBD" nameID="OrderBD_ID">
<Specification name="OrderBDSchema" nameID="OrderBDSchema_ID"
location="http://localhost/xsd/UBL-Order-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="OrderResBD" nameID="OrderResBD_ID">
<Specification name="OrderResBDSchema" nameID="OrderResBDSchema_ID"
location="http://localhost/xsd/UBL-OrderResponse-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="OrderResListBD" nameID="OrderResListBD_ID">
<Specification name="OrderResListBDSchema" nameID="OrderResListBDSchema_ID"
location="http://localhost/xsd/UBL-ApplicationResponse-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="OrderChgBD" nameID="OrderChgBD_ID">
<Specification name="OrderChgBDSchema" nameID="OrderChgBDSchema_ID"
location="http://localhost/xsd/UBL-OrderChange-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="DespatchBD" nameID="DespatchBD_ID">
<Specification name="DespatchBDSchema" nameID="DespatchBDSchema_ID"
97
location="http://localhost/xsd/UBL-DespatchAdvice-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="ReceiptBD" nameID="ReceiptBD_ID">
<Specification name="ReceiptBDSchema" nameID="ReceiptBDSchema_ID"
location="http://localhost/xsd/UBL-ReceiptAdvice-2.0.xsd" type="schema"/>
</BusinessDocument>
<BusinessDocument name="InvoiceBD" nameID="InvoiceBD_ID">
<Specification name="InvoiceBDSchema" nameID="InvoiceBDSchema_ID"
location="http://localhost/xsd/UBL-Invoice-2.0.xsd" type="schema"/>
</BusinessDocument>
<Package name="SimpleSCMPK" nameID="SimpleSCMPK_ID">
<BusinessCollaboration isInnerCollaboration="false" name="SimpleSCMBC" nameID="SimpleSCMBC_ID">
<Role name="Buyer" nameID="Buyer_ID"/>
<Role name="Seller" nameID="Seller_ID"/>
<Role name="ThirdWH" nameID="ThirdWH_ID"/>
<TimeToPerform/>
<Start name="Start of Collaboration SimpleSCMBC" nameID="st-SimpleSCMBC_ID">
<ToLink toBusinessStateRef="ItemInquiryBTA_ID"/>
</Start>
<BusinessTransactionActivity businessTransactionRef="ItemInquiryQR_ID" hasLegalIntent="false"
isConcurrent="true" name="ItemInquiryBTA" nameID="ItemInquiryBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ItemInquiryRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="ItemInquiryResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="QuoteQR_ID" hasLegalIntent="false"
isConcurrent="true" name="QuoteBTA" nameID="QuoteBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="QuoteRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="QuoteResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ProcessOrderRR_ID" hasLegalIntent="true"
isConcurrent="true" name="ProcessOrderBTA" nameID="ProcessOrderBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ProcessOrderRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="ProcessOrderResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="OrderInquiryQR_ID" hasLegalIntent="false"
isConcurrent="true" name="OrderInquiryBTA" nameID="OrderInquiryBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="OrderInquiryRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="OrderInquiryResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="OrderCancelRR_ID" hasLegalIntent="true"
isConcurrent="true" name="OrderCancelBTA" nameID="OrderCanelBTA_ID">
<TimeToPerform/>
98
<Performs currentRoleRef="Buyer_ID" performsRoleRef="OrderCancelRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="OrderCancelResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="OrderChangeRR_ID" hasLegalIntent="true"
isConcurrent="true" name="OrderChangeBTA" nameID="OrderChangeBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="OrderChangeRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="OrderChangeResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ProcessDespatchRR_ID" hasLegalIntent="false"
isConcurrent="true" name="ProcessDespatchBTA" nameID="ProcessDespatchBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="ProcessDespatchRequester_ID"/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ProcessDespatchResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ReceiveDespatchRR_ID" hasLegalIntent="false"
isConcurrent="true" name="ReceiveDespatchBTA" nameID="ReceiveDespatchBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ReceiveDespatchRequester_ID"/>
<Performs currentRoleRef="ThirdWH_ID" performsRoleRef="ReceiveDespatchResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ProcessReceiptRR_ID" hasLegalIntent="false"
isConcurrent="true" name="ProcessReceiptBTA" nameID="ProcessReceiptBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="ThirdWH_ID" performsRoleRef="ProcessReceiptRequester_ID"/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ProcessReceiptResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ReceiveReceiptRR_ID" hasLegalIntent="false"
isConcurrent="true" name="ReceiveReceiptBTA" nameID="ReceiveReceiptBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ReceiveReceiptRequester_ID"/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="ReceiveReceiptResponder_ID"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity businessTransactionRef="ReceiveInvoiceRR_ID" hasLegalIntent="true"
isConcurrent="true" name="ReceiveInvoiceBTA" nameID="ReceiveInvoiceBTA_ID">
<TimeToPerform/>
<Performs currentRoleRef="Seller_ID" performsRoleRef="ReceiveInvoiceRequester_ID"/>
<Performs currentRoleRef="Buyer_ID" performsRoleRef="ReceiveInvoiceResponder_ID"/>
</BusinessTransactionActivity>
</BusinessCollaboration>
<QueryResponse isGuaranteedDeliveryRequired="false" name="ItemInquiryQR" nameID="ItemInquiryQR_ID">
<RequestingRole name="ItemInquiryRequester" nameID="ItemInquiryRequester_ID"/>
<RespondingRole name="ItemInquiryResponder" nameID="ItemInquiryResponder_ID"/>
<RequestingBusinessActivity name="ItemInquiryRequestBA" nameID="ItemInquiryRequestBA_ID">
<DocumentEnvelope name="ItemInquiryReqDE" nameID="ItemInquiryReqDE_ID"
businessDocumentRef="BlankBD_ID"/>
99
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ItemInquiryResponseBA" nameID="ItemInquiryResponseBA_ID">
<DocumentEnvelope name="ItemInquiryResDE" nameID="ItemInquiryResDE_ID"
businessDocumentRef="ItemInquiryBDSchema_ID"/>
</RespondingBusinessActivity>
</QueryResponse>
<QueryResponse isGuaranteedDeliveryRequired="false" name="QuoteQR" nameID="QuoteQR_ID">
<RequestingRole name="QuoteRequester" nameID="QuoteRequester_ID"/>
<RespondingRole name="QuoteResponder" nameID="QuoteResponder_ID"/>
<RequestingBusinessActivity name="QuoteRequestBA" nameID="QuoteRequestBA_ID">
<DocumentEnvelope name="QuoteReqDE" nameID="QuoteReqDE_ID"
businessDocumentRef="RFQBDSchema_ID"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="QuoteResponseBA" nameID="QuoteResponseBA_ID">
<DocumentEnvelope name="QuoteResDE" nameID="QuoteResDE_ID"
businessDocumentRef="QuoteBDSchema_ID"/>
</RespondingBusinessActivity>
</QueryResponse>
<RequestResponse isGuaranteedDeliveryRequired="true" name="ProcessOrderRR" nameID="ProcessOrderRR_ID">
<RequestingRole name="ProcessOrderRequester" nameID="ProcessOrderRequester_ID"/>
<RespondingRole name="ProcessOrderResponder" nameID="ProcessOrderResponder_ID"/>
<RequestingBusinessActivity name="ProcessOrderRequestBA" nameID="ProcessOrderRequestBA_ID"
isAuthorizationRequired="true">
<DocumentEnvelope name="ProcessOrderReqDE" nameID="ProcessOrderReqDE_ID"
businessDocumentRef="OrderBD_ID" isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ProcessOrderResponseBA" nameID="ProcessOrderResponseBA_ID">
<DocumentEnvelope name="ProcessOrderResDE" nameID="ProcessOrderResDE_ID"
businessDocumentRef="OrderResBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<QueryResponse isGuaranteedDeliveryRequired="false" name="OrderInquiryQR" nameID="OrderInquiryQR_ID">
<RequestingRole name="OrderInquiryRequester" nameID="OrderInquiryRequester_ID"/>
<RespondingRole name="OrderInquiryResponder" nameID="OrderInquiryResponder_ID"/>
<RequestingBusinessActivity name="OrderInquiryRequestBA" nameID="OrderInquiryRequestBA_ID"
isAuthorizationRequired="true">
<DocumentEnvelope name="OrderInquiryReqDE" nameID="OrderInquiryReqDE_ID"
businessDocumentRef="BlankBD_ID" isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="OrderInquiryResponseBA" nameID="OrderInquiryResponseBA_ID">
<DocumentEnvelope name="OrderInquiryResDE1" nameID="OrderInquiryResDE1_ID"
businessDocumentRef="OrderResBD_ID"/>
<DocumentEnvelope name="OrderInquiryResDE2" nameID="OrderInquiryResDE2_ID"
businessDocumentRef="OrderResListBD_ID"/>
</RespondingBusinessActivity>
</QueryResponse>
100
<RequestResponse isGuaranteedDeliveryRequired="true" name="OrderCancelRR" nameID="OrderCancelRR_ID">
<RequestingRole name="OrderCancelRequester" nameID="OrderCancelRequester_ID"/>
<RespondingRole name="OrderCancelResponder" nameID="OrderCancelResponder_ID"/>
<RequestingBusinessActivity name="OrderCancelRequestBA" nameID="OrderCancelRequestBA_ID"
isAuthorizationRequired="true">
<DocumentEnvelope name="OrderCancelReqDE" nameID="OrderCancelReqDE_ID"
businessDocumentRef="BlankBD_ID" isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="OrderCancelResponseBA" nameID="OrderCancelResponseBA_ID">
<DocumentEnvelope name="OrderCancelResDE" nameID="OrderCancelResDE_ID"
businessDocumentRef="BlankBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="true" name="OrderChangeRR" nameID="OrderChangeRR_ID">
<RequestingRole name="OrderChangeRequester" nameID="OrderChangeRequester_ID"/>
<RespondingRole name="OrderChangeResponder" nameID="OrderChangeResponder_ID"/>
<RequestingBusinessActivity name="OrderChangeRequestBA" nameID="OrderChangeRequestBA_ID"
isAuthorizationRequired="true">
<DocumentEnvelope name="OrderChangeReqDE" nameID="OrderChangeReqDE_ID"
businessDocumentRef="OrderChgBD_ID" isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="OrderChangeResponseBA" nameID="OrderChangeResponseBA_ID">
<DocumentEnvelope name="OrderChangeResDE" nameID="OrderChangeResDE_ID"
businessDocumentRef="OrderResBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="false" name="ProcessDespatchRR"
nameID="ProcessDespatchRR_ID">
<RequestingRole name="ProcessDespatchRequester" nameID="ProcessDespatchRequester_ID"/>
<RespondingRole name="ProcessDespatchResponder" nameID="ProcessDespatchResponder_ID"/>
<RequestingBusinessActivity name="ProcessDespatchRequestBA" nameID="ProcessDespatchRequestBA_ID">
<DocumentEnvelope name="ProcessDespatchReqDE" nameID="ProcessDespatchReqDE_ID"
businessDocumentRef="DespatchBD_ID"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ProcessDespatchResponseBA" nameID="ProcessDespatchResponseBA_ID">
<DocumentEnvelope name="ProcessDespatchResDE" nameID="ProcessDespatchResDE_ID"
businessDocumentRef="DespatchBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="false" name="ReceiveDespatchRR"
nameID="ReceiveDespatchRR_ID">
<RequestingRole name="ReceiveDespatchRequester" nameID="ReceiveDespatchRequester_ID"/>
<RespondingRole name="ReceiveDespatchResponder" nameID="ReceiveDespatchResponder_ID"/>
<RequestingBusinessActivity name="ReceiveDespatchRequestBA" nameID="ReceiveDespatchRequestBA_ID">
<DocumentEnvelope name="ReceiveDespatchReqDE" nameID="ReceiveDespatchReqDE_ID"
businessDocumentRef="DespatchBD_ID"/>
101
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ReceiveDespatchResponseBA" nameID="ReceiveDespatchResponseBA_ID">
<DocumentEnvelope name="ReceiveDespatchResDE" nameID="ReceiveDespatchResDE_ID"
businessDocumentRef="DespatchBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="false" name="ProcessReceiptRR" nameID="ProcessReceiptRR_ID">
<RequestingRole name="ProcessReceiptRequester" nameID="ProcessReceiptRequester_ID"/>
<RespondingRole name="ProcessReceiptResponder" nameID="ProcessReceiptResponder_ID"/>
<RequestingBusinessActivity name="ProcessReceiptRequestBA" nameID="ProcessReceiptRequestBA_ID">
<DocumentEnvelope name="ProcessReceiptReqDE" nameID="ProcessReceiptReqDE_ID"
businessDocumentRef="ReceiptBD_ID"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ProcessReceiptResponseBA" nameID="ProcessReceiptResponseBA_ID">
<DocumentEnvelope name="ProcessReceiptResDE" nameID="ProcessReceiptResDE_ID"
businessDocumentRef="ReceiptBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="false" name="ReceiveReceiptRR" nameID="ReceiveReceiptRR_ID">
<RequestingRole name="ReceiveReceiptRequester" nameID="ReceiveReceiptRequester_ID"/>
<RespondingRole name="ReceiveReceiptResponder" nameID="ReceiveReceiptResponder_ID"/>
<RequestingBusinessActivity name="ReceiveReceiptRequestBA" nameID="ReceiveReceiptRequestBA_ID">
<DocumentEnvelope name="ReceiveReceiptReqDE" nameID="ReceiveReceiptReqDE_ID"
businessDocumentRef="ReceiptBD_ID"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ReceiveReceiptResponseBA" nameID="ReceiveReceiptResponseBA_ID">
<DocumentEnvelope name="ReceiveReceiptResDE" nameID="ReceiveReceiptResDE_ID"
businessDocumentRef="ReceiptBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
<RequestResponse isGuaranteedDeliveryRequired="true" name="ReceiveInvoiceRR" nameID="ReceiveInvoiceRR_ID">
<RequestingRole name="ReceiveInvoiceRequester" nameID="ReceiveInvoiceRequester_ID"/>
<RespondingRole name="ReceiveInvoiceResponder" nameID="ReceiveInvoiceResponder_ID"/>
<RequestingBusinessActivity name="ReceiveInvoiceRequestBA" nameID="ReceiveInvoiceRequestBA_ID"
isAuthorizationRequired="true">
<DocumentEnvelope name="ReceiveInvoiceReqDE" nameID="ReceiveInvoiceReqDE_ID"
businessDocumentRef="InvoiceBD_ID" isAuthenticated="transient"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="ReceiveInvoiceResponseBA" nameID="ReceiveInvoiceResponseBA_ID">
<DocumentEnvelope name="ReceiveInvoiceResDE" nameID="ReceiveInvoiceResDE_ID"
businessDocumentRef="InvoiceBD_ID"/>
</RespondingBusinessActivity>
</RequestResponse>
</Package>
</ProcessSpecification>
102
Appendix B – ebXML CPP and CPA
A. CPP <?xml version="1.0"?>
<!-- Copyright UN/CEFACT and OASIS, 2002. All Rights Reserved. -->
<tp:CollaborationProtocolProfile
xmlns:tp="http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd
cpp-cpa-2_0b.xsd"
tp:cppid="uri:companySupplier1-cpp" tp:version="2_0b">
<!-- Party info for CompanySupplier1-->
<tp:PartyInfo
tp:partyName="CompanySupplier1"
tp:defaultMshChannelId="syncChannelB1"
tp:defaultMshPackageId="CompanySupplier1_RequestPackage">
<tp:PartyId
tp:type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">200000001</tp:PartyId>
<tp:PartyRef xlink:href="http://CompanySupplier1.com/about.html"/>
<tp:CollaborationRole>
<tp:ProcessSpecification
tp:version="2.0"
tp:name="SimpleSCM Process Specification"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml"/>
<tp:Role
tp:name="Buyer"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml#Seller_ID"/>
<tp:ServiceBinding>
<tp:Service>urn:ebusiness:specification:interchange:simplescm:xml:bpss:v1_00</tp:Service>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID1"
tp:action="Process Despatch Request Action"
tp:packageId="CompanySupplier1_RequestPackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessDespatchBTA"
tp:requestOrResponseAction="ProcessDespatchRequestBA"/>
<tp:ChannelId>syncChannelB1</tp:ChannelId>
103
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID2"
tp:action="Receive Invoice Request Action"
tp:packageId="CompanySupplier1_RequestPackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveInvoiceBTA"
tp:requestOrResponseAction="ReceiveInvoiceRequestBA"/>
<tp:ChannelId>syncChannelB1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID3"
tp:action="Process Item Inquiry Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ItemInquiryBTA"
tp:requestOrResponseAction="ItemInquiryResponseBA"/>
<tp:ChannelId>syncChannelB2</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID4"
tp:action="Process Quote Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="QuoteBTA"
tp:requestOrResponseAction="QuoteResponseBA"/>
<tp:ChannelId>syncChannelB3</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID5"
tp:action="Process Order Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
104
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessOrderBTA"
tp:requestOrResponseAction="ProcessOrderResponseBA"/>
<tp:ChannelId>syncChannelB4</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID6"
tp:action="Order Inquiry Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderInquiryBTA"
tp:requestOrResponseAction="OrderInquiryResponseBA"/>
<tp:ChannelId>syncChannelB5</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID7"
tp:action="Order Cancel Action"
tp:packageId="CompanySupplier1_ResponsePackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderCancelBTA"
tp:requestOrResponseAction="OrderCancelResponseBA"/>
<tp:ChannelId>syncChannelB6</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID8"
tp:action="Order Change Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderChangeBTA"
tp:requestOrResponseAction="OrderChangeResponseBA"/>
<tp:ChannelId>syncChannelB7</tp:ChannelId>
</tp:ThisPartyActionBinding>
105
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID9"
tp:action="Receive Receipt Action"
tp:packageId="CompanySupplier1_ResponsePackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveReceiptBTA"
tp:requestOrResponseAction="ReceiveReceiptResponseBA"/>
<tp:ChannelId>syncChannelB8</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
</tp:ServiceBinding>
</tp:CollaborationRole>
<!-- A synchronous delivery channel -->
<tp:DeliveryChannel
tp:channelId="syncChannelB1"
tp:transportId="transportB1"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB2"
tp:transportId="transportB2"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB3"
tp:transportId="transportB3"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB4"
tp:transportId="transportB4"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB5"
tp:transportId="transportB5"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
106
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB6"
tp:transportId="transportB6"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB7"
tp:transportId="transportB7"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB8"
tp:transportId="transportB8"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:Transport tp:transportId="transportB1">
<tp:TransportSender>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
</tp:TransportSender>
</tp:Transport>
<tp:Transport tp:transportId="transportB2">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/items"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/items/{id}"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/item?querystring"
tp:type="allPurpose"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB3">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
107
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/quotes"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB4">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB5">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/orders?querystring"
tp:type="allPurpose"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB6">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="response"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB7">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
108
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="request"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB8">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/receipts"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:DocExchange tp:docExchangeId="docExchangeB1">
<tp:ebXMLSenderBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLSenderBinding>
<tp:ebXMLReceiverBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLReceiverBinding>
</tp:DocExchange>
</tp:PartyInfo>
<!-- SimplePart corresponding to a request action-->
<tp:SimplePart
tp:id="CompanySupplier1_Request"
tp:mimetype="application/xml">
</tp:SimplePart>
<!-- SimplePart corresponding to a response action -->
<tp:SimplePart
tp:id="CompanySupplier1_Response1"
tp:mimetype="text/xml">
</tp:SimplePart>
<tp:SimplePart
109
tp:id="CompanySupplier1_Response2"
tp:mimetype="application/xml">
</tp:SimplePart>
<!-- Request message packages-->
<tp:Packaging tp:id="CompanySupplier1_RequestPackage">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_RequestMsg"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Request"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<!-- Response message packages -->
<tp:Packaging tp:id="CompanySupplier1_ResponsePackage1">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_ResponseMsg1"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Response1"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Packaging tp:id="CompanySupplier1_ResponsePackage2">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_ResponseMsg2"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Response2"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Comment xml:lang="en-US">Seller1's Collaboration Protocol Profile</tp:Comment>
</tp:CollaborationProtocolProfile>
110
B. CPA <?xml version="1.0"?>
<!-- Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved. -->
<tp:CollaborationProtocolAgreement
xmlns:tp="http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd
cpp-cpa-2_0b.xsd"
tp:cpaid="uri:PCMaker-and-Supplier1-cpa" tp:version="2_0b">
<tp:Status tp:value="proposed"/>
<tp:Start>2009-05-20T07:21:00Z</tp:Start>
<tp:End>2010-05-20T07:21:00Z</tp:End>
<!-- Party info for CompanyPCMaker-->
<tp:PartyInfo
tp:partyName="CompanyPCMaker"
tp:defaultMshChannelId="syncChannelA1"
tp:defaultMshPackageId="CompanyPCMaker_RequestPackage1">
<tp:PartyId
tp:type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">100000001</tp:PartyId>
<tp:PartyRef xlink:href="http://CompanyPCMaker.com/about.html"/>
<tp:CollaborationRole>
<tp:ProcessSpecification
tp:version="2.0"
tp:name="SimpleSCM Process Specification"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml"/>
<tp:Role
tp:name="Buyer"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml#Buyer_ID"/>
<tp:ServiceBinding>
<tp:Service>urn:ebusiness:specification:interchange:simplescm:xml:bpss:v1_00</tp:Service>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID1"
tp:action="Item Inquiry Request Action"
tp:packageId="CompanyPCMaker_RequestPackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ItemInquiryBTA"
tp:requestOrResponseAction="ItemInquiryRequestBA"/>
111
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID2"
tp:action="Quote Request Action"
tp:packageId="CompanyPCMaker_RequestPackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="QuoteBTA"
tp:requestOrResponseAction="QuoteRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID3"
tp:action="Process Order Request Action"
tp:packageId="CompanyPCMaker_RequestPackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessOrderBTA"
tp:requestOrResponseAction="ProcessOrderRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID4"
tp:action="Order Inquiry Request Action"
tp:packageId="CompanyPCMaker_RequestPackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderInquiryBTA"
tp:requestOrResponseAction="OrderInquiryRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID5"
tp:action="Order Cancel Request Action"
112
tp:packageId="CompanyPCMaker_RequestPackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderCancelBTA"
tp:requestOrResponseAction="OrderCancelRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID6"
tp:action="Order Change Request Action"
tp:packageId="CompanyPCMaker_RequestPackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderChangeBTA"
tp:requestOrResponseAction="OrderChangeRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID7"
tp:action="Receive Despatch Request Action"
tp:packageId="CompanyPCMaker_RequestPackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveDespatchBTA"
tp:requestOrResponseAction="ReceiveDespatchRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID8"
tp:action="Receive Receipt Request Action"
tp:packageId="CompanyPCMaker_RequestPackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveReceiptBTA"
tp:requestOrResponseAction="ReceiveReceiptRequestBA"/>
<tp:ChannelId>syncChannelA1</tp:ChannelId>
113
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID9"
tp:action="Process Despatch Action"
tp:packageId="CompanyPCMaker_ResponsePackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessDespatchBTA"
tp:requestOrResponseAction="ProcessDespatchResponseBA"/>
<tp:ChannelId>syncChannelA2</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID10"
tp:action="Process Receipt Action"
tp:packageId="CompanyPCMaker_ResponsePackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessReceiptBTA"
tp:requestOrResponseAction="ProcessReceiptResponseBA"/>
<tp:ChannelId>syncChannelA3</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companyPCMaker_ABID11"
tp:action="Receive Invoice Action"
tp:packageId="CompanyPCMaker_ResponsePackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveInvoiceBTA"
tp:requestOrResponseAction="ReceiveInvoiceResponseBA"/>
<tp:ChannelId>syncChannelA4</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
</tp:ServiceBinding>
</tp:CollaborationRole>
<!-- A synchronous delivery channel -->
<tp:DeliveryChannel
tp:channelId="syncChannelA1"
114
tp:transportId="transportA1"
tp:docExchangeId="docExchangeA1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelA2"
tp:transportId="transportA2"
tp:docExchangeId="docExchangeA1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelA3"
tp:transportId="transportA3"
tp:docExchangeId="docExchangeA1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelA4"
tp:transportId="transportA4"
tp:docExchangeId="docExchangeA1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:Transport tp:transportId="transportA1">
<tp:TransportSender>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
</tp:TransportSender>
</tp:Transport>
<tp:Transport tp:transportId="transportA2">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://pcmaker/despatches"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportA3">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://pcmaker/receipts"
115
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportA4">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://pcmaker/invoices"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:DocExchange tp:docExchangeId="docExchangeA1">
<tp:ebXMLSenderBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLSenderBinding>
<tp:ebXMLReceiverBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLReceiverBinding>
</tp:DocExchange>
</tp:PartyInfo>
<!-- Party info for CompanySupplier1-->
<tp:PartyInfo
tp:partyName="CompanySupplier1"
tp:defaultMshChannelId="syncChannelB1"
tp:defaultMshPackageId="CompanySupplier1_RequestPackage">
<tp:PartyId
tp:type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">20000001</tp:PartyId>
<tp:PartyRef xlink:href="http://CompanySupplier1.com/about.html"/>
<tp:CollaborationRole>
<tp:ProcessSpecification
tp:version="2.0"
tp:name="SimpleSCM Process Specification"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml"/>
116
<tp:Role
tp:name="Buyer"
xlink:type="simple"
xlink:href="http://localhost/SimpleSCMPS.xml#Seller_ID"/>
<tp:ServiceBinding>
<tp:Service>urn:ebusiness:specification:interchange:simplescm:xml:bpss:v1_00</tp:Service>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID1"
tp:action="Process Despatch Request Action"
tp:packageId="CompanySupplier1_RequestPackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessDespatchBTA"
tp:requestOrResponseAction="ProcessDespatchRequestBA"/>
<tp:ChannelId>syncChannelB1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanSend>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID2"
tp:action="Receive Invoice Request Action"
tp:packageId="CompanySupplier1_RequestPackage">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveInvoiceBTA"
tp:requestOrResponseAction="ReceiveInvoiceRequestBA"/>
<tp:ChannelId>syncChannelB1</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanSend>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID3"
tp:action="Process Item Inquiry Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ItemInquiryBTA"
tp:requestOrResponseAction="ItemInquiryResponseBA"/>
<tp:ChannelId>syncChannelB2</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
117
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID4"
tp:action="Process Quote Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="QuoteBTA"
tp:requestOrResponseAction="QuoteResponseBA"/>
<tp:ChannelId>syncChannelB3</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID5"
tp:action="Process Order Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ProcessOrderBTA"
tp:requestOrResponseAction="ProcessOrderResponseBA"/>
<tp:ChannelId>syncChannelB4</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID6"
tp:action="Order Inquiry Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderInquiryBTA"
tp:requestOrResponseAction="OrderInquiryResponseBA"/>
<tp:ChannelId>syncChannelB5</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID7"
tp:action="Order Cancel Action"
tp:packageId="CompanySupplier1_ResponsePackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
118
tp:businessTransactionActivity="OrderCancelBTA"
tp:requestOrResponseAction="OrderCancelResponseBA"/>
<tp:ChannelId>syncChannelB6</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID8"
tp:action="Order Change Action"
tp:packageId="CompanySupplier1_ResponsePackage2">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="true"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="OrderChangeBTA"
tp:requestOrResponseAction="OrderChangeResponseBA"/>
<tp:ChannelId>syncChannelB7</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
<tp:CanReceive>
<tp:ThisPartyActionBinding
tp:id="companySupplier1_ABID9"
tp:action="Receive Receipt Action"
tp:packageId="CompanySupplier1_ResponsePackage1">
<tp:BusinessTransactionCharacteristics tp:isAuthorizationRequired="false"/>
<tp:ActionContext
tp:binaryCollaboration="SimpleSCMBC"
tp:businessTransactionActivity="ReceiveReceiptBTA"
tp:requestOrResponseAction="ReceiveReceiptResponseBA"/>
<tp:ChannelId>syncChannelB8</tp:ChannelId>
</tp:ThisPartyActionBinding>
</tp:CanReceive>
</tp:ServiceBinding>
</tp:CollaborationRole>
<!-- A synchronous delivery channel -->
<tp:DeliveryChannel
tp:channelId="syncChannelB1"
tp:transportId="transportB1"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB2"
tp:transportId="transportB2"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
119
<tp:DeliveryChannel
tp:channelId="syncChannelB3"
tp:transportId="transportB3"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB4"
tp:transportId="transportB4"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB5"
tp:transportId="transportB5"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB6"
tp:transportId="transportB6"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB7"
tp:transportId="transportB7"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:DeliveryChannel
tp:channelId="syncChannelB8"
tp:transportId="transportB8"
tp:docExchangeId="docExchangeB1">
<tp:MessagingCharacteristics/>
</tp:DeliveryChannel>
<tp:Transport tp:transportId="transportB1">
<tp:TransportSender>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
</tp:TransportSender>
</tp:Transport>
<tp:Transport tp:transportId="transportB2">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
120
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/items"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/items/{id}"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/item?querystring"
tp:type="allPurpose"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB3">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/quotes"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB4">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB5">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="allPurpose"/>
<tp:Endpoint
tp:uri="http://supplier1/orders?querystring"
121
tp:type="allPurpose"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB6">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="response"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB7">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/orders/{id}"
tp:type="request"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="transportB8">
<tp:TransportReceiver>
<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol>
<tp:AccessAuthentication>basic</tp:AccessAuthentication>
<tp:AccessAuthentication>digest</tp:AccessAuthentication>
<tp:Endpoint
tp:uri="http://supplier1/receipts"
tp:type="login"/>
</tp:TransportReceiver>
</tp:Transport>
<tp:DocExchange tp:docExchangeId="docExchangeB1">
<tp:ebXMLSenderBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLSenderBinding>
<tp:ebXMLReceiverBinding tp:version="2.0">
<tp:ReliableMessaging>
<tp:Retries>3</tp:Retries>
<tp:RetryInterval>PT2H</tp:RetryInterval>
122
<tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>
</tp:ReliableMessaging>
<tp:PersistDuration>P1D</tp:PersistDuration>
</tp:ebXMLReceiverBinding>
</tp:DocExchange>
</tp:PartyInfo>
<!-- SimplePart corresponding to a request action PCMaker-->
<tp:SimplePart
tp:id="CompanyPCMaker_Request1"
tp:mimetype="text/xml">
</tp:SimplePart>
<tp:SimplePart
tp:id="CompanyPCMaker_Request2"
tp:mimetype="application/xml">
</tp:SimplePart>
<!-- SimplePart corresponding to a response action PCMaker-->
<tp:SimplePart
tp:id="CompanyPCMaker_Response"
tp:mimetype="text/xml">
</tp:SimplePart>
<!-- SimplePart corresponding to a request action Supplier1-->
<tp:SimplePart
tp:id="CompanySupplier1_Request"
tp:mimetype="application/xml">
</tp:SimplePart>
<!-- SimplePart corresponding to a response action Supplier1-->
<tp:SimplePart
tp:id="CompanySupplier1_Response1"
tp:mimetype="text/xml">
</tp:SimplePart>
<tp:SimplePart
tp:id="CompanySupplier1_Response2"
tp:mimetype="application/xml">
</tp:SimplePart>
<!-- Request message packages PCMaker-->
<tp:Packaging tp:id="CompanyPCMaker_RequestPackage1">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanyPCMaker_RequestMsg1"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanyPCMaker_Request1"/>
</tp:Composite>
123
</tp:CompositeList>
</tp:Packaging>
<tp:Packaging tp:id="CompanyPCMaker_RequestPackage2">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanyPCMaker_RequestMsg2"
tp:mimetype="multipart/related"
tp:mimeparameters="type=application/xml">
<tp:Constituent tp:idref="CompanyPCMaker_Request2"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<!-- Response message packages Supplier1-->
<tp:Packaging tp:id="CompanyPCMaker_ResponsePackage">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanyPCMaker_ResponseMsg"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanyPCMaker_Response"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Packaging tp:id="CompanySupplier1_RequestPackage">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_RequestMsg"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Request"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<!-- Response message packages -->
<tp:Packaging tp:id="CompanySupplier1_ResponsePackage1">
<tp:ProcessingCapabilities
tp:parse="true"
124
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_ResponseMsg1"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Response1"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Packaging tp:id="CompanySupplier1_ResponsePackage2">
<tp:ProcessingCapabilities
tp:parse="true"
tp:generate="true"/>
<tp:CompositeList>
<tp:Composite
tp:id="CompanySupplier1_ResponseMsg2"
tp:mimetype="multipart/related"
tp:mimeparameters="type=text/xml">
<tp:Constituent tp:idref="CompanySupplier1_Response2"/>
</tp:Composite>
</tp:CompositeList>
</tp:Packaging>
<tp:Comment xml:lang="en-US">Buyer/Seller agreement between PCMaker.com and Supplier1.com</tp:Comment>
</tp:CollaborationProtocolAgreement>
125
Appendix C – UBL Documents
A. Item List <?xml version="1.0" encoding="UTF-8"?>
<Catalogue xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2 UBL-Catalogue-2.0.xsd">
<cbc:ID>Supplier1 Catalogue</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cac:ProviderParty>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:ProviderParty>
<cac:ReceiverParty>
<cac:PartyName>
<cbc:Name>Buyer</cbc:Name>
</cac:PartyName>
</cac:ReceiverParty>
<cac:CatalogueLine>
<cbc:ID>1</cbc:ID>
<cac:RequiredItemLocationQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">100</cbc:PriceAmount>
</cac:Price>
</cac:RequiredItemLocationQuantity>
<cac:Item>
<cbc:Description>Intel Core2 Duo 1.8GHz</cbc:Description>
</cac:Item>
</cac:CatalogueLine>
<cac:CatalogueLine>
<cbc:ID>2</cbc:ID>
<cac:RequiredItemLocationQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">110</cbc:PriceAmount>
</cac:Price>
</cac:RequiredItemLocationQuantity>
<cac:Item>
<cbc:Description>Intel Core2 Duo 2.0GHz</cbc:Description>
</cac:Item>
</cac:CatalogueLine>
</Catalogue>
126
B. Item Detail <?xml version="1.0" encoding="UTF-8"?>
<Catalogue xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2 UBL-Catalogue-2.0.xsd">
<cbc:ID>Supplier1 Catalogue</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cac:ProviderParty>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:ProviderParty>
<cac:ReceiverParty>
<cac:PartyName>
<cbc:Name>Buyer</cbc:Name>
</cac:PartyName>
</cac:ReceiverParty>
<cac:CatalogueLine>
<cbc:ID>1</cbc:ID>
<cac:RequiredItemLocationQuantity>
<cbc:MinimumQuantity>1</cbc:MinimumQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">100</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
</cac:Price>
</cac:RequiredItemLocationQuantity>
<cac:Item>
<cbc:Description>Intel Core2 Duo 1.8GHz</cbc:Description>
<cbc:AdditionalInformation></cbc:AdditionalInformation>
<cbc:BrandName>Intel</cbc:BrandName>
<cbc:ModelName>INTELC2DUO1.8</cbc:ModelName>
<cac:CommodityClassification>
<cbc:CommodityCode>COMPUTER HARDWARD</cbc:CommodityCode>
<cbc:ItemClassificationCode>CPU</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:CatalogueLine>
</Catalogue>
127
C. Request for Quote <?xml version="1.0" encoding="UTF-8"?>
<RequestForQuotation xmlns="urn:oasis:names:specification:ubl:schema:xsd:RequestForQuotation-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:RequestForQuotation-2
UBL-RequestForQuotation-2.0.xsd">
<cbc:ID>G867B</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cbc:IssueTime>12:15:10</cbc:IssueTime>
<cbc:Note>Sample</cbc:Note>
<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>The Terminus</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Avon Way</cbc:StreetName>
<cbc:BuildingNumber>56A</cbc:BuildingNumber>
<cbc:CityName>Bridgtow</cbc:CityName>
<cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>3rd Floor, Room 5</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
</cac:Party>
</cac:OriginatorCustomerParty>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:RequestForQuotationLine>
<cbc:ID>1</cbc:ID>
<cbc:Note>Sample line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:Quantity>100</cbc:Quantity>
<cac:Item>
128
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:RequestForQuotationLine>
<cac:RequestForQuotationLine>
<cbc:ID>2</cbc:ID>
<cbc:Note>Sample line 2</cbc:Note>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:Quantity>300</cbc:Quantity>
<cac:Item>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:RequestForQuotationLine>
</RequestForQuotation>
D. Quotation <?xml version="1.0" encoding="UTF-8"?>
<Quotation xmlns="urn:oasis:names:specification:ubl:schema:xsd:Quotation-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Quotation-2 UBL-Quotation-2.0.xsd">
<cbc:ID>1</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cbc:Note>Sample</cbc:Note>
<cac:RequestForQuotationDocumentReference>
<cbc:ID>G867B</cbc:ID>
</cac:RequestForQuotationDocumentReference>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:QuotedMonetaryTotal>
<cbc:PayableAmount currencyID="GBP">27300</cbc:PayableAmount>
</cac:QuotedMonetaryTotal>
<cac:QuotationLine>
<cbc:ID>1</cbc:ID>
<cbc:Note>Sample line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
129
<cbc:Quantity unitCode="EA">100</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">45</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>Seagate(R) Barracuda(TM) 250 GB Internal hard drive</cbc:Description>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:QuotationLine>
<cac:QuotationLine>
<cbc:ID>2</cbc:ID>
<cbc:Note>Sample line 2</cbc:Note>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:Quantity unitCode="EA">300</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">76</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>AMD(R) Athlon(TM) 64 X2 2.9 GHz Processor</cbc:Description>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:QuotationLine>
</Quotation>
E. Order <?xml version="1.0" encoding="UTF-8"?>
<Order xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Order-2 UBL-Order-2.0.xsd">
<cbc:ID>AEG012345</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cbc:Note>Sample order</cbc:Note>
<cac:BuyerCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Avon Way</cbc:StreetName>
<cbc:BuildingNumber>56A</cbc:BuildingNumber>
130
<cbc:CityName>Bridgtow</cbc:CityName>
<cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>3rd Floor, Room 5</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:Contact>
<cbc:Name>Mr Fred Churchill</cbc:Name>
<cbc:Telephone>0127 2653214</cbc:Telephone>
<cbc:Telefax>0127 2653215</cbc:Telefax>
<cbc:ElectronicMail>[email protected]</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:BuyerCustomerParty>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:Delivery>
<cac:RequestedDeliveryPeriod>
<cbc:StartDate>2009-07-29</cbc:StartDate>
<cbc:EndDate>2009-07-31</cbc:EndDate>
</cac:RequestedDeliveryPeriod>
</cac:Delivery>
<cac:OrderLine>
<cbc:Note>Sample order line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:Quantity>100</cbc:Quantity>
<cac:Item>
<cbc:Description>Seagate(R) Barracuda(TM) 250 GB Internal hard drive</cbc:Description>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
<cac:OrderLine>
<cbc:Note>Sample order line 2</cbc:Note>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:Quantity>300</cbc:Quantity>
131
<cac:Item>
<cbc:Description>AMD(R) Athlon(TM) 64 X2 2.9 GHz Processor</cbc:Description>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
</Order>
F. Order Response <?xml version="1.0" encoding="UTF-8"?>
<OrderResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2 UBL-OrderResponse-2.0.xsd">
<cbc:ID>1</cbc:ID>
<cbc:IssueDate>2009-07-16</cbc:IssueDate>
<cbc:Note>Sample order</cbc:Note>
<cac:OrderReference>
<cbc:ID>AEG012345</cbc:ID>
</cac:OrderReference>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:BuyerCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Avon Way</cbc:StreetName>
<cbc:BuildingNumber>56A</cbc:BuildingNumber>
<cbc:CityName>Bridgtow</cbc:CityName>
<cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>3rd Floor, Room 5</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
132
<cac:Contact>
<cbc:Name>Mr Fred Churchill</cbc:Name>
<cbc:Telephone>0127 2653214</cbc:Telephone>
<cbc:Telefax>0127 2653215</cbc:Telefax>
<cbc:ElectronicMail>[email protected]</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:BuyerCustomerParty>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2009-07-30</cbc:StartDate>
<cbc:EndDate>2009-07-31</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:OrderLine>
<cbc:Note>Sample order line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:Quantity>100</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">45</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>Seagate(R) Barracuda(TM) 250 GB Internal hard drive</cbc:Description>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
<cac:OrderLine>
<cbc:Note>Sample order line 2</cbc:Note>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:Quantity>300</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="GBP">76</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>AMD(R) Athlon(TM) 64 X2 2.9 GHz Processor</cbc:Description>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
</OrderResponse>
133
G. Order Change <?xml version="1.0" encoding="UTF-8"?>
<OrderChange xmlns="urn:oasis:names:specification:ubl:schema:xsd:OrderChange-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:OrderChange-2 UBL-OrderChange-2.0.xsd">
<cbc:IssueDate>2009-07-23</cbc:IssueDate>
<cbc:SequenceNumberID>001</cbc:SequenceNumberID>
<cac:OrderReference >
<cbc:ID>1</cbc:ID>
</cac:OrderReference>
<cac:BuyerCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:BuyerCustomerParty>
<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>
<cac:OrderLine>
<cbc:Note>Change Note line 1</cbc:Note>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cac:Item>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
<cac:OrderLine>
<cbc:Note>Change Note line 2</cbc:Note>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cac:Item>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
</OrderChange>
134
H. Despatch Advice <?xml version="1.0" encoding="UTF-8"?>
<DespatchAdvice xmlns="urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2 UBL-DespatchAdvice-2.0.xsd">
<cbc:ID>1</cbc:ID>
<cbc:IssueDate>2009-07-26</cbc:IssueDate>
<cac:DespatchSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:DespatchSupplierParty>
<cac:DeliveryCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:DeliveryCustomerParty>
<cac:DespatchLine>
<cbc:ID>1</cbc:ID>
<cbc:DeliveredQuantity>100</cbc:DeliveredQuantity>
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
<cac:Item>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:DespatchLine>
<cac:DespatchLine>
<cbc:ID>2</cbc:ID>
<cbc:DeliveredQuantity>300</cbc:DeliveredQuantity>
<cac:OrderLineReference>
<cbc:LineID>2</cbc:LineID>
</cac:OrderLineReference>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
135
<cac:Item>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:DespatchLine>
</DespatchAdvice>
I. Receipt Advice <?xml version="1.0" encoding="UTF-8"?>
<ReceiptAdvice xmlns="urn:oasis:names:specification:ubl:schema:xsd:ReceiptAdvice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:ReceiptAdvice-2 UBL-ReceiptAdvice-2.0.xsd">
<cbc:ID>1</cbc:ID>
<cbc:IssueDate>2009-07-26</cbc:IssueDate>
<cac:DeliveryCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:DeliveryCustomerParty>
<cac:DespatchSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:DespatchSupplierParty>
<cac:ReceiptLine>
<cbc:ID>1</cbc:ID>
<cbc:ReceivedQuantity>100</cbc:ReceivedQuantity>
<cac:DespatchLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:DespatchLineReference>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
<cac:Item>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
</cac:ReceiptLine>
<cac:ReceiptLine>
<cbc:ID>2</cbc:ID>
<cbc:ReceivedQuantity>300</cbc:ReceivedQuantity>
136
<cac:DespatchLineReference>
<cbc:LineID>2</cbc:LineID>
</cac:DespatchLineReference>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
<cac:Item>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:ReceiptLine>
</ReceiptAdvice>
J. Invoice <?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 UBL-Invoice-2.0.xsd">
<cbc:ID>INV001</cbc:ID>
<cbc:IssueDate>2009-08-09</cbc:IssueDate>
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Supplier1</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>PCMaker Corporation</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:LegalMonetaryTotal>
<cbc:PayableAmount currencyID="GBP">27300</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity>100</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="GBP">4500</cbc:LineExtensionAmount>
<cac:Item>
<cbc:ModelName>SGBARHD250G</cbc:ModelName>
</cac:Item>
137
</cac:InvoiceLine>
<cac:InvoiceLine>
<cbc:ID>2</cbc:ID>
<cbc:InvoicedQuantity>300</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="GBP">22800</cbc:LineExtensionAmount>
<cac:Item>
<cbc:ModelName>AMDA64DUAL2.9</cbc:ModelName>
</cac:Item>
</cac:InvoiceLine>
</Invoice>
