A Recurring Invoicing Web Service Based on a Service ... · been given where reference has been...

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.

(Signature of student)

A Recurring Invoicing Web Service Based on a Service Oriented Architecture

Matthew J. Iveson

BSc Computing Session 2010/2011

i

Summary

This report details the challenges a SME (Small Medium Enterprise), specialising in online payments

software, would face when creating a web service and adopting a SOA to deliver their products. A

recurring invoicing web service was created and used as a case study.

Current practices and technologies were researched to gain an insight into the different options

available when constructing a web service and adopting a SOA. The challenges became clear after

undertaking research. With the completion of a requirement analysis the relevant tools and

methods for design and implementation were decided upon.

The design and implementation of the invoicing web service was then started, requirements were

fulfilled and exceeded at this stage. Once the implementation of the invoicing web service was

completed the success of the solution was evaluated using evaluation criteria. Finally, possible

further enhancements to the solution were proposed.

ii

Acknowledgements

I would like to thank my project supervisor, Lydia Lau, for her constant support and insightful

comments throughout this project. I would also like to thank my assessor, Karim Djemame, for his

invaluable feedback from both the mid-term project report and the progress meeting.

Next I would like to thank my family for their continued support throughout the last three years at

University, with a special thanks going to my mum for the outstanding proof reading of my project

and the interest shown in what I was working on for all those months.

Lastly I would like to thank my girlfriend for encouraging me to go to University, without her none of

this would have been possible.

iii

Contents

1 Introduction ........................................................................................................................... 1

1.1 Introducing the Problem ............................................................................................................ 1

1.1.1 Problem Domain – Online Payment Providers .................................................................... 1

1.1.2 Problem Definition .............................................................................................................. 1

1.2 Project Aim and Objectives ........................................................................................................ 2

1.2.1 Aim ...................................................................................................................................... 2

1.2.2 Objectives ............................................................................................................................ 2

1.3 Minimum Requirements ............................................................................................................ 3

1.4 Project Plan ................................................................................................................................ 3

1.4.1 Methodology ....................................................................................................................... 3

1.4.2 Iteration Plan ....................................................................................................................... 4

1.4.3 Schedule .............................................................................................................................. 4

1.6 Possible Enhancements .............................................................................................................. 5

1.7 Deliverables ................................................................................................................................ 5

1.8 Relevance to Degree .................................................................................................................. 5

2 Background Research .............................................................................................................. 6

2.1 Introduction................................................................................................................................ 6

2.2 SOA (Service Oriented Architecture) .......................................................................................... 6

2.2.1 Definitions ........................................................................................................................... 6

2.2.2 Claimed Benefits.................................................................................................................. 6

2.2.3 Limitations ........................................................................................................................... 7

2.2.4 Guidelines to construct web services based on a SOA ....................................................... 8

2.2.5 Previous Examples of SOA ................................................................................................... 8

2.2.5 Why choose SOA? ............................................................................................................. 10

2.3 Approaches for Web Service Implementation ......................................................................... 10

2.3.1 Definitions ......................................................................................................................... 10

2.3.2 SOAP vs. REST .................................................................................................................... 11

2.3.3 Choosing SOAP or REST for the Project ............................................................................. 13

2.4 Implementation Tools and Platforms ....................................................................................... 14

2.4.1 Windows Communication Foundation (WCF) ................................................................... 14

iv

2.4.2 .NET Framework ................................................................................................................ 14

2.4.3 C# and VB.NET ................................................................................................................... 14

2.5 Evaluation Techniques ............................................................................................................. 15

3 Requirement Analysis ................................................................................................................. 16

3.1 Introduction.............................................................................................................................. 16

3.2 Business Environment .............................................................................................................. 16

3.2.1 Target Market .................................................................................................................... 16

3.2.2 Nochex Product Range ...................................................................................................... 16

3.2.3 Competitors ....................................................................................................................... 17

3.2.4 In-house Technical Capability ............................................................................................ 18

3.2.5 Current Architecture ......................................................................................................... 18

3.3 Scope of Proposed Solution ..................................................................................................... 20

3.3.1 Invoicing Service Stakeholders .......................................................................................... 20

3.3.2 Business Requirements ..................................................................................................... 21

3.4 Functional Requirements .......................................................................................................... 21

3.5 Non-Functional Requirements ................................................................................................. 21

3.5.1 Usability ............................................................................................................................. 21

3.5.2 Data Integrity ..................................................................................................................... 22

3.5.3 Platform Compatibility ...................................................................................................... 22

3.5.4 Documentation.................................................................................................................. 22

3.5.5 Interoperability.................................................................................................................. 22

3.5.5 Scalability ........................................................................................................................... 22

3.6 Summary .................................................................................................................................. 22

4 Development: Design Stage .................................................................................................. 23

4.1 Introduction.............................................................................................................................. 23

4.2 Design of RESTful Invoicing Web Service ................................................................................. 24

4.2.1 Revised Architecture ......................................................................................................... 24

4.2.2 Invoicing Web Service Design............................................................................................ 25

4.2.3 Data ................................................................................................................................... 26

4.2.4 Methods ............................................................................................................................ 29

4.2.5 Presentation ...................................................................................................................... 30

4.3 Summary .................................................................................................................................. 31

v

5 Development: Iteration One – Invoicing Web Service ............................................................. 32

5.1 Introduction.............................................................................................................................. 32

5.2 Implementation ........................................................................................................................ 33

5.2.1 Invoicing Web Service Overview ....................................................................................... 33

5.2.2 Database Creation ............................................................................................................. 34

5.2.3 Custom XML Data Contracts ............................................................................................. 34

5.2.4 HTTP Methods ................................................................................................................... 36

5.2.5 Payment Creation .............................................................................................................. 37

5.2.6 Sending Invoices ................................................................................................................ 37

5.2.7 Updating Payment Records ............................................................................................... 38

5.2.8 Hosting the Invoicing Web Service .................................................................................... 38

5.2.9 Limiting Functionality ........................................................................................................ 39

5.2.10 Help page......................................................................................................................... 39

5.3 Testing ...................................................................................................................................... 40

5.3.1 Functionality Testing ......................................................................................................... 40

5.3.2 Client Feedback ................................................................................................................. 40

5.4 Summary .................................................................................................................................. 40

6 Development: Iteration Two – Front-End Client Application ................................................... 41

6.1 Introduction.............................................................................................................................. 41

6.2 Implementation ........................................................................................................................ 42

6.2.1 Front-End Website Overview ............................................................................................ 42

6.2.2 Coding Language behind the Website .............................................................................. 42

6.2.3 Front-End Layout ............................................................................................................... 42

6.2.4 Invoking the Invoicing Web Service .................................................................................. 42

6.2.5 Hosting the Front-End Application .................................................................................... 43

6.3 Testing ...................................................................................................................................... 43


6.3.2 Client Feedback ................................................................................................................. 43

6.4 Summary .................................................................................................................................. 43

7 Development: Iteration Three – Refining Invoicing Web Service ............................................. 44

7.1 Introduction.............................................................................................................................. 44

7.2 Implementation ........................................................................................................................ 45

vi

7.2.1 Invoicing Web Service ....................................................................................................... 45

7.2.2 Front-End Application for RESTful Invoicing Web Service ................................................ 46

7.3 Testing ...................................................................................................................................... 47


7.3.2 Client Feedback ................................................................................................................. 47

7.4 Summary .................................................................................................................................. 47

8 Evaluation ............................................................................................................................ 48

8.1 Introduction.............................................................................................................................. 48

8.2 Evaluation Criteria .................................................................................................................... 48

8.3 Business Evaluation .................................................................................................................. 49

8.3.1 Business Requirements ..................................................................................................... 49

8.4 Technical Evaluation ................................................................................................................. 50

8.4.1 Functional Requirements .................................................................................................. 50

8.4.2 Non-Functional Requirements .......................................................................................... 51

8.5 Evaluation on the Project .......................................................................................................... 57

8.6 Current Enhancements............................................................................................................. 58

9 Conclusion ............................................................................................................................ 59

9.1 Achievements ........................................................................................................................... 59

9.2 Future Work ............................................................................................................................. 60

References ................................................................................................................................. 61

Appendix A: Personal Reflection ................................................................................................. 63

Appendix B: Gantt Charts ........................................................................................................... 64

Appendix C: APC Diagram ........................................................................................................... 66

Appendix D: APC Handler ........................................................................................................... 67

Appendix E: Comparing the Old and New Administration Front-End Layout ................................. 69

Appendix F: Usability Testing - Front-End Application ................................................................. 70

Appendix G: Usability Testing – Invoicing Web Service ................................................................ 73

Appendix H: Questionnaire Results ............................................................................................ 76

Appendix I: Siege Data ............................................................................................................... 77

Appendix J: Browser Compatibility ............................................................................................. 78

vii

List of Figures

3.1 Nochex Architecture..................................................................................................................... 18

4.1 Design Stage Plan ......................................................................................................................... 23

4.2 Revised Nochex Architecture ....................................................................................................... 24

4.3 Invoicing Web Service Design....................................................................................................... 25

4.4 Entity Relationship Diagram for Invoice Database ....................................................................... 26

4.5 XML Design Table ......................................................................................................................... 27

4.6 Invoicing Web Service Functionality ............................................................................................ 29

4.7 Administration Layout for Invoicing Web Service ......................................................................... 30

4.8 Invoice Email Design ...................................................................................................................... 31

5.1 Iteration One Implementation Tasks ........................................................................................... 32

5.2 Merchant Data Contract............................................................................................................... 35

5.3 Entity List Search Example............................................................................................................ 35

5.4 While Loop through Start Date to End Date ................................................................................ 37

5.5 Customising Invoice...................................................................................................................... 38

5.6 Service Help Page ......................................................................................................................... 39

6.1 Iteration Two Implementation Tasks ........................................................................................... 41

6.2 Finding API Key XML Attribute ..................................................................................................... 43

7.1 Iteration Three Implementation Tasks ......................................................................................... 44

7.2 Returning Custom Return Code ................................................................................................... 45

7.3 Returning JSON Format ................................................................................................................ 46

8.1 Availability of GET Requests ......................................................................................................... 54

8.2 Availability of POST Requests ....................................................................................................... 55

8.3 Response Time of GET Requests .................................................................................................. 56

8.4 Response Time of POST Requests ................................................................................................ 56

1

Chapter 1

Introduction

1.1 Introducing the Problem

1.1.1 Problem Domain – Online Payment Providers

There are a variety of online payment providers available to choose from when considering

accepting payments over the internet. What separates these online payment providers is not only

the cost of the service, but also what services they offer and the functionality they provide to each of

their customers.

Amazon is one of the e-commerce giants offering a wide range of web services to both buyers and

sellers. One of their latest web services is the Amazon Elastic Compute Cloud (Amazon EC2) which

allows users to run applications on the Amazon infrastructure. To compete with businesses like

Amazon, smaller online payment providers are now being pressured to offer their customers a more

personal experience to facilitate the individual needs of customers. Therefore a selection of services

should be available for customers.

It may be more attractive for an online payment provider to have services as separate applications

which are only used when a customer requires them. The use of web services can be used in this

situation. This is moving towards a SOA (Service Oriented Architecture) where web services are

available to both the customer and business when needed.

1.1.2 Problem Definition

A SME (Small Medium Enterprise) online payment provider, Nochex Ltd, wishes to expand upon

their architecture to include the use of web services to deliver extra functionality to their customers.

In particular, they require a recurring invoicing service that can be used by their customers to set up

recurring invoices. Several customers have asked for this service and the business has noticed that

this service could potentially increase sales and their customer base by adding flexibility to the user’s

experience.

There are many technical and practical challenges when implementing a new software product into

an existing company’s architecture. Technical challenges include choosing the ideal technologies and

2

approaches to use in order to create an interoperable, customisable and usable web service. A

practical challenge is the effect introducing a new web service into the company may have on staff.

Training is often required in these situations which can be expensive. The challenges faced

throughout the project are documented and discussed. By creating an invoicing web service and

reporting on the process used to implement the web service into the current architecture, the aim is

to provide Nochex with the information needed to create more intelligent web services. In turn, this

would pave the way to a more SOA based future.

This report shows that moving away from traditional architectures such as N-tier towards a SOA

could prove to be beneficial for the business. Diao and Ma (2008) explain that using loosely-coupled

services will enable the system to become less complicated; problems with integrating

heterogeneous systems will disappear.

1.2 Project Aim and Objectives

1.2.1 Aim

To investigate the practical and technical challenges for a SME (Small Medium Enterprise)

specialising in online payment software for a range of clients, to create a web service and adopt a

SOA to deliver their products. This project will focus on the recurring invoicing web service as a case

study.

1.2.2 Objectives

1. To create a service that interfaces with the current Nochex system and its services.

Associated Tasks:

Construct current architecture

