A Recurring Invoicing Web Service Based on a Service ... · been given where reference has been...
-
Upload
trinhtuyen -
Category
Documents
-
view
214 -
download
0
Transcript of 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.1 Functionality 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.1 Functionality 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:
Learn technical platform
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:
Learn technical platform
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.
Task Estimated Time Required (hours)
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.
Task Estimated Time Required (hours)
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
6.3.1 Functionality 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.
6.3.2 Client Feedback
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
Task Estimated Time Required (hours)
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
7.3.1 Functionality 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.
7.3.2 Client Feedback
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