Design revised architecture around the web service being implemented

Learn technical platform

Design, build and test iterations to create web service

2. To provide an invoicing service that allows merchants to send invoices recurrently.

Associated Tasks:


Design, build and test iterations to create web service

3

3. To provide feedback on how to implement a service in the future and what the best practices

would be.

Associated Tasks:

Evaluation of Project

Documenting Project

4. Produce a front-end user application that invokes the web service

Associated Tasks:


Design, build and test iterations to create user application to invoke web service

1.3 Minimum Requirements

1. A design of the overall architecture and specification of the invoicing service using the SOA

concept.

2. An invoicing system which meets some essential functional requirements such as merchants

being able to take subscriptions.

3. A monitoring and notification mechanism which sends requests to customers for payment and

updates system once paid, sending confirmation to both merchant and customer.

4. A generic method to allow merchants to perform customisation in their invoicing service (e.g.

ability to create profiles for different customers) which will trigger different business processes.

1.4 Project Plan

1.4.1 Methodology

The first task is to hold a meeting with the client (Nochex) to discuss the creation of an invoicing web

service and the requirements that need to be met. It is imperative to investigate the technical and

practical challenges of creating a web service and introduce the idea of a SOA, all of which are

researched in the background reading chapter.

A rapid prototyping method is to be adopted for design which has components of design, build and

test. The design phase is to be completed in one phase giving more time for implementation. If

changes to the design occur they will be stated in the implementation stages. Pilone and Miles

(2008) suggest keeping iterations “short and sweet” so that change can be dealt with. With short

iterations it is easier to fix problems and update software according to renewed requirements or a

4

change in what the client wants. Before each iteration a plan should be defined to clearly identify

the tasks to be completed and their time allocation. After each iteration a short discussion is to be

held with the CTO (Chief Technical Officer) at Nochex, acting as client feedback which is a form of

testing.

For the evaluation stage of the project, a set of criteria are used to evaluate against. This is described

in depth in the evaluation chapter.

1.4.2 Iteration Plan

As described in the methodology it is necessary to have a plan before each iteration is embarked

upon. The iteration plans act as a useful resource as they define the exact tasks which need to be

completed and also the time to be spent on each task. This helps split up the iterations into

manageable tasks. The plans are shown in figures 4.1, 5.1, 6.1 and 7.1

The time allocated to each iteration is decided by the number and difficulty of tasks to be completed

and their priority. As this is a 600 hour project, twenty marks out of a hundred are available for the

delivery of the solution, therefore 120 hours are available between the iterations. A total of 110

hours are spent on the design and implementation leaving 10 hours solely for the testing phase of

the iterations. Testing is also a part of the implementation throughout, in order to check that all

functions created were working.

1.4.3 Schedule

The initial schedule was somewhat optimistic. Coding the solution was given a time allocation of

seven weeks. This was split into three iterations, each consisting of design, build and test stages. In

practise, the time needed was eight weeks. This was due to learning the technical platform which

was a steep learning curve. The revised schedule included an initial design phase lasting a week to

give more time for building the solution. Two weeks of each iteration was then spent on the build

stage.

The project schedule was represented as a Gantt chart due to its clear presentation and ability to

indicate milestones and important tasks. The associated tasks to meet the objectives, previously

described, are included in the Gantt chart. Both the initial and revised schedules are presented in

Appendix B.

5

1.6 Possible Enhancements

Create JSON capability for transferring data

Create invoice template that can be customised to include company logo

Rewrite the URL to hide the implementation language used

1.7 Deliverables

I. A recurring invoicing web service

II. A front-end application that invokes the web service to showcase its functionality

III. A report detailing the process behind creating a web service to lead towards a SOA,

focussing on the recurring invoicing web service

1.8 Relevance to Degree

This project will require knowledge gained from past modules completed at the University. The

distributed systems module in particular is invaluable as the content is strongly focussed towards

web services, their deployment and different architectures that can be applied. The creation of a

database within this project means the Databases Applications and Graphics module is beneficial as

it contains examples of good practice in database design.

Overall the skills acquired and the knowledge gained throughout studying Computing are strongly

tested throughout this project, allowing a demonstration of exactly what skills have been acquired

and how they can be utilised.

6

Chapter 2

Background Research

2.1 Introduction

In order to select the best and most current methods/requirements for the creation of a web service

and the implications associated with these, a great deal of background reading must be carried out

making sure the literature is reliable and current.

Mainly published journals and conference papers are used as they can be seen as reliable and

repeatable.

2.2 SOA (Service Oriented Architecture)

2.2.1 Definitions

2.2.1.1 SOA

“A service-oriented architecture (SOA) is a combination of consumers and services that collaborate,

is supported by and managed by a set of capabilities, is guided by principles, and is governed by

supporting standards” Bean (2007).

2.2.1.2 Web Service

“Self-contained, modular business applications that have open, Internet-oriented, standards-based

interfaces” Hoch and Kerr (2001).

2.2.2 Claimed Benefits

There are certain beneficial characteristics when adopting a SOA; these benefits have reinforced the

decision to adopt a SOA. When creating a web service a SOA is usually taken, the following section

will now explain the reasoning behind this architectural approach and how it could be implemented.

2.2.2.1 Flexibility

The flexibility provided by the architecture is one of the main advantages, “The loosely-coupled,

document-based, asynchronous nature of services in an SOA gives applications more flexibility to

evolve with changing business requirements” Diao and Ma (2008). This is ideal for when a business is

changing either because of growth or to keep up-to-date with current trends. Applications can be

7

easily and swiftly evolved because of their inherent flexibility due to the architecture. The flexibility

is important because it will give users a more unique experience using the system; they can choose

to use certain services to create a more customised user experience.

2.2.2.2 Reusability

Reusability is a huge benefit for a SOA, by creating a new web service dealing with recurring

invoicing; the service can be reused repeatedly by different clients for slightly different purposes.

“To reuse an existing business application, developer may wrap it as web services and then it is

ready to be invoked to meet new business requirements” Diao and Ma (2008). In turn, different

calibrations of the invoicing service could be used with new services, it could be shaped and reused

by other services to meet new requirements the business may set in the future.

2.2.2.3 Interoperability

One beneficial principle of using SOA is interoperability. “This can be realized through the use of web

services, which allows different distributed web services to run on a variety of software platforms

and hardware architectures” Diao and Ma (2008). Therefore the actual programming language is not

of concern as the web services will interact using a neutral data transfer language such as XML.

2.2.2.4 Scalability

“Services in an SOA are loosely coupled, and few dependencies exist between the client applications

and the services they use, which allows applications to scale easily” Diao and Ma (2008). This is an

important advantage of using a SOA in small, medium enterprises (SMEs) like Nochex, as the

potential for growth is great and scalability is extremely vital.

2.2.3 Limitations

Implementing a SOA boasts many benefits and also solutions to past problems which earlier

architectures encountered, but it does not solve every problem. The architecture does have a few

limitations which must be considered when designing a web service around it.

Wang and Liao (2009) describe some limitations and disadvantages of using a SOA, these will now be

described:

8

2.2.3.1 Performance

The main performance issue when implementing an SOA is the run-time. The actual performance of

the web services can be lowered under this architecture. Wang and Liao (2009) explain that “SOA

needs to be additionally wrapped as a standard component through intermediate software.” This

extra process can in fact slow down the run time because of the additional computation taking

place. In order to have a more flexible, open system, performance may be comprised, but in practise

this should only be a slight issue and not cause the system to run noticeably slower.

2.2.3.2 Immaturity

SOA is somewhat immature as it is a relatively new architecture. There are a lot of different

implementations of SOAs and finding the best set of practices and standards remains a challenging

task. To understand how to begin implementing a SOA it is necessary to understand the advantages

and disadvantages that this architecture brings and if it is suitable for the company and services in

question.

2.2.4 Guidelines to construct web services based on a SOA

There are several characteristics that should be followed when creating web services in a SOA.

Papazoglou and Heuvel (2007) list some important principles, they are as follows:

All functions in an SOA are defined as services. This applies to the web service that will be

created since its function is to create and send invoices and it will be defined as a service which

will be following the principles of SOA.

All services are autonomous, their operations are opaque. External components are not

concerned with how the service performs its particular functions they just presume that the

service will return the expected result. The service acts as a “black-box” meaning it is

independent of other services and does not require any other services to complete.

Interfaces are Invocable. Meaning services are not required to be local; they can be remote and

called upon when needed.

All these principles will be used when creating the recurring invoicing web service to make sure a

SOA and its characteristics are followed throughout.

2.2.5 Previous Examples of SOA

A SOA can and has been implemented in a wide range of companies. It is becoming a wise

architecture to adopt, whether it is a full implementation or just on one sector of the business. Xin

9

(2009) suggests that those companies who do not adopt a SOA may be “forced to play catch-up and

will be at a distinct disadvantage”.

Kokko, Antikainen and Systä (2009) explain use cases of where companies have adopted a SOA

approach. One of these companies is in the finance sector. They describe how the organisation’s

SOA adoption started in 2004, as the IT department started to notice that their current architecture

had certain limitations that included rigidity and a lack of tools to extend their business logic from

the legacy base. The organisation had to improve its services to the end user, based on decided

business requirements. This scenario is similar to the current project in showing that a SOA can be

implemented into the current Nochex systems and services. In addition, because this is a similar

scenario to the finance company it shows that other companies have already made the move to SOA

because they needed an updated architecture to keep on top of the market.

The finance company has separate SOA projects so the whole system has not completely changed

which is exactly the approach that will be taken in this project. By creating smaller SOA projects the

potential of the architecture can be showcased without changing the whole system at once. The

company’s SOA adoption was a gradual process where prototypes were used and once successful

they could be expanded into a working solution. However, they did encounter a few problems

implementing the architecture, especially with the IT sector of the business. The IT personnel had to

move away from familiar legacy systems and start utilising a new distributed server environment

which was the company’s chosen method when adopting SOA. They had to learn the new

architecture style and technology associated with it which placed strain on the employees and

generated a few negative attitudes towards SOA. This is an extremely important point to note, one

must consider the effect that implementing a SOA can have on existing staff as processes and

methods will change within the business in line with the new architecture and some staff may find

the transition quite difficult and even oppose to it.

Edwards (2007) describes another example. VocaLink, a UK-based payments processing company,

started the adoption of a SOA in 2002. They decided to make the change after a large technology

renewal for the UK payment infrastructure took place, and due to this they had to build their

infrastructure from the ground up. It is disappointing that within this article no explanation is made

of the actual methodology used by the company as this would have been extremely beneficial for an

insight into how a large company like VocaLink went about introducing a SOA into their current

legacy systems. VocaLink did not revamp their old systems they created new ones. Although this is

10

the ideal approach, companies like Nochex do not own the resources to do the same. The main

benefit VocaLink have taken advantage of is the flexibility SOA offers and the greater opportunity for

software reuse. The separate web services can be used repeatedly in different systems, increasing

their reuse and making the SOA model an extremely valuable asset.

2.2.5 Why choose SOA?

When faced with the problem of creating an invoicing web service that needs to interact with a

system already implemented, it is clear this task can be challenging. This web service must have solid

foundations and a sturdy architecture. There is a lot of information on the process of creating web

services and it is apparent that web services and SOA do go hand in hand. A SOA can create a solid

foundation and sturdy architecture for a web service, leading to the reason why a SOA was chosen.

Papazoglou and Heuvel (2007) describe how web services and SOA are linked “In an SOA, software

resources are packaged as “services”, which are well defined, self-contained modules that provide

standard business functionality and are independent of the state or context of other services.” In

effect, all the principles of web services are encompassed by the term SOA; this is why adopting a

SOA approach is a very interesting architectural approach to research.

2.3 Approaches for Web Service Implementation

The actual implementation of the invoicing web service based on a SOA is challenging and therefore

it is important that the right tools are chosen to aid with the creation of the service. The protocols

and tools that can be utilised are now discussed and a conclusion made about which ones to use,

bearing in mind what is most suitable for the current problem.

2.3.1 Definitions

2.3.1.1 REST (REpresentational State Transfer)

Elkstein (2008) defines REST as an architectural style which believes existing principles and protocols

of the web are enough to create web services.

2.3.2.2 SOAP (Simple Object Access Protocol)

“A lightweight protocol intended for exchanging structured information in a decentralized,

distributed environment. It uses XML technologies to define an extensible messaging framework

providing a message construct that can be exchanged over a variety of underlying protocols” W3C

(2007).

11

2.3.2 SOAP vs. REST

When creating a web service there are mainly two directions a developer can pursue, either a SOAP-

based or REST-based implementation. A comparison of these methods is vital in choosing the most

appropriate solution for the problem being presented.

For many years, SOAP has been the preferred choice for developers when deciding upon the

implementation of a web service; it is well documented and supported with rich tools.

However, SOAs do not require the use of SOAP; other methods of communicating with services exist

such as REST. REST is seen as an architectural style for distributed hypermedia systems. A RESTful

approach follows the belief that the existing principles and protocols of the web are enough to

create web services. Concisely, REST is based upon the architecture of the web. A significant point to

note with RESTful services is that they model the interaction with user agents based on resources, so

each resource is represented by a unique URI, and the user agent uses the uniform interface of HTTP

to interact with that resource using the URI. The idea of resources is a key construct in REST.

Some important characteristics of both SOAP and REST are now discussed leading to a conclusion

explaining which implementation, either SOAP or REST, is the most appropriate for the project.

2.3.2.1 Support

Papazoglou and Heuvel (2007) describe how web services using standards are the most popular type

available today; one of these standards is SOAP. This is one of the main advantages of using SOAP; it

is a recognised standard and is well documented. This aids development as documentation is readily

available when needed for guidance or clarification. Users trust this type of protocol as it has been

utilised for many years. In turn, one of the main advantages of using SOAP and the reason for its

current popularity amongst developers, is the wide range of tools and support that are available for

this protocol.

On the other hand, when it comes to support, REST is somewhat lacking. Because REST is not

considered a protocol or a standard it will never be academically defined by an organisation like

W3C. Therefore REST suffers when it comes to documentation and support. Conversely there are

several books detailing how to implement RESTful services and a standard approach to do so. But in

comparison with SOAP, REST is lacking in terms of support. However, large companies like Amazon

according to Tim O-Reilly (2003) claim that usage of their web services is 85% REST over SOAP. This is

12

interesting; it shows that a company as successful as Amazon can use more REST implementations

than SOAP so it is clear that REST works and can be seriously effective in some organisations despite

the lack of support. Also companies like eBay have a REST-API that “enables interaction by means of

a simple URL via HTTP at users’ disposal” Hochstein, Schwinn and Brenner (2009). This again shows

how large companies are using RESTful services and reaping the benefits of doing so.

2.3.2.2 State

SOAP can be a stateful design, meaning the web service maintains state information between

message calls. A session state can be kept which is created by a SOAP server that creates a session ID

which then gets sent to the client. This requires quite a lot of processing and does not scale too well.

REST uses a protocol that is client/server stateless. Vinoski (2008) explains how RESTful web services

by nature are stateless. Essentially “as each application uses one or more resources, it maintains its

own session state with respect to those. Servers keep resource state, of course, but avoiding the

need to keep session or application state on the server side is a big scalability win.” REST being

stateless is a brilliant aspect which enables greater scalability within applications.

2.3.2.3 Applying to SOA

“SOAP is by nature a platform-neutral and vendor-neutral standard. These characteristics allow for a

loosely coupled relationship between requester and provider” Papazoglou and Heuvel (2007). This is

ideal as this meets one of the major principles of SOA, all services have to be loosely coupled and

independent. Therefore by utilising SOAP these principles become a reality by default and a SOA is

clearly within reach.

SOAP has one major drawback, it is much better dealing with homogeneous systems. This

contradicts the fundamentals of SOA. One of the main principles of a SOA is that the systems within

the architecture do not need to be homogeneous; they can be different from one another but still

connect. So within heterogeneous environments SOAP can struggle more than REST. For example

Xin (2009) explains that “differences between the default SOAP encoding formats of Java EE

(document/literal encoding) and Microsoft.NET (RPC/literal encoding) technologies can cause

problems.” Therefore if two different technologies are being used within a company integrating a

SOA with SOAP messaging, serious problems could arise meaning the full potential of a SOA could

not be utilised.

13

REST on the other hand is renowned for being an excellent choice for heterogeneous systems and

services. RESTful web services are completely platform independent and can interact even if the

service it is connecting with is programmed in a different language. This is due to having resources as

URIs, so any program can send a POST to these URIs and they will receive a response back.

2.3.2.4 Methods

SOAP uses SOAP messages in order to communicate; Muracevic and Kurtagic (2009) describe SOAP

as acting as an envelope that carries messages along certain protocols. SOAP envelopes are passed

between the server and the client in order to communicate. SOAP solely uses HTTP POST.

REST on the other hand can use several interfaces for accessing resources; the methods of accessing

a resource are GET, POST, PUT or DELETE. The request-response messages are made up of the

method, a header and a body. This gives a lot of flexibility to the user and does not involve a SOAP

server or large messages wrapped in SOAP envelopes. As Elkstein (2008) explains one attractive

characteristic of a REST service is that the service runs on top of HTTP and is therefore standards-

based. HTTP is a trusted protocol and is reliable, meaning that RESTful services can also be trusted.

Since HTTP has been around since the birth of the web, this shows it is a reliable and robust

protocol.

2.3.3 Choosing SOAP or REST for the Project

Considering the categories looked at for both SOAP and REST a decision on which implementation to

adopt had to be made. SOAP has been used frequently when creating web services and has many

advantages. A well-rounded understanding of SOAP was developed through background research;

this gave many positive reasons for choosing a SOAP implementation but on balance; REST is the

ideal choice.

REST was chosen due to the simplicity of the approach. The approach uses existing principles and

protocols which are familiar, reliable and easy to use. This makes invoking the web service much

more accessible for the Nochex merchants, as it is simple to send calls to a RESTful service as HTTP

GET, POST, PUT and DELETE methods can be used to access a URI resource.

14

2.4 Implementation Tools and Platforms

2.4.1 Windows Communication Foundation (WCF)

Microsoft provides the following brief explanation of what WCF is: “Windows Communication

Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can

send data as asynchronous messages from one service endpoint to another”.

Zhang and Cheng (2010) describe WCF in an extremely positive manner “WCF provides unified SOA

programming model and is an ideal SOA implementation form.” They further explain how WCF can

be utilised in the design of services in order to create SOA implementations. By using WCF, inter-

loose coupling is possible.

WCF is ideal when creating a RESTful service as there are certain downloadable packages available

which have REST support. These packages create a more structured approach to the design of the

service and also saves time as without these packages custom functions have to be produced to

enable the use of REST with WCF.

The main reason for using WCF is to create a web service which uses SOA principles.

2.4.2 .NET Framework

The .NET framework is a software framework used on Microsoft Windows operating systems. It

supports a wide range of programming languages and includes a vast library to build a variety of

applications. Nochex is one of the many companies that use .NET because of the wide range of tools

and support it offers. The .NET framework is used through Visual Studio 2010 as this software is also

used at Nochex to great effect.

2.4.3 C# and VB.NET

The coding language C# is used for the invoicing web service as there is a considerable amount of

documentation associated with this language and the creation of web services. VB.NET is used when

creating the administration front-end application of the web service to showcase that the web

service (written in C#) can be accessed by any other language.

15

2.5 Evaluation Techniques

An extremely important aspect of the project is the evaluation. It is important to evaluate how

successful the proposed solution is in reality. There are many evaluation techniques that can be

utilised; to gain a detailed evaluation a combination of these are used. The two main types of data

obtained from evaluation techniques are quantitative and qualitative. Quantitative data is favoured

over qualitative as quantitative data can be visualised easily to produce graphs and it can be

expressed numerically.

Since a rapid prototyping method is being used with iterations of design, build and test the testing

phase is a form of on-going evaluation. A short meeting is held with the CTO (Chief Technical Officer)

of Nochex at the end of each iteration to discuss the product created and its success at this stage.

The usability of the solution can be taken into account using usability dimensions, Lindgaard (1994).

A questionnaire is to be created and completed by the two developers at Nochex. This questionnaire

uses the Likert scale, Bryman (2008), using a five-scale Likert item meaning there are five responses

available to the questions asked ranging from “1. Strongly disagree” to “5. Strongly agree”.

HTTP load testers can be utilised in order to retrieve data relating to a web service’s response time,

availability and other important attributes. The software uses concurrent threads to make multiple

calls to the web service. This form of testing is to be used in the evaluation of the solution.

Requirements can be evaluated against to assess whether they have been met or indeed exceed.

This can be determined by means of evaluation.

16

Chapter 3

Requirement Analysis

3.1 Introduction

The reason for undertaking a requirement analysis is to obtain a set of requirements that explicitly

state what the business is expecting from the solution. This ensures that when the development

phase of the project is reached there is a clear path to follow in order to fulfil these requirements

and to exceed them. The requirements will be partitioned into two categories: (i) business

requirements, in order to get a clear understanding of what the business expects the solution to be

capable of, and (ii) technical aspects in terms of functional and non-functional requirements. The

subsequent design, development and evaluation of the solution will take into consideration the

business, functional and non-functional requirements.

3.2 Business Environment

It is important to fully understand the business environment of Nochex before deciding upon the

specific requirements. This gives a better understanding of what the business currently offers and

the market they are in.

3.2.1 Target Market

The customers Nochex hope to entice are generally small to medium size businesses looking for an

online payment facilitation service to receive and make payments online. Usually these potential

customers will hire a web developer to design and develop their website. Therefore the target user

for the invoicing web service will be web developers with experience of HTML and XML.

3.2.2 Nochex Product Range

Nochex currently offer a range of accounts for potential customers, the two main accounts are a

Seller account and a Merchant account. With a Seller account the customer is limited to a £100

maximum transaction limit. There is no telephone support and certain features cannot be enabled

within their account, for instance they must keep the default layout of the checkout system.

17

Merchants on the other hand can customise their checkout to seamlessly integrate the Nochex

checkout system into their own website. Also merchants have a maximum transaction limit of up to

£1000 and telephone support.

Customers pay a setup fee of £50 to have a Merchant account with upgraded features; the proposed

invoicing web service can included within a Merchant account to give even more features to these

customers. In turn the addition of recurring invoicing may entice more customers to become

merchants.

3.2.3 Competitors

Diao and Ma (2008) explain how “internet industry leaders such as Google and eBay, successively

released their web services application programming interface (API) to the public.” They explain how

this made it possible for outside companies to use these service to integrate and customise their

own business functionality into their web sites or applications. This shows how successful creating

web services can truly be. An API is an interface which allows developers to invoke functions from

web services. This dramatically increases the customisability and flexibility of the user’s experience;

they can now embed web services within their own applications and create new experiences for

their own customers.

Cai, Chung and Su (2007) use Amazon as an example in demonstrating the power of using a SOA and

web services “Amazon.com … has evolved its business model from an online retailer to a service

provider for the retail industry – enabled by SOA and Web services technology. Its marketplace

partner model is highly successful, with tens of thousands of subscribers to its Web services-enabled

back-end interfaces.Amazon.com is now providing end-to-end services to other retailers, running

their entire on-line operations (including Web sites, orders, and fulfilments).” It is therefore

apparent that one of the reasons Amazon became so successful was their use of SOA and web

services as they were able to provide solutions to companies in a flexible and affordable approach.

PayPal, an online payment services company, allow businesses and consumers to send and receive

payments online. PayPal have a web services platform, they have various APIs that developers can

utilise to build new applications. The web services provide functionality for developers such as

searching for transactions and making refunds.

18

When considering updating the architecture of a company and creating web services it is important

to assess the competition to see what services they are currently offering and the infrastructure

behind them. The invoicing web service produced will hopefully inspire Nochex to update their

architecture to allow more web services and to have a more service oriented approach to compete

with some of the aforementioned companies by offering competitive services.

3.2.4 In-house Technical Capability

At present the technical team at Nochex comprises of a small team of developers who concentrate

on security and general updates, their main duties being the general upkeep of the Nochex systems.

This project gives an opportunity to showcase to the technical team how a RESTful invoicing web

service can be created and implemented within a non-SOA architecture and can hopefully lead the

way for more advanced web services to be created and for the adoption of an overall SOA.

3.2.5 Current Architecture

Figure 3.1: Nochex Architecture

As shown in figure 3.1 the current Nochex architecture can be described as monolithic using one

central database to store order, customer and payment data. The current systems and services

barely connect with one another meaning duplication of data is rife. Nochex has a severe lack of web

services; they mostly have systems that cannot connect to one another in an intelligent way.

19

3.2.5.1 Existing Nochex Systems

In order to truly understand what requirements are needed for the product it is important to

research into the existing Nochex systems, this gives a basic outline of the architecture currently

existing within the company and also what systems and services they currently offer. In turn, this will

give major insight into the current practices of the company and how the new service should

interact with the existing systems whilst demonstrating a different style of architecture.

3.2.5.2 Checkout System (Payment Pages)

The Nochex Payments Pages is the checkout process that customers use in order to pay through

Nochex. The Payments Pages is the key system that collects customer data and sends this on to the

relevant parties to complete the transaction. Merchants can modify the look of their payments

pages as to integrate the checkout process seamlessly into their own website. This idea of flexibility

to merchants is very appealing as it provides choice.

3.2.5.3 Automatic Payment Confirmation (APC)

The APC service confirms and authenticates any payment that is made into a merchant’s account

through communication between the Nochex server and the merchant’s server. This service is called

after a customer has completed a payment, through the Nochex payments pages. Appendix C shows

the exact functionality of APC. APC is an example of an existing service within Nochex, however it is

not a standalone web service, GET and POST HTTP requests are the only methods allowed and so it is

not a fully RESTful web service. Despite these factors it is an extremely useful tool that merchants

use in order to update their records and check if fraudulent activity has taken place. Therefore this

service can be used to update the invoicing web service, a tailored APC handler script will be

produced which will be called after a payment has been made to update the web service’s database.

3.2.5.4 Account Admin System

The account admin system is where users can login to their Nochex account and explore different

information regarding their account, such as transaction history and current balance. This system

has connections to the APC service and the payments pages, it can provide the user with information

on whether the APC service has been successful or not. In addition, a user can customise their

payments pages within the account admin system. This system is extremely user-friendly as the

interface is easy to utilise and it is just simple point and click.

20

3.2.5.5 SSL Image Hosting

Nochex has an SSL image hosting service that secures any non-secure image being sent through to

the payments pages after customisation. This is helpful in creating a secure platform for users. This

service is connected to the payments pages.

3.2.5.6 E-Support System

The E-Support system is used by both Nochex customers and staff. Customers can post support

tickets if they require any assistance with a problem they are experiencing and an employee will

reply to this ticket. In addition, there are support sections such as the knowledgebase section which

contains helpful articles on integration for customers, another example is the downloads section

which provides customers with guides and code to aid the implementation process.

3.2.5.7 Intranet

The intranet is strictly for Nochex employees; it contains information about all Nochex accounts and

has operations that can be performed on these accounts.

3.3 Scope of Proposed Solution

3.3.1 Invoicing Service Stakeholders

It is important to identify the stakeholders when creating a web service. Research into the existing

company’s systems aid in the identification of all the relevant stakeholders. They are as follows:

Merchants – Merchants are the user of the administration front-end application of the

invoicing web service, they create customer profiles and the payments that need to be

made. There can be any number of merchants and each merchant can have as many

customers as needed.

Merchant’s Developer – The merchant’s developer can integrate the invoicing web service

without the administration front-end application by making direct calls to the service.

Merchant’s Customers – The merchant adds their customers to the invoicing web service.

When a payment needs to be made an email is sent out to the customers with a link to pay

using Nochex. A customer’s role is to pay using Nochex after they are sent an email from the

invoicing web service.

Nochex – Nochex is a large stakeholder as Nochex’s services are used when a customer is

actually making the payment and also when the invoicing system is updating.

21

3.3.2 Business Requirements

Based on information gathered when researching into the current systems and services within

Nochex and also brief meetings with the CTO (Chief Technical Officer) of Nochex discussing the

design of the service, defined below are the specific business requirements.

Service must be easily accessible for staff, little training needed

Basic knowledge of XML and HTTP are enough to start using the service

Service Integrates with non-SOA architecture

3.4 Functional Requirements

Based on current knowledge and experience along with insight gained from the background research

carried out, defined below are the functional requirements that need to be met.

The service must be loosely-coupled and not completely rely on any other service

The service must provide accessibility only to those merchants who have created a merchant

entity

Merchants can create customer profiles detailing the start and end date of the invoicing period

A service that can update so it is clear when a payment has been made

An email function that sends an email to customer and merchant when payment is due

The service has to be hosted separately from Nochex

Database layer must be protected

Service must support the use of CRUD functions (Create/Read/Update/Delete) as HTTP requests

The data must be passed as XML in both Client-to-Service and Service-to-Client communication

3.5 Non-Functional Requirements

Below are the non-functional requirements that will need to be met. These are similarly based on

current knowledge and experience gained from the background research.

3.5.1 Usability

The web service will be used by web developers implementing a payment option into their client’s

websites. The service must be easily usable and use current practices that web developers

understand, therefore HTTP request methods will be utilised.

22

3.5.2 Data Integrity

The underlying database will store a variety of information that will have different data types; it is

important to check that the data being entered by the user is valid. An example relating specifically

to the invoicing service being produced would be to check that a valid date has been entered for the

start date and end date of the payments.

3.5.3 Platform Compatibility

As the web service will be situated on the web it must be compatible with all systems that have a

web browser installed so all that is needed to access the service is a connection to the internet.

3.5.4 Documentation

Documentation can be quite important for users, the user of the web service must be able to use the

service effectively. Without documentation this would be a difficult task.

3.5.5 Interoperability

As with most web services interoperability is an important requirement to note. Due to using HTTP

requests to process the different functions of the service, it must be interoperable with any language

that can connect to URLs and get responses from the requests made.

3.5.5 Scalability

An important requirement is that the solution is scalable, especially in the sense that the web service

can handle concurrent requests and remain available.

3.6 Summary

From researching into the background of the current systems and services Nochex provides, it has

now become clear how the new invoicing web service should interact with these systems and

services. The various business, functional and non-functional requirements gathered at this stage

will be followed carefully in the design phase to create a solution that meets all requirements laid

out in this chapter.

The requirements detailed within this chapter present a great deal of technical and practical

challenges for the design and implementation of the solution. The implementation stages will

describe how these challenges were overcome.

23

Chapter 4

Development:

Design Stage

4.1 Introduction

It is extremely important to design the various components of the solution before carrying out the

implementation. Figure 4.1 is a table explaining the design tasks that were required to be completed

prior to the implementation stage.

Total Hours: 20

Figure 4.1 Design Stage Plan

Task Estimated Time Required (hours)

Comments

Des

ign

Revised Nochex Architecture

2 Create revised architecture of Nochex after web service implementation.

Invoicing Web Service Design

3 Create a design for the general structure of the web service.

Database Design 3 Create Entity Relationship diagram for the database.

XML Design 2 Produce a design for the XML structure of the web service.

Functionality Design 5 Design the methods that will be created within the web service.

Invoice Design 2 Create an email template for invoices.

Administration Layout

2 Create the design layout for the front-end of the invoicing web service.

24

4.2 Design of RESTful Invoicing Web Service

4.2.1 Revised Architecture

Figure 4.2: Revised Nochex Architecture

As figure 4.2 shows, with the addition of the invoicing web service, a whole new branch of

possibilities are available to the client/merchant, they are no longer required to make a HTTP POST

to Nochex they can instead use the invoicing service to bill the customer. The revised Nochex

architecture indicates the systems and services that the invoicing web service can interact with.

The architecture of Nochex will move more towards a SOA as more web services are added. The

invoicing web service’s function and how it interacts with the services of Nochex will be described

clearly within the implementation stage.

25

4.2.2 Invoicing Web Service Design

Figure 4.3: Invoicing Web Service Design

The design of the invoicing web service shown in figure 4.3 illustrates how a client can invoke the

invoicing web service, there are two options available. One option is to make a direct request to the

invoicing web service using XML and a HTTP request. The XML sent is converted into an SQL query

with the results being sent back also as XML. The other option is to use the administration front-end

application to invoke the invoicing web service’s functionality. Merchants are more likely to use this

26

option as knowledge of HTTP requests and XML are not required. The application is a website that

provides a GUI for users to access the invoicing web service.

4.2.3 Data

Storing and recalling data is one of the key elements within the invoicing web service as each URI

acts as a resource and these resources must contain information. This information will be stored

within a MySQL database, located on a separate server to the main invoicing web service for security

reasons.

4.2.3.1 Database Entity Relationship Diagram

Figure 4.4: Entity Relationship Diagram for Invoice Database

A database entity relationship diagram was created in order to design a suitable database for the

invoicing web service. Figure 4.4 shows that each entity contains a Primary Key which is extremely

important when identifying specific records, also the attributes in bold represent fields that cannot

be NULL. The payments column of the invoice database will store the information returned after APC

has been activated.

27

4.2.3.2 XML Data

The design in figure 4.5 shows how the XML data will be structured when the web service returns a

record. This is also the structure a user would follow when creating or updating a record. They would

be required to send XML similar to this. The data in bold below demonstrates what information

could be displayed within the XML tags.

The XML design directly links to how the database will be structured and what columns are present

within the corresponding tables. Therefore all information within the database will be available

within the invoicing web service making every resource possible available.

Entity XML Structure

Merchants <merchants> <merchant>

<id>1</id> <firstname>Matthew</firstname> <lastname>Iveson</lastname> <nochexemail>[email protected]</nochexemail> <apikey>e84e4b3f-663f-4f50-8724-d100a0cf4fdd</apikey> <companyemail>[email protected]</companyemail> <companyname>Company</companyname> <companylogo>http://company.com/logo.jpg</companylogo>

</merchant> </merchants>

Customers <customers> <customer>

<id>1</id> <firstname>Bill</firstname> <lastname>Payer</lastname> <email>[email protected]</email> <description>Membership</description> <amount>5.99</amount> <frequencypay>6</frequencypay> <startdate>08/04/2011</startdate> <enddate>08/04/2012</enddate> <merchantid>NULL</merchantid>

</customer> </customers>

Payments <payments> <payment>

<id>1</id> <datesent>08/04/2011</datesent> <status>PAID</status> <to>[email protected]</to> <from>[email protected]</from> <authorised>AUTHORISED</authorised> <transactionid>2630453</transactionid>

28

<transactiondate>31/03/2011 20:19:07</transactiondate> <ordered>12345</orderid> <amountpaid>5.99</amountpaid> <merchantid>1</merchantid> <customerid>1</customerid> <invoicenumber>1</invoicenumber>

</payment> </payments>

Figure 4.5: XML Design Table

29

4.2.4 Methods

4.2.4.1 Functionality of the Invoicing Web Service

The web service must have certain functionality as described previously in Chapter 3. The web

service will contain methods that are implemented when a user sends a HTTP request to a specific

URI. These are shown in figure 4.5.

URI: http://mji-services.co.uk/InvoicingService.svc

Function Description CRUD Functionality

/merchants Get all merchants GET – get all merchant records

Create a merchant POST – create a new merchant

/merchants/{api_key} Get a merchant GET – get a merchant record

Update a merchant PUT – update a merchant record

Delete a merchant DELETE – delete a merchant record

/merchants/{api_key}/customers Get customers for specific merchant

GET – get all customers for a merchant

Create new customer POST – create a new customer

/merchants/{api_key}/customers/{c_id} Get a customer GET – get a customer record

Update a customer PUT – update a customer record

Delete a customer DELETE – delete a customer record

/merchants/{api_key}/customers/all/payments Get all payment records GET – get all payment records

/merchants/{api_key}/customers/{c_id}/payments Get payment records for specific customer

GET – get payment records for a customer

/merchants/all}/customers/all/payments/sendemail Send email to customers needing to pay today

GET – send email to customer needing to pay

Figure 4.6: Invoicing Web Service Functionality

The “api_key” variable in figure 4.6 is the API key which is a globally unique identifier that is unique

to each merchant record. Once a merchant account is created, this merchant will receive an API key.

This API key is required when using certain functions of the service and will identify the merchant

using the service therefore updating only their records.

30

4.2.5 Presentation

One of the presentation features of the invoicing web service supplies an administration section for

merchants. The administration section is a website that acts as a user-friendly interface for the

functions of the invoicing web service. The administration section is completely optional as the

invoicing web service can still be directly invoked using a HTTP request. The other presentation

component is an invoice email that is sent to customers that need to make a payment. These

components will now be designed in preparation for the implementation stage.

4.2.5.1 Administration Layout

Figure 4.7: Administration Layout for Invoicing Web Service

Figure 4.7 shows the general layout of the website, the layout will be similar throughout the whole

website. The menu links will correspond to functions that can be performed by the invoicing web

service such as creating a merchant entity. The user will be required to enter the information within

31

the text boxes and then press the button provided. The relevant return information will then be

displayed below the button separate of the other textboxes.

4.2.5.2 Invoice Design

An email invoice will be sent out to customers when their payment is due, the email will be

somewhat customisable, if a merchant specifies their company email, name and logo URL these will

be displayed within the email to their customers. Figure 4.8 illustrates how this email will be

presented.

Figure 4.8: Invoice Email Design

The values in “{}” are variables that will be unique to the invoice, for example if a merchant has

entered a company logo URL into their record stored in the database their logo will be displayed in

the same position as above.

4.3 Summary

The completion of the initial design phase produced useful designs that would be utilised in the

implementation stages. The design phase also aided in separating tasks within the iterations which

created a more focussed plan of the tasks that needed implementing.

32

Chapter 5

Development:

Iteration One – Invoicing Web Service

5.1 Introduction

Iteration one of the development stage focuses on the implementation of the RESTful web service

for invoicing. The creation of the invoicing web service is extremely important for all other iterations

and is also the main deliverable that will be used to evaluate the success of the project and whether

the solution meets the proposed requirements.

This section will describe the actual implementation of the solution. The design phase laid the

foundations of the work to be carried out, how this was actually implemented will now be detailed.


Comments

Imp

lem

enta

tio

n

Create database

3 Create database in MySQL using the design from figure 4.4

Create XML data contracts 5 Followed the XML design composed in figure 4.5

Create functions that can be called using HTTP requests

15 Follow functionality design in figure 4.6

Create payment records automatically

3 Once a customer entity has been create payment records for this customer must be created

Create function to send invoice

4 Create method that when called sends an invoice to the customers who have payments set to today’s date.

Update records after payment

5 Create APC handler file that updates payment records after payment

Hosting the web service 4 Deploy the web service to a web host

Limit functionality for non-merchants

3 Design functions so they require an API key

Create help page 2 Create a help page as documentation for users

Total Hours: 44

Figure 5.1: Iteration One Implementation Tasks

33

5.2 Implementation

5.2.1 Invoicing Web Service Overview

There are many methods that can be accessed when using the invoicing web service; it is the client’s

preference as to which of these functionalities they use. A client needs to create a merchant profile

when first using the web service. A POST request is made to the URL that creates a merchant, the

client sends the appropriate XML attributes detailing their personal information and then a unique

merchant profile is created. The response message from this request is XML showing the merchant

profile just created along with an API key which is essential for all other operations.

After the merchant profile is created and operational with the API key, a client can create a

customer profile. The customer profile has personal attributes so when an invoice is emailed to the

customer it is customised specifically for them. The most important attributes when creating a

customer profile are the frequency, start date and end date of the payment. When set, these

attributes automatically create payment records within the database, the number created

depending on these attributes. A while loop was created that iterated through the start date to the

end date by the frequency specified, so if a “6” is entered as the frequency, this would correspond to

6 month intervals.

A method runs daily to check the payments table in the database for any invoices that need to be

sent out. If the current date matches with any entries send out date the customised invoice will be

distributed to those customers, with a copy going to the merchant. This invoice contains a payment

link to Nochex which a customer is required to click.

Once the invoice arrives and the customer clicks on the payment link they pay using the Nochex

system. After payment, APC ensures that, a script is run automatically that updates the database

specifying that the customer has paid so that invoice will not be sent out again. Both the customer

and merchant are notified by Nochex that a payment has been made.

The “WCF REST Starter Kit Preview 2” toolkit was used in the creation of the RESTful web service due

to the many features and methods offered. The toolkit provides new .NET classes specifically

designed for the creation of a RESTful web service. The benefits of the toolkit will be discussed in

greater detail within this section.

Important aspects of the web service which are of particular interest will now be discussed.

34

5.2.2 Database Creation

A MySQL database was created which followed the database structure shown in figure 4.4. The

database contains three tables; merchants, customers and payments. This database is stored on a

web host and a separate server to the invoicing web service.

5.2.3 Custom XML Data Contracts

Distributing data using XML was a challenging aspect of the implementation process, so care had to

be taken when deciding which method should be used in order to create custom XML. Creating the

custom XML was the first stage of the implementation process as this would be the main function of

the web service, to distribute data between both the client and the service.

The main functionality of the invoicing web service was previously designed in figure 4.6. In order to

construct these functionalities XML entities had to be created to match the database structure.

Within the database created there were three main entities; merchants, customers and payments.

These entities all required a custom XML format in order to display their data to the client and

provide a way for the client to interact with the service.

The WCF programming model presented a useful way of creating custom XML formats; a

DataContract for each entity was created that listed all the entity’s attributes that needed to be

displayed as XML. These attributes act as a DataMember of the entity. Figure 5.2 displays this

process in detail, every XML variable was declared as a string, therefore some conversion had to be

carried out when either displaying or recording information within the database.

35

Figure 5.2: Merchant Data Contract

Following the XML design Figure 5.2 demonstrates how a DataContract was produced for the

merchant entity. To group these merchants together a CollectionDataContract was produced that

held a list of all merchants. This was beneficial in several ways, it provided a way to show all

merchants at once which is useful when trying to determine the popularity of the service and also it

provided a swift way of searching through these merchants to find the merchant with the

corresponding API key or other attribute as demonstrated in figure 5.3.

Figure 5.3: Entity List Search Example

Merchant FindMerchant(string api_key) { merList = GetAllMerchants(); foreach (Merchant merhant in merchantList) { if (merchant.APIKey == api_key) { return merchant; } } }

// Merchant Contracts [CollectionDataContract(Name = "merchants", Namespace = "")] public class Merchants : List<Merchant> { } [DataContract(Name = "merchant", Namespace = "")] public class Merchant { [DataMember(Name = "id", Order = 1)] public string MerchantId; [DataMember(Name = "firstname", Order = 2)] public string FirstName; [DataMember(Name = "lastname", Order = 3)] public string LastName; [DataMember(Name = "nochexemail", Order = 4)] public string NochexEmail; [DataMember(Name = "apikey", Order = 5)] public string APIKey; [DataMember(Name = "companyemail", Order = 6)] public string CompanyEmail; [DataMember(Name = "companyname", Order = 7)] public string CompanyName; [DataMember(Name = "companylogo", Order = 8)] public string CompanyLogo; }

36

Both the customer and the payment entities were constructed in a similar manner, making searching

through many customers and payments a much simpler task.

Although this proved to be a useful way of creating custom XML formats for the entities there were

other methods that could have been used. The XmlSerializer class was a considered method that has

been available in the .NET framework since .NET 1.0. The DataContract method was chosen as it is

specifically designed for WCF and more up-to-date.

5.2.4 HTTP Methods

One of the crucial functional requirements was to enable CRUD functions for clients using the

invoicing web service. In order to achieve this requirement the System.ServiceModel.Web class from

the “WCF REST Starter Kit Preview 2” was used. WebGet and WebInvoke are attributes that are used

to map the HTTP methods (GET, POST, PUT and DELETE) to the function being created, so they have

a specific HTTP interface.

These attributes were used for each function that was created; it was a swift process, made possible

by the “WCF REST Starter Kit Preview 2” toolkit. All functions followed the design from figure 4.6,

the URIs are the same as well as the available CRUD functions.

The HTTP method allowed in each function corresponds to what SQL query is performed on the

invoicing web service’s database. For example, if a DELETE request is made a DELETE SQL query is

constructed which deletes a record from the database. But if a POST request is made an INSERT SQL

query is constructed and used to add a new record to the database. A challenge when using a

MySQL database within Visual Studio was encountered as there was not an in-built class that

supported MySQL. A class had to be downloaded and referenced within the project in order to

utilise a MySQL database.

37

5.2.5 Payment Creation

To create payment records within the database, a separate class file was created to keep this

functionality separate. This made testing and debugging easier.

Figure 5.4: While Loop through Start Date to End Date

As figure 5.4 shows the DateTime objects created can be used to great effect within a while loop,

with each iteration of the loop the start date is changed by adding the number of months provided

as the frequency of payment. If a merchant created a customer profile that had “6” as the frequency

of payment and the start date and end date equated to a year there would only be two payments

created. This method is called during the creation of a customer so the payments are created within

the database straight away.

5.2.6 Sending Invoices

An invoice needs to be sent out to a customer whenever the start date indicates. Therefore a

function was created that matched the current date with the send date of the payment and if they

are equal the invoice is sent to the customer with a payment link attached.

As this function would have to be called every day a scheduled task was created on the web host. A

simple GET request is issued every day to the URL and the functionality behind it matches the dates

and then sends the customised invoices out.

To meet with the requirements the invoice had to be customisable, this challenging task was

completed using the MailMessage class. An email template was created with variables that could be

customised. These variables were customised for the customer before the invoice was sent.

InvoicingServ = new InvoicingService(); Customer customer = InvoicingServ.GetCustomer(api_key, customer_id); DateTime startdate = DateTime.Parse(customer.StartDate); DateTime enddate = DateTime.Parse(customer.EndDate);

while (startdate < enddate) {

//MySQL query to create payment startdate = startdate.AddMonths(Convert.ToInt16(customer.FrequencyPay));

}

38

Figure 5.5: Customising Invoice

As figure 5.5 shows, replacing the variables is achievable with the replace method within the body

object. The invoice design shown in figure 4.8 was followed in order to create an invoice template

with certain customisable variables and it was implemented as shown in figure 5.5.

5.2.7 Updating Payment Records

The invoicing web service meets the requirement that specifies that the service should not

completely rely on any other web service and that it should be loosely coupled. When creating

merchant and customer profiles along with payments and invoices no other service is required to

complete these tasks.

In order to update the payment to the status of “PAID” the invoicing web service interacts with the

Nochex APC service, described in the requirements analysis chapter. The merchant is required to

have an APC handler which is a script file that checks if APC has been authorised. An APC script file

was created specifically for the invoicing web service that connected to the database and updates

the payment, this code can be seen in Appendix D.

5.2.8 Hosting the Invoicing Web Service

The invoicing web service created is constantly running. A client can call upon this service when

needed. In order for this to be a reality within the project the web service has been deployed to a

host that can support the .NET Windows framework. This goes beyond the requirements, however it

was deemed necessary in order to fully test the invoicing web service.

When deploying the web service to the web host it is important for the settings to be configured

correctly for a RESTful service. Occasionally, depending on the web host’s settings, certain HTTP

verbs can be blocked, these verbs then have to be enabled to make sure that the requests are going

to be allowed, otherwise 405 “Method Not Allowed” exceptions occur. The WebDAV module has to

be removed as it conflicts with the PUT and DELETE requests.

Merchant merchant = GetMerchantID(pay.MerchantId); MailMessage mail = new MailMessage(); mail.Body = "<html><p><%CompanyLogo%></p></html>" mail.Body = mail.Body.Replace("<%CompanyLogo%>", merchant.CompanyLogo);

39

When moving from the ASP.NET development server to a web host it is important to note if any class

libraries have been downloaded separately and used within the solution. If so, they will have to be

uploaded to the server so they can be accessed and used by the web service.

The host also provides a secure database that is stored on a separate server, this correlated exactly

with the previous requirements that detailed that the database had to be on a separate server and

be secure along with the actual web service being hosted separately to the Nochex website.

5.2.9 Limiting Functionality

The challenge of limiting functionality and maintaining a secure web service is overcome with the

creation of an API key that must be provided within the URL to complete tasks like creating

customers. A client therefore has to make their own merchant profile before using the other

functions within the service. The API key is created automatically when a merchant creates a profile,

it is a globally unique identifier generated by the Guid class.

5.2.10 Help page

When using the “WCF REST Starter Kit Preview 2” the WebServiceHost2 class can be used in order to

generate an automatic help page. The documentation requirement is fulfilled by this page as every

function that can be utilised and called is displayed and described. Request examples are given to aid

clients who wish to use the service and do not know the correct XML to send through. The relevant

URLs are also displayed, with the HTTP methods available for use, either GET, POST, PUT or DELETE.

This documentation overcomes a practical challenge that Nochex may face, staff will not be familiar

with the new invoicing web service and will therefore require training which is expensive. The help

page irradiates this problem as self-learning can take place at a fast pace to get staff familiar with

the invoicing web service. Also guides for users will not have to be manually created.

Figure 5.6: Service Help Page

40

Figure 5.6 is an example of the invoicing web service help page; this is showing the

“GetAllMerchants” function which retrieves all the merchants that have been created. The method

is displayed along with relevant request and response examples.

5.3 Testing

5.3.1 Functionality Testing

The testing throughout was strenuous especially because the errors returned from the server were

not descriptive, the most common error was “Internal Server Error”. This was not informative and

did not detail what the actual problem was.

In order to test the functionality that was implemented as described in this chapter, the invoicing

web service had to be used to see whether the functions created acted as they were intended. As

the web service did not currently have an administration front-end application that could invoke the

invoicing web service, a web debugging proxy, “Fiddler”, was used to make calls to the web service

easily. By the end of the iteration all functions worked without any errors so it was clear that this

iteration had been successful in creating working functions.

5.3.2 Client Feedback

The feedback gained from the CTO (Chief Technical Officer) at Nochex was mostly positive. The

major improvement suggested was to generate a log that would keep track of any errors that may

occur when the web service is being utilised. This would also solve the problem experienced with the

unhelpful errors displayed when an error occurs, the log would provide additional information on

these errors helping development.

5.4 Summary

Iteration one was a significant iteration that presented the core of the RESTful invoicing web service

being created. The feedback obtained at this stage will be considered and utilised in the final

iteration detailed in a later chapter. The development of the administration front-end application for

the invoicing web service will now be addressed in the following chapter.

41

Chapter 6

Development:

Iteration Two – Front-End Client Application

6.1 Introduction

Iteration two of the development process focuses on the implementation of the administration

front-end of the web service that acts as the client application for merchants. This client application

accesses the web service’s methods and displays the data in an attractive way. The design of the

front-end layout produced in the design phase will be followed throughout the implementation to

make sure a solid front-end is created.


Comments

Imp

lmen

etat

ion

Creating the layout for the front-end

3 Followed the layout design composed in figure 4.7

Create functionality to call the invoicing web service

15 Create different functions that call the invoicing web service using information supplied by the user

Hosting the Front-End application

2 Deploy the front-end application on a web host

Total Hours: 20

Figure 6.1: Iteration Two Implementation Tasks

42

6.2 Implementation

6.2.1 Front-End Website Overview

The website produced acts as an administration front-end to the invoicing web service. The “Home”

page of the website is the “Create a Merchant” page. A user needs a merchant profile with their own

unique API key before they can use the rest of the functionality on the website.

The most important and interesting points will now be discussed in further detail.

6.2.2 Coding Language behind the Website

To illustrate that a variety of programming languages can be used to invoke the invoicing web

service created, it was essential for the requirements to show that a different language from C# can

be used to access the web service(C# was used to code the web service). Visual Basic was chosen

partly because Nochex uses this language within their business.

Visual Studio 2010 was still used in the development of the website and the .NET framework had

useful libraries that made reading and writing XML less laborious.

6.2.3 Front-End Layout

The layout from the design phase shown in figure 4.7 was followed and applied directly to the

solution without any changes. The layout was applied to each webpage individually making sure they

all followed the same layout style.

6.2.4 Invoking the Invoicing Web Service

The main purpose behind the website administration front-end application is to harness the

functionality provided within the invoicing web service and display an easy to use GUI for the user.

In order to use the invoicing web service a HTTP GET, POST, PUT or DELETE method has to be sent to

the appropriate URL, along with an XML string if needed. After this request has been sent the

response from the web service is displayed by the website in a suitable way.

As the data is transferred in XML between the web service and the client application, a class had to

be used which could search through this XML to return important attributes, such as the API key. To

overcome this challenge the XmlDocument class along with the XmlNode class were utilised when

searching through an XML response to find the relevant attribute.

43

Figure 6.2: Finding API Key XML Attribute

As figure 6.2 shows, returning the API key attribute value is successfully completed using the two

classes previously mentioned. The same process can be repeated with any attribute, which was

extremely useful for other functions within the client application.

6.2.5 Hosting the Front-End Application

The administration front-end application of the invoicing web service has been placed on the same

server as the invoicing web service so that the two components are in close proximity and calls made

between them are therefore fast.

6.3 Testing


The functionality within the administration front-end application was tested extensively by using a

variety of different values in the calls to the invoicing web service. By adding a status field within

each page of the website if a problem is encountered clear errors are presented in the status field,

giving an indication as to why the call wasn’t successful.


The comments made by the CTO (Chief Technical Officer) at Nochex were positive. However there

was a suggestion to generate tables showing the merchant’s payment history as opposed to showing

single payments and having to cycle through each one. The CTO was impressed by the general layout

and usability of the application and believed that the application would be usable for their

merchants.

6.4 Summary

Iteration two detailed the administration front-end application for the invoicing web service. The

implementation was described and testing was carried out. The feedback gained from the test phase

was useful and again will be utilised in the final iteration. The following chapter will describe the final

and third iteration taking into account the feedback gained from the previous iterations.

Dim document As XmlDocument = New XmlDocument() document.LoadXml(backstr) Dim node As XmlNode = document.DocumentElement.SelectSingleNode("//apikey") APIKeyTextBox.Text = node.InnerText

44

Chapter 7

Development:

Iteration Three – Refining Invoicing Web Service

7.1 Introduction

The third and final iteration is devoted to refining both the invoicing web service and the

administration front-end application for the web service. Based on the feedback obtained from the

company there are several improvements to be made. This chapter will explain these improvements.

Total Hours: 26

Figure 7.1: Iteration Three Implementation Tasks


Comments

Imp

lmen

etat

ion

W

eb

Ser

vice

Creating custom invoice template

3 Follow design in figure 4.8 to produce a template invoice

Create logging functionality

3 A logging function to catch any errors

Informative return codes

2 After HTTP requests have informative return codes

Implement JSON formatting

2 Give the user a choice of formatting in JSON or XML

Rewrite the URL 3 Hide the implementation language from users

Imp

lem

enta

tio

n

Fro

nt-

End

Add table functionality

3 When required display a table showing results

Add search function 5 Create a search utility for forgotten API key and customer ID

Create master page for the layout

5 Design and implement a master page that creates the layout for each page

45

7.2 Implementation

7.2.1 Invoicing Web Service

7.2.1.1 Custom Invoice Template

By definition the invoicing web service should be easily adaptable for other payment providers not

just Nochex. By allowing custom invoice templates there are a wide range of possibilities. The

invoicing web service can be adapted to a number of payment providers who use payment links.

Allowing custom email templates provides more freedom for merchants to create a template that

matches their company’s house style. Previously merchants could change just the logo within the

invoice email that was sent but not change the entire layout. Although this could be a useful feature,

more documentation would have to be provided to guide merchants through the process. An

external text file with the HTML of the email template can now be used as the invoice email.

7.2.1.2 Trace Log

One of the most important additions was adding a trace log that logs all calls made to the invoicing

web service and any errors that were encountered. The trace log pinpoints where the error has

occurred and gives a trace of what exactly has transpired. This made debugging much faster and will

also aid in detecting and fixing future problems that may occur.

7.2.1.3 Informative Return Codes

When commencing testing during iteration one, several HTTP POSTs were made to the service, each

time (when successful) the return code was “200 OK”. Although this is acceptable it would be much

more beneficial for the user to read the status code “201 Created” as it would be clear that an entity

has been created. By using the “WCF REST Starter Kit Preview 2” certain classes are available in

order to change these return codes to make them more meaningful, figure 7.2 demonstrates how a

“201 Created” status can be returned.

Figure 7.2: Returning Custom Return Code

7.2.1.4 JSON

XML is the ideal language to transfer the data from the web service to the client and vice versa and

XML formatting was a requirement that had to be met.

WebOperationContext context = WebOperationContext.Current; context.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.Created;

46

JSON (JavaScript Object Notation) is a data-exchange format that is language independent; it is both

machine and human friendly meaning it is easily read. To add greater functionality to the invoicing

web service and appeal to a greater audience some of who would prefer not to use XML, JSON

formatting was implemented so the user could choose whether the data was returned as XML or

JSON.

Figure 7.3: Returning JSON Format

In order to return the data in JSON format the response format had to be altered from the default

setting of XML. Figure 7.3 illustrates how this modification was made to return JSON.

7.2.1.5 URL Rewrite

In order to conceal the implementation language of the invoicing web service the URL rewrite

module was used within IIS 7. A regular expression was used in order to rewrite the URL that

contained the “.svc” extension to remove the extension. This also made the URL of the invoicing web

service easier to remember and more user friendly, creating a truly RESTful web service.

7.2.2 Front-End Application for RESTful Invoicing Web Service

7.2.2.1 Table Creation

To improve the administration front-end application the feedback gained in iteration two was taken

into consideration. Returning the results from the invoicing web service in a table proved to be a

time consuming task but the end result outweighed the time spent. Tables provided another

dimension to the administration front-end application showing the entire merchant’s payments

information or all the customers the merchant currently has, in an easily readable way.

7.2.2.2 Search for API Key using Email

It became clear through the implementation and testing that retaining the 25 character long API key

could prove quite difficult. If a merchant happened to forget/lose their API key a function was

created within the administration front-end application that could search for a merchant based upon

their email address. As email addresses are unique this function could be easily created to return the

merchant’s API key.

[WebGet(UriTemplate = "/merchants?format=json", ResponseFormat = WebMessageFormat.Json)]

47

7.2.2.3 Master Page

The administration front-end application originally did not include a master page and therefore the

graphics and styling from each page had to be copied over to the next page. This is not a very

effective way of keeping a certain style. A master page was therefore added to the administration

front-end application within the final iteration so in future if any alterations to the presentation of

the website were needed they could be changed easily and swiftly. The layout was slightly changed

from the design shown in figure 4.7 to a layout which was clearer and easier to use. A comparison

between the old and new layout can be found in Appendix E.

7.3 Testing


The final iteration added a lot of new functionality that had to be tested. With the addition of JSON

new functions were created that had to be tested, again these tests were carried out using “Fiddler”,

GET requests were made which returned a JSON file that could be opened using a text editor. There

are tools for certain browsers that will allow viewing of JSON directly within the browser.

The front-end application was tested again making sure results were displayed appropriately and

any errors that occurred were neatly displayed within the status field.


The feedback received by the CTO (Chief Technical Officer) at Nochex throughout has been

extremely helpful to make sure the end product is exactly what Nochex required. The feedback on

the third iteration was positive yet again describing how the invoicing web service has gone beyond

their expectations with the inclusion of JSON and other helpful functions.

7.4 Summary

Iteration three included extra functionality to both the core invoicing web service and the

administration front-end application. The requirements were achieved and indeed exceeded with

the implementation of JSON formatting, customised return codes and other features explained

previously. With the product now completed it is extremely important to evaluate the overall

success of the solution produced and the project as a whole, finding both the strengths and

weaknesses present. The next chapter will focus on the evaluation stage.

48

Chapter 8

Evaluation

8.1 Introduction

This section aims to evaluate whether the project has been a success. A set of evaluation criteria will

be described below that will be used to evaluate the solution that has been produced.

8.2 Evaluation Criteria

It is important to define suitable criteria for evaluation to properly measure the success of the

project. One of the main criteria for evaluation will be the requirements defined in Chapter 3. The

business evaluation will involve using the proposed business requirements as criteria to assess

whether they have been fulfilled.

The technical evaluation will include the functional and non-functional requirements as criteria. The

fulfilment of these requirements will be evaluated, with explanations and analysis given as to how

the solution met these requirements. Scalability is one of the major focal points of the technical

evaluation. Web services require scalability; otherwise heavy use of the service is unavailable.

Response time is another important measure which will be included in the evaluation. Usability will

also be an important criterion as the invoicing web service and the administration front-end

application must have high usability in order for users to be comfortable using them.

The project evaluation will assess the project as a whole; this will involve evaluation of time

management and the overall planning of the project. The criteria here will aid in evaluating what

worked well in the project and if there were any pitfalls or issues that needed to be overcome.

49

8.3 Business Evaluation

The business evaluation will focus on the business requirements listed in section 3.3.2. Each

requirement will be specified followed by a description explaining how this requirement has been

fulfilled.

8.3.1 Business Requirements

Service must be easily accessible for staff, little training needed

If the administration front-end of the invoicing web service was used, no training at all would be

needed as all staff are familiar with web forms and how to complete them. However, if the

administration front-end was not used and the invoicing web service was accessed directly,

some training would be required. The invoicing web service has a help page as shown in section

5.2.9. This help page lists all the available functions of the invoicing web service and the specifics

of how to use the functions. This page would act as the sole training resource for staff. Therefore

with this help page in mind, little training would be required to become familiar with the

invoicing web service.

Basic knowledge of XML and HTTP are enough to start using the service

When using the invoicing web service directly, XML is used for the data transfer and HTTP for the

actual requests. The development chapters demonstrated how this was made possible. The

creation of an administration front-end for the invoicing web service required only knowledge of

XML and HTTP to access the invoicing web service’s functionality to create, read, update and

delete records.

Service Integrates with non-SOA architecture

To fulfil this requirement the invoicing web service was integrated into the current non-SOA

architecture of Nochex. The Nochex APC service was used to integrate the invoicing web service

into the current Nochex architecture. The invoicing database is updated when APC has been

completed. When APC is run the status of the payment within the invoice database changes to

“PAID”, if APC has been successful. As the invoicing web service follows a SOA, integrating the

web service into a non-SOA did prove to be somewhat problematic, the only viable way was to

utilise the APC service that Nochex offers and create a unique APC handler that would connect

with the invoicing web service’s database.

50

8.4 Technical Evaluation

8.4.1 Functional Requirements

The functional requirements are described in section 3.4. The functional requirements are listed

below, with a description under each informing which part of the solution fulfils the given

requirement.

The service must be loosely-coupled and not completely rely on any other service

Following a SOA it was imperative that the web service was loosely-coupled and did not rely on

any other service. By using the RESTful approach when designing and implementing the invoicing

web service this requirement was fulfilled. A HTTP request with XML data is used when invoking

the invoicing web service, this request can be constructed in most programming languages. The

administration front-end of the invoicing web service was written in VB.NET while the invoicing

web service was written in C#, proving that the created invoicing web service is loosely-coupled.

The invoicing web service does not completely rely on any other service. Yet in order to update

the payment status, the APC service provided by Nochex is used.

The service must provide accessibility only to those merchants who have created a merchant

entity

When a merchant successfully creates a merchant profile they are provided with a unique API

key for their account. This key is a 25 character long, globally unique identifier. This API key is

required to use all other functions within the invoicing web service such as creating a customer

profile. Therefore the API key prevents unauthorised access to the web service, fulfilling this

requirement.

Merchants can create customer profiles detailing the start and end date of the invoicing period

After a merchant profile has been created and an API key is obtained, merchants can create

customer profiles that detail the start and end date of the invoicing period. With these dates and

the frequency of the payment the payment records are then created.

A service that can update so it is clear when a payment has been made

When a payment has successfully been made the APC service that Nochex provides is used to

run a custom APC handler script file, updating the invoicing web service’s database. The

payment table within the invoice database has a column “status”; this will be altered depending

on whether APC was successful or not.

51

An email function that sends an email to customer and merchant when payment is due

The invoicing web service contains a function that will run daily through a scheduled task as

shown in section 5.2.5 that sends an email to both customer and merchant when a payment is

due.

The service has to be hosted separately from Nochex

As explained in section 5.2.7 the invoicing web service including the administration front-end are

hosted on a separate server to Nochex, showcasing that the web service is invocable regardless

of where it is situated on the web.

Database layer must be protected

The database layer is again hosted on a separate server, keeping security in mind. The database

is protected from unauthorised users as a username and password are required to read or

modify any data.

Service must support the use of CRUD functions (Create/Read/Update/Delete) as HTTP requests

CRUD functions were implemented into the service as HTTP methods. Section 5.2.3 showcases

the use of the HTTP methods within the web service, detailing how the different CRUD

operations were integrated. The GET, POST, PUT and DELETE HTTP methods correspond to the

CRUD operations; therefore the requirement has been successfully fulfilled.

The data must be passed as XML in both Client-to-Service and Service-to-Client communication

XML was used within the web service when transporting data to and from the user to the

invoicing web service. JSON formatting was also introduced into the web service so users had a

choice of what format the data was transferred in.

8.4.2 Non-Functional Requirements

The non-functional requirements are described in section 3.5. The non-functional requirements are

listed below, followed by a discussion analysing the requirement that was fulfilled.

8.4.2.1 Usability

Procedure

Nochex has a small development team of two web developers. To evaluate the usability of both the

administration front-end application and the actual invoicing web service itself, the two developers

52

were given a set of pre-defined tasks. These tasks had to be completed, followed by a simple

questionnaire that allowed their experiences to be reflected. The pre-defined tasks and

questionnaire for the administration front-end application can be seen in Appendix F and Appendix G

for the invoicing web service.

A five-scale Likert item was used to give five response options ranging from “1. Strongly disagree” to

“5. Strongly agree”. There was one question on each questionnaire not relating to the five-scale

Likert item. This question allowed the developer to add any further comments if they wished.

Results

The results of the questionnaires can be seen in Appendix H along with a mean that was calculated

from the results. Although there were only two developers that completed the questionnaires this

will suffice as Nochex are the client and their comments are vital to evaluate the success of the

solution.

Analysis

There are a variety of important points that can be raised with regard to the results obtained. The

first is that the usability of the solution was highly rated. Feedback from the questionnaires was

extremely positive with most responses being “agree” or “strongly agree”. The first statement of the

invoicing web service questionnaire read “The Invoicing Web Service was easy to use”, the mean

answer resulted in a score of 4.5. This score is very encouraging and helps to show the high usability

of the solution, but it could still be improved. A similar statement was included in the administration

front-end application’s questionnaire. The mean of the results yielded a score of 5, this could not be

improved and emphasises how usable the administration front-end application is.

The answers obtained from the question “Any further comments?” on the invoicing web service

questionnaire produced several interesting points that can be noted. One developer described how

it would be beneficial to have an API key search function within the invoicing web service. This

would therefore no longer require the administration front-end application to perform this function.

If any future developments were made to the invoicing web service this function would definitely be

implemented. A developer also noted that the customer profile would benefit from additional

details such as an address and phone number. This was reemphasised by the mean result of the sixth

statement “The XML/JSON structure has all the information needed for merchants, customers and

payments” which was a score of 3. This was the lowest score gained which shows that the entities

53

should have more attributes to include more information. Again, if any future developments take

place these attributes would be added to the customer profile. The “Any further comments?”

question asked on the administration front-end application questionnaire also produced useful

suggestions. A developer described how the application could be improved if instructions on the

webpages were more in-depth. In regard to this feedback the instructions on the webpages were

improved.

The penultimate question on each questionnaire asked if the developer would use the invoicing web

service and administration front-end application again. The mean score of the results gave a score of

5, which again meant the application’s usability was of a high standard.

8.4.2.2 Data Integrity

All data passed to the web service is treated as a string, it is then converted into the appropriate

format for the database. This server-side validation is carried out before any data is written to the

database which ensures that data stored within the database is valid.

8.4.2.3 Platform Compatibility

Many different browsers were used to test the compatibility of the invoicing web service. Although

the data was displayed differently on each browser no problems were encountered. This shows that

the web service is platform compatible. Screen captures of the various web browsers used to test

compatibility can be seen in Appendix J.

8.4.2.4 Documentation

The documentation provided by the invoicing web service is in the form of a help page that is

automatically generated when the service is deployed. This provides adequate documentation for all

users and aids in showcasing the functions that the service provides while explaining how to actually

use the service and its functions.

8.4.2.5 Interoperability

The web service is accessed by HTTP requests with XML or JSON data that can be executed by the

majority of programming languages so the invoicing web service is truly interoperable between

different programming languages. For example Java, PHP and Python can be used to make these

requests.

54

8.4.2.6 Scalability

Procedure

Scalability was evaluated using Siege, a HTTP load tester, which can determine the availability of a

web service under a certain amount of concurrent users over a specified time. Siege uses multiple

concurrent threads to send its requests. The invoicing web service can be put under stress by varying

the amount of concurrent users trying to access a particular resource either using a GET or POST

request. From the test carried out the availability of the web service is recorded showing how

scalable the service is when under stress. The availability indicates the percentage of successful

requests that were made. If availability is low many failed requests were made.

Results

The results obtained from the siege tests were recorded and then utilised to create graphical

representations. The full data can be seen in Appendix I which includes the number of failed

requests.

Figure 8.1: Availability of GET Requests

80

85

90

95

100

30 60 120 240

Ava

ilab

ility

(%

)

Time (seconds)

Availability of GET Requests

10 Concurrent Users

20 Concurrent Users

40 Concurrent Users

60 Concurrent Users

55

Figure 8.2: Availability of POST Requests

Analysis

The availability of GET requests is quite positive until a certain number of concurrent users are

reached. When 10 concurrent users are active the web service will be 100% available but if the

concurrent users grow beyond 20, the availability starts to decline as shown in figure 8.1. GET

requests will be frequently used by merchants to check if a payment has been received, therefore 60

merchants using the invoicing web service at once is likely. When 60 concurrent users send GET

requests over 240 seconds the invoicing web service’s availability is 90%. This result is positive and

shows the invoicing web service is scalable, but the availability could be improved upon which in

turn would increase scalability.

When POST requests were used it was interesting to find that with 10 or 20 concurrent users the

availability was again 100% with no failed requests. However, when the concurrent user number

climbed higher than 20 the failed requests raised. This could potentially be a major downfall of the

invoicing web service. When requests fail the action intended is not performed and the user has to

repeat the request which can add to the problem. Figure 8.2 illustrates the extent of the availability

when the service was under stress.

If Nochex deployed the invoicing web service and it was not accessible for a long duration of time a

large number of potential payments would be lost and merchants would start to complain. The

invoicing web service could be deployed within the Nochex architecture for a trial period to truly test

the scalability.

70

75

80

85

90

95

100

30 60 120 240

Ava

ilab

ility

(%

)

Time (seconds)

Availability of POST Requests

10 Concurrent Users

20 Concurrent Users

40 Concurrent Users

60 Concurrent Users

56

8.4.2.7 Response Time

Procedure

Siege was once again used to evaluate the response time of the invoicing web service. A number of

concurrent users were used to make requests continually over a specified time period. The time

periods were 30, 60, 120 and 240 seconds with 10, 20, 40 and 60 concurrent users being used within

each period.

Results

The results obtained from the siege tests were recorded and then utilised to create graphical

representations; the full data can be seen in Appendix I. The following graphs represent the response

time gained using GET and POST requests.

Figure 8.3: Response Time of GET Requests

Figure 8.4: Response Time of POST Requests

0

0.2

0.4

0.6

0.8

1

1.2

1.4

30 60 120 240

Re

spo

nse

Tim

e (

s)

Time (seconds)

Response Time of GET Requests

10 Concurrent Users

20 Concurrent Users

40 Concurrent Users

60 Concurrent Users

0

2

4

6

8

10

12

14

30 60 120 240

Re

spo

nse

Tim

e (

s)

Time (seconds)

Response Time of POST Requests

10 Concurrent Users

20 Concurrent Users

40 Concurrent Users

60 Concurrent Users

57

Analysis

The response times of the GET requests shown in figure 8.3 were minimal and did not fluctuate too

much when more concurrent users were added. The response time stayed relatively static as the

time increased from 30 seconds to 240 seconds. This result demonstrates that if the invoicing web

service had many users accessing a URI at once the response time would not suffer greatly.

When testing POST requests the response times tended to fluctuate greater than GET requests.

There was a significant difference in the response time when 10 concurrent users were active

compared to 60 concurrent users. Figure 8.4 illustrates when 60 concurrent users are making

requests over 240 seconds the response time is around 12 seconds. This is a long wait for users and

could be seen as unacceptable. Although these findings show that under stress the invoicing web

service’s response time becomes gradually worse.

The choice made to implement a RESTful approach was definitely justified by the response times

recorded. If SOAP was used the lengthy SOAP messages and extra SOAP server may have created

much slower response times.

8.5 Evaluation on the Project

Time Management and Planning

Once the schedule was revised the project ran accordingly. Implementation of the invoicing web

service did however take longer than predicted as there were issues with deploying the service to a

suitable web host. The planning carried out for the iterations was a success as the separate design

and implementation plans helped to keep the project on track.

Due to effective planning, additional features were implemented that went beyond the proposed

requirements. Such features include implementing JSON formatting into the web service.

The methodology was followed exactly throughout the process which allowed management of time

to be effective. The next step was always clear so there was no wasted time.

58

8.6 Current Enhancements

Create JSON capability for transferring data

This function was implemented in the third iteration, users can choose between XML or

JSON to return and send data.

Create invoice template that can be customised to include company logo

The customisable invoicing template was designed in the design phase and then

implemented in iteration one as it was apparent that it would be beneficial if a logo could be

added to the invoice. The invoices with custom logos give a professional and personal

appearance.

Rewrite the URL to hide the implementation language used

As described in section 7.2.1.5 the URL rewrite module was used in order to hide the

implementation language used.

59

Chapter 9

Conclusion

9.1 Achievements

The project’s aim was to “investigate the technical and practical challenges for a SME (Small Medium

Enterprise) specialising in online payment software for a range of clients, to create a web service and

adopt a SOA to deliver their products. This project will focus on the recurring invoicing web service as

a case study.” Overall the project has been a success with this aim being achieved and all

requirements set fulfilled. The project presented a RESTful invoicing web service based on a SOA and

detailed the methods, tools and resources used within the web service’s creation. This report can

now be utilised by Nochex to create new additional web services that will eventually allow a SOA to

be fully implemented. The technical and practical challenges have been described throughout,

detailing how in the future the company could design and implement a web service.

From the usability testing it is clear that the invoicing web service exceeded the expectations of the

client, Nochex. One of the main achievements of this project was the design and implementation of

a solution that went beyond what was required to produce an overall solution that impressed the

client.

The evaluation also yielded mainly positive results, showing how usable the invoicing web service is

and how little documentation and training are needed to begin using the service. However it has to

be noted that scalability and response time could be improved.

The invoicing web service created offers new functionality to potential Nochex merchants allowing

them to take payments with recurring invoices. A merchant has the choice to use this service,

providing a personalised experience. With the addition of this invoicing web service Nochex can

compete with rival online payment providers offering similar services. Additional benefits will be

gained if more web services are created and a SOA is adopted.

60

9.2 Future Work

All the possible enhancements listed in Chapter 1 have been implemented to great success, however

there are still certain improvements that could be made that became apparent after the evaluation

stage. Future enhancements include:

Link invoicing web service with other online payments providers other than Nochex

Give the option to download payment records as a .CSV file

Create functionality to accumulate all money received and display as a current balance

Send a reminder invoice to a customer who still has not paid within a given time period

If any future developments take place these enhancements will definitely be integrated into the

invoicing web service to further expand its functionality.

61

References

Bean J. SOA from A-to-Z. (Presented at DAMA International and Wilshire Metadata conference,

Boston, 2007):8.

Bryman, A. Social Research Methods, Third Edition. Oxford and New York: Oxford University press,

2008

Hong Cai; Jen-Yao Chung; Hui Su; , "Relooking at Services Science and Services Innovation," e-

Business Engineering, 2007. ICEBE 2007. IEEE International Conference on , vol., no., pp.427-432, 24-

26 Oct. 2007

Lilin Diao; Yanan Ma; , "A Versatile SOA-based E-Business Platform," Electronic Commerce and

Security, 2008 International Symposium on , vol., no., pp.638-641, 3-5 Aug. 2008

Edwards, C.; , "Payback for SOA adopters," Information Professional , vol.4, no.5, pp.26-27, October-

November 2007

Dr. M. Elkstein, http://rest.elkstein.org/2008/02/rest-as-lightweight-web-services.html, 2008

Holley, K., Channabasavaiah, K., Tuggle, E.M., Jr.: Migrating to a Service-Oriented Architecture. IBM

DeveloperWorks, December 2003

Kokko, T.; Antikainen, J.; Systa, T.; , "Adopting SOA – Experiences from Nine Finnish Organizations,"

Software Maintenance and Reengineering, 2009. CSMR '09. 13th European Conference on , vol., no.,

pp.129-138, 24-27 March 2009

Lindgaard, G., “Usability Testing And System Evaluation”, Chapman & Hall, 1994

Microsoft Corporation, "Windows Communication Foundation," 2003,

http://msdn.microsoft.com/en-us/library/ms731082.aspx

Mike P. Papazoglou · Willem-Jan van den Heuvel, “Service oriented architectures: approaches,

technologies and research issues”. Springer, 3 March 2007

62

Muracevic, D.; Kurtagic, H.; , "Geospatial SOA using RESTful web services," Information Technology

Interfaces, 2009. ITI '09. Proceedings of the ITI 2009 31st International Conference on , vol., no.,

pp.199-204, 22-25 June 2009

Tim O-Reilly, “REST vs. SOAP at Amazon”, http://www.oreillynet.com/pub/wlg/3005, Apr 2003

Vinoski, S.; , "RESTful Web Services Development Checklist," Internet Computing, IEEE , vol.12, no.6,

pp.96-95, Nov.-Dec. 2008

Ying-Hong Wang; Jingo Chenghorng Liao; , "Why or Why Not Service Oriented Architecture," Services

Science, Management and Engineering, 2009. SSME '09. IITA International Conference on , vol., no.,

pp.65-68, 11-12 July 2009

Chen Xin; , "Service-oriented architecture in business," Computing, Communication, Control, and

Management, 2009. CCCM 2009. ISECS International Colloquium on, vol.4, no., pp.521-524, 8-9 Aug.

2009

Wei Zhang; Guixue Cheng; , "Research and Application of SOA Based on Current Technologies," Web

Information Systems and Mining (WISM), 2010 International Conference on , vol.2, no., pp.359-362,

23-24 Oct. 2010

63

Appendix A: Personal Reflection

Completing this project proved to be an extremely difficult and challenging task which would test

and develop all the skills I had learnt throughout my University career. On completion of the project

my programming, time management and planning skills had all improved dramatically.

As I had the experience of working for a client I learnt many lessons that will help when working for

a client in the future. The main issue I encountered was at the start of the project the client was

vague about what the functionality requirements were and these requirements were changed

several times. This led to many wasted and confused hours. I would strongly recommend always

having an agenda when meeting with a client as it adds a professional focus to the meeting.

To avoid the enormity of the project becoming overwhelming, I created a suitable project plan that

helped to prioritise the tasks that needed to be carried out. Therefore I would advise splitting the

project up into smaller tasks which can be easily managed; this was the key to keeping on track with

my schedule.

An important lesson I was forced to learn was not to create a too ambitious schedule. I believed that

implementation of the product would be much faster than it actually was. I did not take into account

how long it would take to become familiar with programming languages and software I had never

used before. Also, deploying a web service to a host proved to be a very taxing activity which took an

extremely long time. Therefore, always plan for the worst, expect delays somewhere within the

project and then there will be less distress when these delays do occur. Especially when embarking

upon using a new programming language enough time must be allocated to become fully familiar

with the syntax.

One major piece of advice I would give is to choose a topic which is of particular interest. My choice

of topic meant that throughout the project I remained engaged and enthusiastic about what I was

working on and never doubted my decision.

Overall I have learnt a variety of important lessons throughout this process, lessons that I will never

forget. These will be built upon throughout my career in Computing.

64

Appendix B: Initial Gantt Chart

65

Revised Gantt Chart

66

Appendix C: APC Diagram

Legend:

The red arrows show the customer’s experience, they just see the immediate effects. They will see the updated

webpage after APC has been successful, if you have a success URL, this will be displayed.

The blue arrow shows the APC token and what route it takes round the system.

Steps:

The details you received are then posted back to the Nochex server using your APC listener.

You can implement various optional actions within your APC listener, some of which include; sending an email

with the APC response to your email address and updating your database or records.

A customer visits your website.

Your customer decides to pay using Nochex, which you have integrated into your website.

Once your customer has entered all their details they will be sent to the Nochex server to be checked.

The Nochex server will then send an APC response to your APC listener with either an “AUTHORISED” or

“DECLINED” response; for the purpose of this diagram we assume it was the “AUTHORISED” response.

After the optional actions and checking of details are complete you can then update your website, either to

show a success URL or the current status of your customer’s order.

4

1

2

3

5

6

7

2 1 3

4

6

7

5

67

Appendix D: APC Handler

<?php

// Get the POST information from Nochex server

$postvars = http_build_query($_POST);

// Set parameters for the email

$to = '[email protected]';

$url = "http://www.nochex.com/nochex.dll/apc/apc";

mail( $to, 'APC', $postvars);

// Curl code to post variables back

$ch = curl_init(); // Initialise the curl tranfer

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_POST, true);

curl_setopt($ch, CURLOPT_POSTFIELDS, $postvars); // Set POST fields

curl_setopt ($ch, CURLOPT_TIMEOUT, 60); // set connection time out variable - 60 seconds

curl_setopt ($ch, CURLOPT_SSLVERSION, 3); // set openSSL version variable to 3

$output = curl_exec($ch); // Post back

curl_close($ch);

//If statement

if (!strstr($output, "AUTHORISED")) { // searches response to see if AUTHORISED is present if it isn’t a failure

message is displayed

}

else {

$msg = "APC was AUTHORISED.\r\n\r\n$debug"; // if AUTHORISED was found in the response then it was

successful

if (isset($_GET['pid'])) {

$paymentID = $_GET['pid'];

}

if (isset($_POST['transaction_id'])) {

$transactionid = $_POST['transaction_id'];

}

if (isset($_POST['order_id'])) {

$orderid = $_POST['order_id'];

}

68

if (isset($_POST['amount'])) {

$amount = $_POST['amount'];

}

if (isset($_POST['status'])) {

$state = $_POST['status'];

}

//End Variables

if ($state == "test") {

$status = "TEST PAID";

} else {

$status = "PAID";

}

$passed = "AUTHORISED";

//Connecting to DB

$dbhost = 'mysql1097.netcetera.co.uk';

$dbuser = 'mjiservices';

$dbpass = ‘********’;

$dbname = 'InvoiceDB';

$conn = mysql_connect($dbhost, $dbuser, $dbpass);

$selected = mysql_select_db($dbname,$conn);

$query = "UPDATE Payments SET status='$status', authorised='$passed',

transactionid='$transactionid', transactiondate=NOW(), orderid='$orderid', amountpaid='$amount' WHERE

payment_id='$paymentID'";

mysql_query($query);

mysql_close($conn);

}

?>

69

Appendix E: Comparing the Old and New Administration Front-End Layout

Old Layout

New Layout

70

Appendix F: Usability Testing - Front-End Application

Usability Testing – Front-End

Introduction

To evaluate the front-end of the invoicing web service usability testing is required.

Please complete the following tasks below in the relevant order proposed. After all tasks

have been completed or attempted find the questionnaire attached and complete.

Instructions

1. Open your default browser and access the website:

http://mji-services.co.uk/front-end

2. Create a merchant entity using your own details

3. Create a custom entity but enter the email address as your own and make the start

date today’s date

4. Find payment and check the status

5. Find payment and check the changed status

6. Check your email inbox that was entered as the customer’s email address

7. Open the email from the invoicing service and click on the payment link

8. Pay through Nochex with any details

9. After successful payment, find the payment and check the changed status

10. Update customer to have different name

71

11. Update your merchant entity to have a different name

12. Search for your API key using your email address

13. Delete both customer entity then merchant entity

Thank you for completing the tasks above. Please find the attached questionnaire and

complete.

72

Questionnaire

13 Any further comments?

1 2 3 4 5

1 The front-end of the Invoicing Web Service was easy to use

2 All tasks were easy to complete

3 Any errors returned are easy to fix given the error message

4 The search function to find forgotten API Keys is useful

5 The system is not missing any functionality that I would expect

6 The functions of the system have a quick response time

7 The instructions present on the website are helpful and informative

8 The layout is consistent and professional

9 It is easy to find which function I need to use

10 The invoice sent as an email looked professional and was superior to a plain text invoice

11 I am satisfied with the overall usability of the front-end of the invoicing web service

12 I would use the front-end of the invoicing web service again

Strongly

Disagree

Strongly

Agree

73

Appendix G: Usability Testing – Invoicing Web Service

Usability Testing – Web Service

Introduction

To evaluate the actual invoicing web service’s functions without the front-end usability

testing is required.

Please complete the following tasks below in the relevant order proposed. After all tasks

have been completed or attempted find the questionnaire attached and complete.

Instructions

1. Open your default browser and access the help webpage of the web service:

http://mji-services.co.uk/webservice/invoicingservice/help

2. After familiarising with the functions available, complete a GET request to find all

merchants

3. Create a new merchant entity either using XML or JSON to form the POST request,

get the response from the POST and copy the API key for future reference

4. Create a new customer entity either using XML or JSON to form the POST request,

but enter the email address as your own and make the start date today’s date

5. Complete a GET request to view all customers

6. Complete a GET request to view the customer’s payments

7. Open the email from the invoicing service and click on the payment link

8. Pay through Nochex with any details

9. After successful payment, complete another GET request to view the customer’s

payments

74

10. Update customer to have different name either using XML or JSON to form the PUT

request

11. Update your merchant entity to have a different name either using XML or JSON to

form the PUT request

12. Delete both customer entity then merchant entity either using XML or JSON to form

the DELETE request

Thank you for completing the tasks above. Please find the attached questionnaire and

complete.

75

Questionnaire

11 Any further comments?

1 2 3 4 5

1 The Invoicing Web Service’s functions were easy to use

2 All tasks were easy to complete

3 The help page was helpful and informative, providing all the information required to use the web service

4 The URLs of the web service are user friendly, easy to recall and correspond to the functionality they have

5 Having the choice between XML and JSON is a good feature

6 The XML/JSON structure has all the information needed for merchants, customers and payments

7 The return status codes are useful, especially the “201 Created” status after a successful POST request

8 All expected functionality is included

9 I am satisfied with the overall usability of the web service

10 I would use the web service again

Strongly

Disagree

Strongly

Agree

76

Appendix H: Questionnaire Results

Administration Front-End Application

Web Developer One

Question 1 2 3 4 5 6 7 8 9 10 11 12 13

Answer 5 4 4 5 4 5 4 4 4 4 4 5 Good front-end application, could add more search functions.

Web Developer Two

Question 1 2 3 4 5 6 7 8 9 10 11 12 13

Answer 5 4 4 5 5 4 4 4 5 4 5 5 Layout is nice and clear; maybe have more in-depth description of each function.

Mean Results

Question 1 2 3 4 5 6 7 8 9 10 11 12

Answer 5 4 4 5 4.5 4.5 4 4 4.5 4 4.5 5

Web Service

Web Developer One

Question 1 2 3 4 5 6 7 8 9 10 11

Answer 5 4 4 4 5 3 5 4 4 5 Customer entity could include address, phone number and other details.

Web Developer Two

Question 1 2 3 4 5 6 7 8 9 10 11

Answer 4 4 4 4 5 3 4 4 4 5 Impressive web service, could have find API key function as implemented in the front-end application.

Mean Results

Question 1 2 3 4 5 6 7 8 9 10

Answer 4.5 4 4 4 5 3 4.5 4 4 5

77

Appendix I: Siege Data

GET Requests POST Requests

78

Appendix J: Browser Compatibility

Google Chrome v11.0.696.65 Mozilla Firefox v4.0.1

Internet Explorer v8.0.7600.16385 Opera v11.01

A Recurring Invoicing Web Service Based on a Service ... · been given where reference has been...

Documents

Transcript of A Recurring Invoicing Web Service Based on a Service ... · been given where reference has been...