1. A Report submitted in partial fulfilment of the regulations governing the award of Degree of BSc
(Honours) Computer and Network Technology at the University of Northumbria at Newcastle
Implementation of a middleware integration solution for
CRM software
STUDENT NAME: Ashley Kingscote
STUDENT ID: w12012610
STUDENT COURSE: Computer & Network Technology
PROJECT TYPE: General Computing Project
SUPERVISOR NAME: Neil Eliot
SECOND MARKER NAME: Emma-Jane Phillips
CM0645
Individual Project
General Computing Project
Project Report
15/16
2. ii
Author Declaration
I declare the following:
(1) That the material contained in this dissertation is the end result of my own work and
that due acknowledgement has been given in the bibliography and references to ALL
sources be they printed, electronic or personal.
(2) The Word Count of this Dissertation is 26,529 words.
(3) That unless this dissertation has been confirmed as confidential, I agree to an entire
electronic copy or sections of the dissertation to being placed on the eLearning
Portal (Blackboard), if deemed appropriate, to allow future students the opportunity
to see examples of past dissertations. I understand that if displayed on eLearning
Portal it would be made available for no longer than five years and that students
would be able to print off copies or download.
(4) I agree to my dissertation being submitted to a plagiarism detection service, where it
will be stored in a database and compared against work submitted from this or any
other School or from other institutions using the service. In the event of the service
detecting a high degree of similarity between content within the service this will be
reported back to my supervisor and second marker, who may decide to undertake further
investigation that may ultimately lead to disciplinary actions, should instances of plagiarism
be detected.
(5) I have read the Northumbria University/Engineering and Environment Policy
Statement on Ethics in Research and Consultancy and I confirm that ethical issues
have been considered, evaluated and appropriately addressed in this research.
Ashley Kingscote
3. iii
Acknowledgements
I would like thank my dissertation supervisor Neil Eliot for his guidance throughout my time
at university.
Additionally, I would like to thank my Partner, Friends, Family and ‘Frankies & Tonys’ for
their support throughout the project.
4. iv
Abstract
A detailed investigation into Enterprise Application Integration (EAI) technologies with
supporting practical demonstrations.
A simple mock business scenario has been created where data from a database in
Business A is migrated to Business B’s Customer Relationship Management (CRM)
solution. CRM software is used by companies to manage information about their
customers.
From the understanding gained in the research, three different proof of concept solutions
were developed.
Design Integration Method
Concept 1 Data is exposed via a RESTful web service then consumed by an
application that feeds the data into Business B’s CRM.
Concept 2 Data is passed into a SOAP service where it is encoded in XML format to
match the fields in Business B’s CRM. The data is then pushed into the
CRM by an additional application.
Concept 3 Data is pushed onto a queue to provide reliable delivery to Business B’s
CRM.
All three concepts successfully demonstrate the intended technology and the data is
visible in the CRM frontend without any corruption.
The project provides insight into EAI technologies to allow educated decisions for choosing
an EAI implementation method.
The project concludes that there is not a single ‘perfect’ EAI technology for every
integration scenario. The choice of implementation depends on three factors:
Personal Preference - potentially fuelled by development team skillset
System Architecture
Business Requirements
5. v
List of Acronyms
AJAX Asynchronous Javascript And XML JRE Java Runtime Environment
AMQP Advanced Message Queuing Protocol JSE Java Standard Edition
API Application Programming Interface JSON Javascript Object Notation
AS2 Applicability Statement 2 JSP Java Server Page
CBA Cost Benefit Analysis JVM Java Virtual Machine
CCI Common Client Interface LPC Local Prodecure Call
CLR Common Language Runtime MB Megabtye
CORBA
Common Object Request Broker
Architecture MIME
Multipurpose Internet Main
Extensions
CPU Central Processing Unit MOM Message Orientated Middleware
CRM Customer Relationship Management MQOD Message Queuing Object Descriptor
DCOM Distributed Component Object Model MSQB Microsoft Queuing Binary Protocol
DNT Do Not Track
MS-
RPCE
Microsoft Remote Procedure Call
Extension
DVI Dynamic Invocation Interface MVP Minimum Viable Product
EAI Enterprise Application Integration OFTP Odette File Transfer Protocol
EBI Extended Business Integration OLE Object Linking and Embedding
EDI Electronic Data Interchange ORB Object Request Broker
EI Enterprise Integration POJO Plain Old Java Object
EIP Enterprise Integration Patterns POP3 Post Office Protocol - Version 3
EJB Enterprise Java Beans QoS Quality of Service
ERP Electronic Resource Planning REST Representational State Transfer
ESB Enterprise Service Bus RMI Remote Method Invocation
FCL Framework Class Library RPC Remote Procedure Call
FTP File Transfer Protocol RSS Really Simple Syndication
GUI Graphical User Interface SA System Architecture
HL7 Health Level Seven SCI Supply Chain Integration
HTML Hypertext Markup Language SI System Integration
HTTP Hypertext Transfer Protocol SMTP Simple Mail Transfer Protocol
IDE Integrated Development Environment SOA Service-Oriented Architecture
IDL Interface Description Language SOAP Simple Object Access Protocol
IETF Internet Engineering Task Force SPI Service Provider Interface
IMAP Internet Message Access Protocol SQL Structured Query Language
IRC Internet Relay Chat SSL Secure Sockets Layer
ISO
International Organization for
Standardization STOMP
Streaming Text Orientated Messaging
Protocol
J2EE Java Platform Enterprise Edition SWIFT
Society for Worldwide Interbank
Financial Telecommunication
Java SE Java Platform Standard Edition TLS Transport Layer Security
JBI Java Business Integration TOS Talend Open Studio
JCA Java Connectivity Architecture UDDI
Universal Description, Discovery and
Integration
JDBC Java Database Connectivity UID Unique Identifier
JDK Java Development Kit URI Uniform Resource Indicator
JMS Java Messaging Service URL Uniform Resource Locator
JMX Java Management Extension VCI Value Chain Integration
JNDI Java Naming & Directory Interface W3C World Wide Web Consortium
6. vi
WADL Web Application Description Language
WAIS Wide Area Information Server
WCF Windows Communication Foundation
WPF Windows Presentation Foundation
WSDL Web Service Description Language
WS-I
Web Services Interoperability
Organisation
WSIF Web Services Invocation Framework
WWW World Wide Web
XML eXtensible Markup Language
XML-
RPC
eXtensible Markup Language - Remote
Procedure Call
XMPP
Extensible Messaging and Presence
Protocol
YAML YAML Ain't Markup Language
7. 7
List of Contents
Author Declaration........................................................................................................... ii
Acknowledgements ........................................................................................................ iii
Abstract........................................................................................................................... iv
List of Acronyms ............................................................................................................. v
List of Contents ............................................................................................................... 7
Aims of the Project ........................................................................................................ 10
Objectives ...................................................................................................................... 10
Introduction.................................................................................................................... 11
Background................................................................................................................. 11
Scenario...................................................................................................................... 12
Subject of the Work..................................................................................................... 13
Plan of Study............................................................................................................... 13
Literature Review........................................................................................................... 14
Scope.......................................................................................................................... 14
Integration................................................................................................................... 14
Data Formats .............................................................................................................. 21
Relevant Standards..................................................................................................... 22
HL7.......................................................................................................................................... 22
SWIFT Messaging .................................................................................................................. 22
ODETTE.................................................................................................................................. 22
EDI .......................................................................................................................................... 22
CRM Software............................................................................................................. 22
Approaches................................................................................................................. 24
Remote Procedure Call (RPC)................................................................................................ 24
Java Remote Method Invocation (Java RMI).......................................................................... 26
Common Object Request Broker Architecture (CORBA) ....................................................... 28
Distributed Component Object Model (DCOM) ...................................................................... 29
Web Services.......................................................................................................................... 32
Development Tools ..................................................................................................... 49
Java Platform Enterprise Edition (J2EE) ................................................................................ 49
.NET........................................................................................................................................ 56
VERT.X ................................................................................................................................... 58
Spring Framework................................................................................................................... 58
Enterprise Integration Patterns (EIP)...................................................................................... 59
Integrated Development Environment (IDE)........................................................................... 60
9. 9
Summary of Concepts............................................................................................... 130
Concept 1.............................................................................................................................. 130
Concept 2.............................................................................................................................. 130
Concept 3.............................................................................................................................. 131
Key Metrics Discussion......................................................................................................... 131
Evaluation .................................................................................................................... 133
Evaluation of the Research ....................................................................................... 133
Evaluation of the Products ........................................................................................ 135
Discussion of the Strengths & Weaknesses of Concepts..................................................... 135
Evaluation of Tools Used...................................................................................................... 137
Challenges Faced ................................................................................................................. 137
Evaluation of Project Process.................................................................................... 138
Management and Execution ................................................................................................. 138
Discussion of Aims & Objectives Achieved .......................................................................... 139
Personal Development.......................................................................................................... 141
Conclusion & Recommendations............................................................................... 142
Conclusion ................................................................................................................ 143
Recommendations .................................................................................................... 143
Future Work .............................................................................................................. 144
References ................................................................................................................... 145
Bibliography................................................................................................................. 172
List of Figures.............................................................................................................. 177
List of Tables................................................................................................................ 181
Appendix 1 - Terms of Reference – October 2015..................................................... 183
Appendix 2 – SOAP WS Compliance Result.............................................................. 191
10. 10
Aims of the Project
To investigate integration technologies
To develop a middleware solution to integrate data from a source to destination.
Objectives
a) Define Scope
This section will define the requirements of the project, taking into account the time and
resources available.
b) Research
Investigate integration technologies and standards.
c) Design
Plan design of solution
d) Implementation
Develop solution
e) Test Solution
Test final solution against previously set criteria.
f) Conclusion & Recommendations
11. 11
Introduction
Background
Information Technology’s (I.T) importance to business processes has grown (McDonald &
Rowsell-Jones, 2012). From the automation of key processes, to Electronic Resource
Planning (ERP); I.T’s value has extended to supply chain management and Customer
Relationship Management (CRM). I.T is a fundamental part of the modern business and
can drive efficiency, simplicity and enable cost savings. By streamlining business
processes, companies can increase productivity and facilitate growth (Boyd, et al., 2012).
This often creates a business need for a versatile solution that can efficiently manage
communication and data transfers between I.T Systems (Perry & Flemming, 2012).
The rapid development of technology has led to many systems within organisations
existing in heterogeneous environments. Different systems have been developed at
different times, in different languages, on different hardware and available through various
platforms (Lin, 2005). In an ideal world, imagine that a single company had created every
application then there should not be a need for integration (assuming they were all built to
communicate together). The challenge in integration is being versatile enough to
effectively communicate between systems no matter the supporting technology.
Enterprise Application Integration (EAI) is defined as a systems integration strategy to
achieve data and process integration (Markus, 2000). EAI has become a crucial process
as a direct consequence of the globalization phenomenon generated by the popularity of
the internet. This globalization has two direct impacts for companies from the viewpoint of
their markets; a huge increase in market potential and the need to know each customer in
detail. It is vital to understand customers in order to establish a privileged relationship with
them. This leads companies to implement Customer Relationship Management (CRM)
software (Radcliffe, 2001) (Hohpe & Woolf, 2003).
Integration of systems is a challenging task within organizations. Often, businesses
implement new systems that are not directly compatible with their existing architecture. As
this happens, their business efficiency may decline (Brynjolfsson, 1993). EAI technology
has gained popularity to solve this problem. (Perjons & Johannesson, 2000). EAI
increases the versatility of applications and can increase the system life (Irani, et al.,
2003). EAI has been shown to have a positive impact on a company’s efficiency leading to
an increase in its business value. (Riztocki & Weistroffer, 2006)
12. 12
The cost-benefit analysis (CBA) of integration within businesses can be vast. This is
because of a number of factors including (but not limited to) the number of systems, the
supporting technologies, the size of the companies, the size & expertise of the
development team, the classification of integration & the scope of integration (Fazlollahi, et
al., 2013).
Year 2000 2001 2011 2014 20191
Market Value $40 Million $60 Million $5 Billion $7.8 Billion $13.35 Billion
Table 1 - Market Value of EAI (Serain & Craig, 2002, p. 1), (Markets and Markets, 2014),
(Lheureux, et al., 2011)
Table 1 shows that the market value of EAI in 2014 is nearly 200 times greater than the
market value in the year 2000. This shows tremendous growth in the EAI market over the
past 14 years and research predicts the market growth to continue a steep increase in
value (Markets and Markets, 2014)
Scenario
The report will investigate and implement various integration technologies in mock
scenarios as proof of concept designs.
The chosen scenarios will simulate data integration across two businesses. The scenario
is that Business A has data that needs to feed into Business B’s CRM Solution.
Figure 1 - Scenario
1 Estimated Value
13. 13
Multiple integration technologies will be critically analysed and a range of integration
methods will be demonstrated in mock business scenarios.
These are proof of concept integrations that flow one way; from Business A into Business
B’s CRM product. The focal point is not on the business scenario, security or the
integration quality, it is on the technologies supporting the methods.
Subject of the Work
The project investigates technologies used in EAI and three core technologies will be used
in development of proof of concept integrations. The focus of the project is an introduction
into the technologies and demonstrate their usage within an EAI scenario. Security and
performance will be mentioned but a detailed analysis and development is out of scope.
Plan of Study
Figure 2 - Plan of Study
14. 14
Literature Review
Scope
The aim of this literature review is to critically analyse methods and technologies of
integration from a data source to a CRM destination. Three integration technologies will be
chosen for proof of concept implementations in a mock business integration scenario.
Security will be mentioned but a detailed analysis is out of scope for this review. Any
predictions or analysis of the future for integrations is also out of scope.
The review will discuss definitions of integration to remove any ambiguity and ensure
clarity. System architectures will be discussed as they have an impact on choosing an
integration technology.
The emphasis of the project is on the technologies involved in integration - not the system
architecture or database configurations.
Integration
Definitions
Integration in I.T is often presented in a variety of terms such as Enterprise Integration
(EI), Systems Integration (SI), Enterprise Application Integration (EAI), Value Chain
Integration (VCI), Supply Chain Integration (SCI) and Extended Business Integration (EBI)
(Themistocleous & Irani, 2002, pp. 154-165). These terms are commonly used incorrectly
so it is important to define them to ensure clarity throughout the report.
EI can be defined as connecting systems and applications to support business processes
and operations. From a business point of view, Enterprise Integration facilitates the flow of
information across an organization by connecting all of its departments to improve
communication, collaboration and coordination (Chen, et al., 2008).
From an organizations perspective, this definition brilliantly sums up the goal of
integrations and it is easy to imagine the business benefits. However, the definition lacks
much of a technical description as there is no indication of the information technology
behind EI.
A slightly more comprehensive definition can be found by (Lee, et al., 2003, pp. 54-60)
which describes EI is a “business computing term for plans, methods and tools aimed at
modernizing, consolidating and coordinating the overall computer functionality in an
enterprise”. This is a great definition as it mentions the organizational and technical areas
15. 15
that are encompassed within EI. Throughout the report, this definition will be used as the
term for EI.
L.M Markus defines System Integration as the creation of “tighter linkages” between
different information systems and databases (Markus, 2000). This is a vague definition that
leaves the interpretation open to the reader. Tighter linkages is not an easily measureable
factor for the value of system integration.
Gartner Research defines SI as the process of creating a complex information system that
may including building an architecture or application that can integrate with new or old
hardware, software and communications (Gartner, n.d.). This definition implies that all SI
must be complicated which may not always be true. However, the definition also highlights
that SI must be versatile and communicate with old and new systems. This is one of the
main factors of integration as otherwise, new applications would have to be constantly
developed in order for communication. Integration allows for communication with old/new
systems using a variety of technologies to eliminate the cost of updating/building new
applications.
Enterprise Application Integration (EAI) is defined as a systems integration strategy to
achieve data and process integration (Markus, 2000). EAI requires involvement of the
entire enterprise, business processes, applications, data, standards and platforms. (Lin,
2005). EAI can be seen as a combination of EI and SI. EAI encompasses the business
need for communication between applications in a reliable fashion irrespective of the
platform or geographical location of the applications. (Goel, n.d.). EAI specifically
addresses integration problems from a technical perspective leading to more versatile and
manageable information systems. (Irani, et al., 2003)
Other definitions of EAI exist such as Grimson et al’s (Grimson, et al., 2000) definition
which states that EAI is limited to the integration of ERP systems. This is not true as EAI
can encompass integration between a variety of applications (like CRM tools). Zahavi
suggests that EAI supports enterprise and cross-enterprise application integration.
16. 16
Other integration terms are much more specific to business processes but may still involve
system integration.
Acronym Name Definition
VCI Value Chain Integration Integration of processes performed for
converting raw materials into finished
products.
SCI Supply Chain Integration Integration of internal/external suppliers
inputs/outputs to create a unified process
EBI Extended Business Integration A concept that a company does not
operate in isolation. It is dependent upon
a network of partner relationships.
Table 2 - Process Specific Integration Definitions (Yang & Papazoglou, 2000) (Markus, 2000),
(Linthicum, 1999)
Throughout the report, any further mention of integration will be in reference to EAI. Taking
the above into consideration, the definition used will be the following which is a
development of Markus & Lin’s opinion - “EAI is a systems integration strategy to achieve
reliable data and process communication irrespective of platform or location”.
System Architecture
Within EAI, the integration methods can be dictated by the System Architecture (SA) within
an organisation. It is important to have a basic understanding of system architecture styles
to help identify the best integration technology for a given scenario.
SA is a broad description of the elements in a system and the relationship between them.
SA follows principles known as ‘Architecture Styles’ or ‘Patterns’ to define a model of the
network and to shape an application.
Dr Garlan, the Professor of Computer Science at Carnegie Mellon describes architecture
styles as the vocabulary of components and connectors and their constraints (Garlan &
Shaw, 1994). Modern texts still use Dr Garlan’s definition in defining SA Styles which
shows that the core concepts are still valid (Bass, et al., 2013).
17. 17
Architecture Style Description
Client/Server Segregates the system into two applications, where the client makes
requests to the server. In many cases, the server is a database with
application logic represented as stored procedures.
Component-Based
Architecture
Decomposes application design into reusable functional or logical
components that expose well-defined communication interfaces.
Domain Driven Design An object-oriented architectural style focused on modelling a business
domain and defining business objects based on entities within the
business domain.
Layered Architecture Partitions the concerns of the application into stacked groups.
Message Bus An architecture style that prescribes use of a software system that can
receive and send messages using one or more communication
channels, so that applications can interact without needing to know
specific details about each other.
N-Tier / 3-Tier Segregates functionality into separate segments in much the same
way as the layered style, but with each segment being a tier located on
a physically separate computer.
Object-Oriented A design pattern based on division of responsibilities for an application
or system into individual reusable and self-sufficient objects containing
the relevant data and the behaviours..
Service-Oriented
Architecture (SOA)
Refers to applications that expose and consume functionality as a
service using contracts and messages.
Table 3 - Summary of Key Architectural Styles (Microsoft Corporation, 2009)
System Architectures are often unique to an organisation although they are all derived
from the key styles. SA’s often range in complexity and may be difficult to develop due to
legacy system constraints, private or public regulations, governing standards and protocols
or by the accretion of smaller architectures. All causes of complexity in SA’s can be
simplified in two key aspects; the integration and heterogeneity of the components
(Microsoft Corporation, 2009).
The potential that elements within an SA could potentially have to communicate with a
huge number of ever changing components creates challenges for architecture stability
(Massachusetts Institute of Technology, 2004).
18. 18
Distributed Computing
A distributed system is where components in a network communicate by messaging
(Coulouris, et al., 2012). Messaging is a technology that enables fast & reliable
communication between applications (Hohpe & Woolf, 2003).
Figure 3 - Messaging Between Computers (Hohpe & Woolf, 2003)
SOA
Service-Oriented Architecture (SOA) is a vague term used to describe a software
architecture based that supports service-orientation. Service-Orientation is the production
and consumption of services, typically web services. (OASIS-OPEN, 2005) (The Open
Group, 2013).
Figure 4 – SOA (Broker is optional) (W3C, 2003)
19. 19
ESB
Enterprise Service Bus (ESB) is another ambiguous term. ESB does not have an official
standard and does not have an established definition. However, the general accepted
definition is:
"An architecture pattern that enables interoperability between heterogeneous environments,
using service orientation" (Oracle, 2013).
It is important to note that ESB is not a product, but an architecture style.
Figure 5 - With and Without an ESB Architecture
Figure 5 shows that without an ESB architecture, applications would possibly have to have
multiple separate custom build API’s to talk to other applications. This would create a
complex and inefficient integration scenario. The architecture is significantly simplified by
using an ESB as a central broker.
ESB can offer the following core features:
Table 4 - Core Features of an ESB (Shaheen, 2010)
Feature Use
Invocation Synchronous or asynchronous, service invocation
Routing Addressing, content centric, logic and policy based routing
Mediation Adapters and mapping of web services
Transformation Apply business logic, enrichment, conversion
Messaging Apply transformation qualities to messages
Service Orchestration Coordinate Services
Quality of Service (Qos) Security, Asynchronous delivery, reliability
Management Monitoring and Logging
20. 20
Advantages Drawbacks
Single place for metrics – availability, traffic
management, logging & performance
Inefficient for less than 3 applications
Scalable Could potentially bottleneck for development
SOA Friendly Risk of Regression
Manageable Single point of failure
Table 5 - Advantages and Drawbacks of ESB (Mason, 2009)
Figure 6 - Services interact with the ESB and the ESB translate the message to the correct
message format and sends it onto the appropriate producer service (Angeli, 2008) Image
from Wikipedia
21. 21
Figure 7 - Example ESB (Oracle, 2013)
Figure 7 shows an example of an ESB implementation. In the example, Enterprise
Integration Patterns (EIP’s) are used within the example to provide routing, marshalling
and to call services. ESB’s can be seen as a figurative bus that sits between applications,
dynamically handling requests via routing and invoking services. ESB’s remove the need
for every application to have a separate interface to communicate with every other
application.
Data Formats
Data can be presented in a variety of formats. These are often dictated by what format
best suits the business need in an application. Integration needs to make systems
understand each other and interpret the data. This is achieved through language neutral
platforms and data mapping into a readable format by the target system. It is important to
understand that the data format is just an encoding and format of the data, the underlying
structure is always a mix of characters, strings, integers and boolean values or even binary
if viewed at the highest level.
There are many possible data types, each serving a unique purpose. Some common data
types within integration are:
Format Definition Possible Use
Flat File A file with no specific format or data structure Example would be a Microsoft
Word document containing text
and images about a product.
CSV Comma-Separated Values – stores tabular
data in plain text. A comma is used as the
delimiter.
A static extract of data from a table
within a database
XML eXtensible Markup Language – human and
machine readable format for textual data.
Language-independent
Documents and Data Structures
(like in web services)
22. 22
Table 6 - Common Data Formats in EAI (IETF, 2005) (W3C, 2008) (IETF, 2014) (W3C, 2014)
Relevant Standards
Some industries have standards that should be adhered to when creating integration
solutions.
HL7
Health Level 7 (HL7) is a set of international standards produced by HL7 International for
the transfer of data between applications in the healthcare industry. HL7 standards are for
interoperability between systems within healthcare with the aim to improve care delivery,
optimize efficiency, reduce ambiguity and enhance knowledge transfer. HL7 does not
specify and particular security encryption method (HL7, 1996).
SWIFT Messaging
Society for Worldwide Interbank Financial Telecommunication (SWIFT) provides a network
for financial institutions to transfer financial transactions known as a financial message.
“SWIFT enables secure, seamless and automated financial communication between users”
(SWIFT, 2016).
ODETTE
Odette is a service platform for the automotive industry. It has standards to develop best
practice and services for supply chain logistics, business communications and data
exchange (ODETTE, 2016).
EDI
Electronic Data Interchange (EDI) is a standard for exchanging electronic data (usually
between two separate parties). Data to be transferred is translated into an EDI message.
EDI can speed up transactions and has few errors because less data has to be processed
(OpenText, 2016).
CRM Software
Customer Relationship Management (CRM) is a strategy for managing a business’s
relationship and interactions with their customers. CRM solutions allow multiple staff to
collaborate with customers, build up a history, have audit trails, accountability and improve
JSON JavaScript Object Notation – lightweight,
language-independent data format.
AJAX, Data Structures (like in
webs services)
HTML Hypertext Markup Language – Markup
language used to create web documents.
Creating web documents
23. 23
efficiency to ultimately improve the customer experience (Robles, 2015). CRM’s are a
focal point for businesses and are often involved with integration with legacy systems.
Salesforce is the industry leader for CRM solutions and has a wealth of documentation for
integration. However the Salesforce CRM is expensive and hosted on their own servers.
Vendor Market Share 2014 (%) Market Share 2015 (%)
Salesforce 23% 24%
SAP 12% 10%
Oracle 12% 11%
Microsoft Dynamics CRM 8% 8%
Table 7 - CRM Market Leaders (CRMSEARCH, 2015)
There are many open-source CRM solutions available however they are not as popular as
the paid solutions. An open-source CRM would be preferable for the scenario as they can
be hosted on a privately owned database/server to provide full control and manageability.
Vendor Free Users Free Storage Free Support Free Contacts
SuiteCRM Unlimited Unlimited Online Unlimited
CapsuleCRM 2 200MB Email 2500
Salesbox 2 Unlimited Full Support Unlimited
Capsule 2 10MB None 250
Table 8 - Popular Open-Source CRM Solutions (Capterra, 2015)
24. 24
Approaches
Middleware is a vague term to describe software that mediates communication between
applications. A great analogy is that Middleware is plumbing. As an end user you don’t see
it, it has standard components to make the build simpler and it ties together complex
systems (DiMaggio, 2008).
The following will critically analyse integration technologies to help identify chosen
methods for the mock scenarios.
Remote Procedure Call (RPC)
The fundamentals of RPC can be traced back to the documentation of early
implementations of the internet (ARPANET) (IETF, 1976). The term Remote Procedure
Call (RPC) was not coined until 1984 by Greg Nelson and Andrew Birrell (Nelson & Birrell,
1984). RPC is regarded as the oldest type of middleware (Linthicum, 1999)
RPC is a request-response protocol that allows functions to be run remotely from another
computer. RPC provides developers with a familiar mechanism for building distributed
systems. RPC needs to be discussed as modern integration techniques utilises technology
derived from RPC (Glavis, 2010).
The central component of the client/server model is the interface. An interface is a set of
remotely callable operations offered by a server and that are called by clients. RPC has a
range of facilities for defining, implementing and binding to interfaces. (The Open Group,
1997, p. 12)
“RPC gives developers a mechanism for defining interfaces that can be called over a
network. These could be as simple as a single function call or as complicated as a large API”
(St.Laurent, et al., 2001, p. 3).
A simplified RPC Process is as follows:
1. An RPC is initiated by a client. A request is sent to a known remote server
to execute a procedure with supplied parameters.
2. Whilst the server is processing, the client is blocked from sending any more
requests.
3. The Server sends a reply and the client can continue.
25. 25
Figure 8 - Simplified RPC Process
RPC is a development of Local Procedure Call (LPC) and adds the potential of calling the
procedure in a different process in a different computer in a remote network.
Although RPC’s offers the benefit of being used remotely, it adds the potential issue of
failing because of unexpected network problems. Callers must also handle errors without
knowing whether or not the procedure was actually started.
There must be libraries on both parties involved within the communication and RPC must
handle delays or loss in communicating across a network. (St.Laurent, et al., 2001). As
well as this, RPC increases the possibility of processer crashes because of how much
processing is needed. RPC’s are much more time consuming and have a considerably
larger overhead when compared to LPC, this is due to the additional information needed in
network communication (Sinha, 2007).
Advantages Drawbacks
Simple Call Syntax Context switching increases scheduling costs
Well defined Interface Weak default security measures
Efficient – simple concept that is built for
purpose.
Does not solve distribution creation problems
Can be used Locally or Remotely Interaction based only – not flexible in terms of
hardware architecture
Table 9 - Advantages and Drawbacks of RPC (Saeed, 2014) (Nelson & Birrell, 1984)
26. 26
In 2001, RPC was not considered a flexible technology because of the “simplicity” of its
architecture (St.Laurent, et al., 2001). Abstraction within RPC is low which results in
potential complexity as requests increase.
RPC does not care how a message is passed from one process to another. The
Client/Server must agree on the transport protocol (Srinivasan, 1995, p. 3). RPC’s can be
run on a number of transport protocols including TCP/IP, UDP, NetBEUI and NetBIOS
(Rubin & Brain, 1999).
Since RFC 1831 in 1995, there have been a few improvements to the RPC standard as
defined in RFC 5531 (2009). The core technology and principles of RPC have not
changed, but the technology has been developed and incorporated into other protocols
such as eXtensible Markup Language – Remote Procedure Call (XML-RPC) and Simple
Object Access Protocol (SOAP).
Java Remote Method Invocation (Java RMI)
RMI is the Java ‘extension’ of RPC that allows objects to be passed in the request. It is an
object-orientated development of RPC (Oracle, 2010). However Richard Freedman
regards RMI as more of an implementation of RPC (Freedman, 2012).RMI allows
communication between two Java Virtual Machines (JVM) (Oracle, 2010).
A great benefit of using RMI or an RMI framework is that it will automatically generate the
code to perform marshaling and unmarshalling of data and application configuration
(Grosso, 2001).
An RMI complier is an implementation of the server stubs and skeletons. In an RMI
context, a stub is an object that is responsible for marshaling/unmarshalling of data on the
client side. A skeleton is an object responsible for maintaining connection and performing
the marshaling/unmarshalling of data on the server side.
27. 27
Figure 9 - A basic RMI call with a stub and skeleton (Grosso, 2001)
RMI makes the network a homogenous collection of Java Virtual Machines (JVM) because
it assumes that the client and server are both Java classes (Waldo, 1998).
Jim Waldo argues that RMI’s Java-centric design is a benefit as it utilises Java
environments dynamic nature by letting code load any time during execution. However
David Reilly claims that there is a lack of support for legacy systems written in other
languages which makes RMI a hindrance as additional programming will be needed to
create bridges between systems. If a company choses JMI as a base technology, they are
restricting themselves to the use of Java. This could cause additional complexity in the
future if Java becomes a legacy language (Reilly, 2006).
Advantages Drawbacks
Object Orientated – can pass full object as
arguments and return values (RPC cannot).
Security vulnerabilities with remote code calling
Mobile Behavior & Portable – can move class
implementations. Also portable across many
platforms
An invocation of a remote method is subject to
potential failure from security, latency problems
& network failure
Design Patterns – passing object and
behaviors means object orientated design
patterns can be used.
Can only operate with Java systems
Table 10 - Advantages and Drawbacks of RMI (Oracle, 2010) (Reilly, 2006) (Waldo, 1998)
28. 28
Common Object Request Broker Architecture (CORBA)
CORBA is a distributed object-orientated client/server platform that facilitates the
communications of systems that are deployed on different Operating Systems (OS),
programming languages and hardware.
The CORBA standard was originally defined in 1991 by the Object Management Group
(OMG) standards consortium (Object Management Group (OMG), 1991).
CORBA achieves portability and interoperability by providing an RPC mechanism that
allows the invocation of operations across different languages, OS and hardware. CORBA
uses CORBA Component Model (CCM) to allow reusable components.
A simplified CORBA Process is as follows:
A client makes a request via a choice of three interfaces to the Object Request Broker
(ORB); a Dynamic Invocation Interface (DVI) or an Interface Description Language Stub
(IDL) or through the ‘ORB Interface’. If the DVI or IDL were chosen, the receiver of the
message cannot tell how the request was invoked. For DVI and IDL, Object Adapters
called skeletons are used by the ORB to implement code, transmit parameters and
transfer code to the Object Implementation. The ORB is the middleware that establishes
the client/server relationship between object/components (Ginsburg, et al., n.d.).
The ORB interface is the interface that goes direct to the ORB. The ORB interface is used
when the ORB functions do not depend on which object adapter is used.
Figure 10 - A request being sent through the Object Request Broker (Object Management
Group (OMG), 2012)
29. 29
Advantages Drawbacks
Feature Rich – supports many languages,
hardware and operating systems and has a
range of capabilities such as trading,
transactions and trading services
Firewall Unfriendly –if HTTP isn’t used,
Firewalls will often block communications.
CORBA is difficult to dictate port usage.
Open Standard – many vendors to choose
from
IDL is complicated
Scalability – can virtually handle unlimited
objects
Doesn’t support the transfer of objects or code
(only primitive data types, parameters or data
structures)
Efficiency – Application Wire Protocol
compacts messages
Development is complicated and time and
labor intensive.
No CORBA standard for binding. Only vendor
specifications.
Table 11 - Advantages and Drawbacks of CORBA (Object Management Group (OMG), 2012)
(Reilly, 2006)
Popular CORBA Products
ORB Description
Obracus A popular Java and C++ ORB from Iona Technologies
WebSphere A popular application server with ORB from IBM
Netscape
Communicator
Netscape browsers have a version of VisiBroker embedded in
them
Sun Java 2 Platform Provides an ORB and two CORBA programming models
Table 12 - Common CORBA Products (Traore, n.d.)
Distributed Component Object Model (DCOM)
The Distributed Component Object Model is a protocol created by Microsoft in 1996 that
exposes application objects by RPC (Microsoft, 2015). DCOM is an extension of Microsoft
Remote Procedure Call Extension (MS-RPCE) (a development of RPC) and Component
Object Model (COM) which is used to create re-usable software components to build
applications and take advantage of services (Microsoft, 2015) (Mircosoft, 1993).
COM is a development of Object Linking and Embedding (OLE). OLE was created in 1990
by Microsoft to allow for data within one application to be exported into another, for
example, importing a picture into a document. The official definition by Microsoft is “OLE
enable applications to create documents that contain linked or embedded objects”
(Microsoft, 2012)
30. 30
COM is used to find objects on a computer or network. DCOM is a development of COM
allowing the technology to be used over different networks. As COM was local, it is
restricted that the consumer and provider of the interface had to be on the same machine
(Microsoft, n.d.).
DCOM extends COM over a network by providing facilities for creating object, managing
object references, object lifetimes and object interface queries (Microsoft, 2015). DCOM
uses RPC whereas COM uses LPC which makes DCOM distributed.
Microsoft’s official definition of DCOM is: "An object protocol that enables ActiveX
components to communicate directly with each other across a network. DCOM is language-
neutral, so any language that produces ActiveX components can also produce Distributed
Common Object Model applications".
DCOM services can include security, load balancing, guaranteed delivery, triggers, multi-
threading, shared memory, distributed transactions, message queueing, bridging and
routing. DCOM can support both synchronous and asynchronous delivery (Rock-Evans,
1998).
DCOM is regarded as an alternative to CORBA for providing a set of distributed services.
In 1998, DCOM was considered extremely powerful as it was one of the first middleware
products to have integrated services within products with one interface (Rock-Evans,
1998). Additionally, DCOM works natively with TCP/IP, Java and HTTP which makes it
commonly supported.
Figure 11 - DCOM Protocol Stack
31. 31
A simplified DCOM process is as follows:
1. COM object is created and all calls will be marshaled through the proxy and stub
objects
2. Proxy and stub communicate using RPC which handles the network interaction
3. On the server side, the stub unmarshalls the data
(Thai, 1999) (Rubin & Brain, 1999)
Advantages Drawbacks
ActiveX Based – programming language
neutral
Platform-Specific – reduces interoperability
Works with Internet Technologies – by
default works with HTTP, TCP/IP
No load balancing, No automatic multi-
threading, No automatic fault handling, No
automatic memory management.
Versatile Available Services Complicated to develop
Table 13 - Advantages and Drawbacks of DCOM (Davis & Zhang, 2002)
32. 32
Web Services
Defining a Web Service
Before analysis of Web Services as an integration technology, it is important to have clarity
on what a web service is. The term web service is used in different contexts with different
meanings. Existing definitions are often very generic or very precise; this can make the
topic difficult to understand.
Web Services provide abstraction between clients and server. They are a form of middle-
ware based on XML and Web technologies. Web Services can be developed using any
language and deployed on any platform making them independent. They typically use
language neutral protocols like HTTP and communicate between applications by using
XML or JSON via an Application Program Interface (API). Web Services are a commonly
implemented because they work across the internet and are cheap to develop and are
easy to use (Kumaraswamipillai, 2014).
“Often, a Web service is seen as an application accessible to other applications over the
Web” (Alonso, et al., 2004, p. 124). This is a very open definition that ties nearly everything
with a URL as a Web Service. Simon St.Laurent in Programming Web Services with XML-
RPC describes web services as “a set of tools that let you build distributed applications on
top of existing web infrastructures” (St.Laurent, et al., 2001). This is a strong definition that
encompasses the role of web services in relation to the goal of the project. However, it
does little to describe & define anything about the technology used.
The Universal Description, Discovery and Integration (UDDI) Consortium describes web
services as “self-contained, modular business applications that have open, Internet-
oriented, standards-based interfaces” (UDDI, 2001). This definition emphasises the need
for being compliant with the standards and having an open service meaning that the
interface can be invoked across the internet. This is still a vague definition of a web service
and restricts web services to being “modular, self-contained business applications”.
The World Wide Web consortium (W3C) Web Services Architecture Working Group
defines web services in more detail:
“A Web service is a software system identified by a URI [RFC 2396], whose public interfaces
and bindings are defined and described using XML. Its definition can be discovered by other
software systems. These systems may then interact with the Web service in a manner “
(W3C, 2004).
This definition states that XML must define & describe the public interface and bindings
and that a Web Service must be discovered by other systems in order to interact. This is a
33. 33
much more comprehensive definition and is generally accepted as the definition of web
services. Despite its detail, there are even more specific definitions available such as
Webopedias description:
“a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and
UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP
is used to transfer the data, WSDL is used for describing the services available and UDDI is
used for listing what services are available” (webopedia, n.d.).
This definition goes much further and describes the specific standards that could be used
for binding and interacting with a web service. The issue with this definition is that it is
implied that SOAP, WSDL and UDDI standards cover web services in its entirety.
With consideration of the above observations, it is most beneficial to use the W3C
definition of web services as it covers the essence of a web service without limiting it to
specific technologies (other than XML).
Web Services are used in systems to provide access to applications. Web Services assist
in the integration of isolated autonomous and heterogeneous sources and services. Web
Services allow participants to not worry about the platform, language or component model
used to create or access the services (Bouguettaya, et al., 2008).
An important takeaway is that web services are just one method of implementing a SOA.
Web Services offer standards based, platform-independent services via a range of
protocols and standards to achieve interoperability between applications.
Web Service Styles
XML-RPC
eXtensible Markup Language – Remote Procedure Call (XML-RPC) is a data structure
format for representing function calls and their return values (Richardson & Ruby, 2007). It
is a RPC protocol that works over the internet (Winer, 1999). XML-RPC is an extension of
RPC using XML to encode data and HTTP for communication. XML-RPC was created in
1998 by Dave Winer (Box, 2001).
XML-RPC applications are typically built for connecting different kinds of environments, for
example, Java to Perl or Python to ASP (St.Laurent, et al., 2001).
34. 34
Figure 12 - XML-RPC Process
A simplified XML-RPC process is as follows:
1. The Client specifies the method name to be called on the remote server, any
parameters to be passed and the target URL of the destination server.
2. The Client then puts the method name and parameters in XML.
3. The request is then sent to the Server via the URL though a HTTP POST request.
4. On the Servers end, a listener processes the XML and extracts the method name
and the parameters.
5. The method is then run and the result is wrapped in XML ready to be sent back to
the Client.
6. The response is sent to the Client through the same HTTP connection.
7. The Client then extracts the return value from the XML and passes the value into
the program.
35. 35
An XML-RPC request is always followed by a synchronous response. Once a XML-RPC
request has been sent, the client is blocked from sending any more requests. This is
because it is expecting a response from the server on the same HTTP connection
(St.Laurent, et al., 2001). XML-RPC is a stateless technology meaning that no information
is kept from requests. Each request is unique and does not have any knowledge of any
other previous request.
Advantages Drawbacks
Reusable Components to help simplify
development
High bandwidth consumption
Simple Architecture Poor performance compared to other distributed
approaches such as RMI and CORBA
Client Independent Method call only supports alphanumeric,
underscore, dot, colon or slash making it difficult to
pass and object as an argument.
Fast to Deploy Cannot name structures or arrays which can make
development confusing
Table 14 - Advantages and Drawbacks of XML-RPC (Rhodes, 2006) (Winer, 1999) (St.Laurent,
et al., 2001)
SOAP
The Simple Object Access Protocol (SOAP) is a protocol specification defining a XML-
based envelope for data being transferred, rules for translating data types into XML and
rules for representing RPC and responses (W3C, 2000). SOAP was designed in 1998 by
Dave Winer (creator of XML-RPC), Bob Atkinson, Mohsen Al-Ghosein for Microsoft.
From 2001-2007, SOAP was an extremely popular protocol for SOA. However, in recent
years its popularity has declined (Google, 2016).
SOAP improves upon XML-RPC by adding security and by supporting WSDL which
makes discovery and integration with remote web services much simpler.
SOAP can work with either SMTP (Simple Mail Transfer Protocol) or HTTP (Hypertext
Transfer Protocol) application layer protocols. HTTP has become the preferred choice
because it works well with firewalls and because of its abundant use in the internet
infrastructure. SOAP can also be used with HTTPS to add data encryption to provide
security (IETF, 1999).
SOAP is document-based where a client puts a ‘document’ in an ‘envelope’ and sends it to
a server. The Server response by putting a ‘response document’ in an ‘envelope’ and
36. 36
sending it back to the client. SOAP strictly dictates what format an envelope should be in
but doesn’t care about what goes inside (the document).
SOAP Encoding Rules
SOAP has two categories of data types: Scalar and Compound. Scalar types contain
exactly one value. Compound types contain multiple values. Compound types can contain
arrays and structures. The SOAP specification dictates encoding rules for converting data
values into an XML format when embedded into a SOAP envelope.
A detailed analysis of the encoding rules are out of scope for this review.
SOAP defines encoding rules in a default schema so that the recipient knows how to
process the message. The rules are not required, but a schema reference must be
included. There is a recommended schema in the specification, but it is not default for
SOAP messages (W3C, 2000). The encoding style of a SOAP message is specified using
the encodingStyle attribute.
Figure 13 - Java to SOAP Example
SOAP RPC Representation
SOAP RPC functionality works in the same way as with XML-RPC (Figure 12). The
difference is that for SOAP, the invocation of a RPC is achieved through a SOAP
message. The principles are exactly the same; a URL, method name and parameters are
required.
37. 37
SOAP Message
A SOAP message is an XML document made from a SOAP envelope, an (optional) SOAP
header and a SOAP body. The protocol dictates that the envelope must be top element of
the XML message. The optional header can be used to add additional features to a SOAP
message such as authentication or transaction management. The SOAP body contains
the data that is intended for the recipient.
Figure 14 – Example SOAP Request (Indiana University, 2000)
Figure 14 shows a SOAP request message. The message is sent via HTTP using the
POST method. The key HTTP information is the host address and the SOAP action. The
SOAP action is the procedure to be called on the server.
The SOAP message contains its data in a SOAP envelope. The default schema and
encoding is used in this example. The name space in the envelope will always be
http://schemas.xmlsoap.org/soap/envelope/ as this is what defines the
envelope as a SOAP envelope (W3 Schools, 2016). The actual message is wrapped in the
SOAP body XML tags. It contains the procedure and the XML name space (XMLNS) for
the message data. The XMLNS is used to provide the unique elements and attributes
within an XML document.
POST /Temperature HTTP/1.1
Host: www.temperature-service.com
Content-Type: text/xml
Content-Length: 357
SOAPAction: "http://weather.org/query#GetTemperature"
< SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
< SOAP-ENV:Body>
< m:GetTemperature xmlns:m="http://weather.org/query">
< longitude>39W< /longitude>
< latitude>62S< /latitude>
< /m:GetTemperature>
< /SOAP-ENV:Body>
< /SOAP-ENV:Envelope>
38. 38
Figure 15 - Example SOAP Response (Indiana University, 2000)
Figure 15 shows an example SOAP response to Figure 14’s SOAP request. The HTTP
information shows displays the HTTP return code 200 meaning that the request was
successful (W3C, 1999). The SOAP information is similar to the request except the result
is now returned in the body in instead of the parameters.
Advantages Drawbacks
Works through firewalls Slower speeds than RMI, CORBA and DCOM
Allows named structures and arrays Encoding mentioned in specification isn’t default
Platform Independent WSDL Dependent – more components
Simple to develop compared to RMI,
CORBA and DCOM
High network load
Table 15 - Advantages and Drawbacks of SOAP (Rhodes, 2006) (XYZWS, 2006)
WSDL
Web Services Description Languages (WSDL) is an XML-based format used for describing
network services as endpoints of messaging (W3C, 2001). A WSDL document defines
services as collections of network endpoints or ports. WSDL was created in 2000, by
Microsoft, IBM and Ariba to describe how a service is bound to a messaging protocol,
namely SOAP. In 2007, WSDL 2.0 became a W3C recommendation. It improves upon
previous versions by adding further semantics to the description language, removing
message constructions and by not supporting operator overloading. It also renames
‘PortTypes’ to ‘Interfaces’ and ‘Ports’ to ‘Endpoints’.
WSDL 2.0 does not define a message as it is defined inside the operation element (W3C,
2004). WSDL 2.0 was developed to improve interoperability but few vendors support
WSDL 2.0 (thesoatestinggeek, 2012).
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 343
< SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
< SOAP-ENV:Body>
< m:GetTemperatureResponse xmlns:m="http://weather.org/query">
< centigrade>28.4< /centigrade>
< /m:GetTemperatureResponse>
< /SOAP-ENV:Body>
< /SOAP-ENV:Envelope>
39. 39
The following elements are used within a WSDL document to define a network service:
Table 16 - WSDL Element Definitions - Source W3C WSDL Standard 2001
Officially there are 4 styles of WSDL used to translate a WSDL binding into a SOAP
message: RPC/Encoded, RPC/Literal, Document/Encoded, Document/Literal. Although
the main differences are between RPC style and Document style, the rest are just
encoding models for how to translate a WSDL binding the SOAP message. IBM maintains
that the document/encoded style is rarely used as it is not WS-I compliant (Butek, 2005).
RPC Style
The SOAP request body must contain the operation name and the operation parameters.
Document Style
Allows the SOAP body to be structured any way the developer wants. This style is referred
to as Message-Orientated Style.
Advantages Drawbacks
RPC/Encoded Simple WSDL, Operation name is in
the message which makes it easier for
the receiver to send the message
when the operation is called.
Unnecessary overhead, difficult
to validate the XML, not WS-I
compliant
RPC/Literal All of above + it is WS-I Compliant Difficult to validate the XML
Document/Encoded N/A – Not Used N/A – Not Used
Document/Literal No type encoding, can easily validate
the XML, WS-I compliant
Complicated WSDL, No
operation name in the message,
can break compliancy by
allowing two child elements
within the SOAP body. WS-I
specifies only one is allowed.
Table 17- WSDL Styles Advantages and Drawbacks (Butek, 2005) (W3C, 2001)
Oracle recommends to use the Document Style with Literal encoding as it is Web Services
Interoperability (WS-I) compliant (Suresh Raj, 2006) (Butek, 2005).
WSDL 1.1 WSDL 2.0 Definition
Type Type A container for data type definitions using some
Message N/A An abstract, typed definition of the data being communicated.
Operation Operation An abstract description of an action supported by the service.
Port Type Interface An abstract set of operations supported by one or more
endpoints.
Binding Binding A concrete protocol and data format specification for a particular
port type.
Port Endpoint A single endpoint defined as a combination of a binding and a
network address.
Service Service A collection of related endpoints.
40. 40
WS-*
WS-* is a prefix that refers to specifications associated with Web Services. There are 40+
web services specifications (Microsoft, 2016). The most notable being:
Table 18 - Common Web Service Stack Specifications (Goodner, et al., 2007) (IBM, 2006)
WS-I
The Web Services Interoperability Organisation (WS-I) is a consortium to promote
interoperability amongst web services stack specifications. It does not define standards,
but rather guidelines and tests to promote interoperability (WS-I, 2009).
UDDI
Universal Description Discovery and Integration (UDDI) is a platform neutral XML registry
for businesses to list themselves on the internet. Its purpose is to streamline transactions
between businesses by easily being able to find each other on the internet. UDDI can be
compared to the yellow pages.
Registering a service involves four data types:
Table 19 - UDDI Data Structures (Eclipse, 2007)
Specification Use
WS-Addressing Allows web services to communicate via addressing information over a
natural transport protocol.
WS-Discovery Specification defining a multicast discovery protocol for locating services on
a local network
WS-Policy Allows web services to use XML to advertise their policies like Quality of
Service (QoS) or Security
SOAP Exchanging of structured information in web services
WS-Security Applying security to SOAP
WS-Trust Extension of WS-Security. Specifies issuing, renewing and validation of
security tokens.
WS-Federation Extends WS-Security & WS-Trust by enabling authorized access to
resources
Data Structure Use
businessEntity Information about the business that has a published service
businessService Description of a web service
bindingTemplate Technical information for finding the entry point for invoking a web service
tModel Reference to assist in the discovery of web services
41. 41
UDDI provides access to WSDL documents by describing the binding information in its
registry. These can be accessed by SOAP messages to allow the service to be discovered
(IBM, 2001).
To publish a service in the UDDI registry, the binding information of the WSDL must be
mapped to the UDDI format.
Figure 16 - WSDL to UDDI Mapping (OASIS-OPEN, 2004)
The UDDI Business Registry shutdown after IBM, Microsoft and SAP shutdown their public
registries (OASIS-OPEN, 2005). The official declaration states that they were shut down
because the goal of the UDDI project was met however Jason Bloomberg states it’s
because it “isn't how companies do business -- there's always a human element to
establishing a relationship”.
Apache jUDDi is an open source Java implementation of the UDDI specification for web
services. It maintains a public UDDI server although it is mainly used for testing services
(Apache, 2015).
42. 42
RESTful Services
Representational State Transfer (REST) is an architecture style for distributed systems like
the World Wide Web. REST was first defined in Roy Thomas Fielding in 2000 in his
famous PHD dissertation ‘Architecture Styles and the Design of Network-based Software
Architecture’ (Fielding, 2000).
REST is used to build web services that are lightweight, maintainable and scalable
(Vaqqas, 2014). It is important to note that REST isn’t a web service, but an architecture
style.
RESTful Services must comply with the following principles taken from Roy Fielding’s
dissertation:
Stateless Communication must be stateless in nature “such that each
request from client to server must contain all of the information
necessary to understand the request, and cannot take advantage
of any stored context on the server. Session state is therefore
kept entirely on the client .This constraint induces the properties
of visibility, reliability, and scalability”
Caching Responses to a request must be labelled cacheable or non-
cacheable. “The advantage of adding cache constraints is that
they have the potential to partially or completely eliminate some
interactions, improving efficiency, scalability, and user perceived
performance by reducing the average latency of a series of
interactions”
Uniform Interface Enables the access of a resource using a uniform interface,
such as HTTP methods (GET, POST, PUT, and DELETE).
“Overall system architecture is simplified and the visibility of
interactions is improved”. However this makes the
style more inefficient as data is transferred in a standard from
rather than a unique form specific for the intended application
Layered System “Each component cannot ‘see’ beyond the immediate layer with
which they are interacting”. This improves scalability by
enabling load balancing and by providing shared caches.
Client-Server The Uniform Interface separates the clients from servers. This
makes clients not have to worry about data storage and
Servers do not worry about user interaction. This makes client
code more portable and servers simpler and more scalable.
Table 20 –Principles of a RESTful Service (Fielding, 2000) (Oracle, 2015)
43. 43
REST is a lightweight & simple alternative the more complicated CORBA, RPC and SOAP
methods. REST can be summarised as simply standard to make calls between machines.
Dr Elkstein claims that REST is dependent on HTTP as it is a stateless, client-server and
cacheable communication protocol (Elkstein, 2008). Although, HTTP is not explicitly
defined as compulsory for REST services, it is almost always implemented that way and
was actually inspired by HTTP (Fielding, 2000).The key feature that sets the REST style
from other styles is the use of a uniform interface.
In REST, the endpoint of the API’s are the URLs. URLs are used to point to a resource. If
there is a URL, then there is a resource. REST can represent resources (objects) as a
language-independent representation through languages like JSON, XML, HTML and
YAML. It’s important to note that a response is not the resource itself, but rather a
representation of the resource in a specific format. Just like a when a web page is viewed
online, it is a representation of the resource. A representation is defined as a machine-
readable description of the state of a resource. With REST, the client and server exchange
representations of a resource which reflect its current state or its desired state.
Representational State Transfer is a way for two machines to transfer the state (the data)
of a resource by using representations.
As REST is almost always used with HTTP, it is best to discuss it as it is the most widely
implemented as an integration technology (Oracle, 2015). As mentioned earlier in the
review, in HTTP a resource being requested is identified by a URI built from the hostname
and then the path of the source. There is a method that defines an action to be performed
on the resource (typically a HTTP verb). The representation of the resource specified at
the request URI is returned in the response.
HTTP has a Uniform Interface, is used for Client-Server interaction, is stateless, is
cacheable and cannot see past its own layer so it therefore meets the RESTful principles.
JSON is better for building web services that will be used by web pages for AJAX calls.
XML is typically used for everything else, especially the more complicated calls.
The constraints for representation in REST is that client and server must be able to
understand the format. Representation must be capable of linking resource to each other
by placing the URI or a Unique Identifier (UI). The REST principles allow developers to
use HTTP’s full potential by creating API’s that can be used from almost every device and
platform.
44. 44
Advantages Drawbacks
Simple Syntax - easier to develop and
maintain
Natively Synchronous
Easy to implement Not inherently support server-initiated notifications
Fast and efficient Doesn’t fully comply with WS-*
Platform independent
Scalable
Low Maintenance Costs
Table 21 - Advantages and Drawbacks of RESTful Services
HTTP
Tim Berners-Lee is credited for originally creating HTTP in 1989 although the first official
documented version of HTTP is HTTP V0.9 in 1991. HTTP was originally implemented by
the World Wide Web initiative in 1990 (W3C, 1991). HTTP V1 was published in RFC 1945
in 1996 (IETF, 1999).
HTTP is the ‘language’ of the internet. HTTP is something that most web services have in
common so it is important to have a solid understanding.
HTTP is a request-response, application layer protocol in the client-server architecture
model. The requested resource of HTTP is made available by the use of a URL. TCP is
used to establish a connection to the default port number 80 although others can be used
if explicitly defined. A series of requests and responses in HTTP is called a HTTP session.
HTTP is stateless, meaning that every connection is independent and no information is
carried between connections.
Version Year Documentation Development
0.9 1991 W3C Documents Simple protocol for raw data transfer across the
internet
1.0 1996 RFC 1945 Allowed MIME messages, added metadata about
the data and modifiers, added POST method.
1.1 1997 RFC 2068 Mandated host header & added persistent
connections by default, added OPTIONS method,
added conditional caching, added additional return
codes, chunked transfer encoding, enhanced
compression support & proxy authentication.
1.1 Updated 1999 RFC 2616 Detailed documentation for clarity
1.1 Updated 2014 RFC 7230-7239 Much more clarity on everything. Return code 308
added as standard, forwarder header added, two
connection per server limit removed, default
45. 45
character set removed, more return codes
cacheable.
2 2015 RFC 7540 Minifies data element of HTTP, binary not textual,
servers can proactively push responses into clients,
fully multiplexed.
Table 22 - History of HTTP Versions (W3C, 1991) (IETF, 1996) (IETF, 1997) (IETF, 1999) (IETF,
2014) (IETF, 2015)
As HTTP 1.1 was not obsolete for 15 years, the majority of RESTful API’s were built using
HTTP v1.1. Consequently, v1.1 will be discussed in detail it is heavily documented as
being used in RESTful API’s.
HTTP v1.1 Request Process
1. A TCP connection is established with the server (port 80 by default)
Figure 17 - TCP Three Way Handshake
2. HTTP Request is sent. Containing method, request-URI & request header fields
HTTP Method Purpose
OPTIONS Requests information about the communication options available
GET Retrieves the information identified by the request URI
HEAD Identical to GET except the server must not return a message-body in reply
POST Submits data to the processed at the specified URI
PUT Uploads a representation of the specified URI
DELETE Deletes the resource specified by URI
TRACE Allows the client to see how the message is received by the server
CONNECT Converts the request to a transparent TCP/IP tunnel
PATCH Modify an existing resource
Table 23 – HTTP 1.1 Method Definitions (IETF, 1999) (W3Schools, n.d.) (IETF, 2010)
The Request URI identifies the resource that the request will be applied to. There are
four formats of the request URI.
URI Format Example
46. 46
* OPTIONS * HTTP/1.1
absoluteURI GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
abs_path GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
authority CONNECT www.w3.org HTTP/1.1
Table 24 - Example URI Formats for HTTP
URI Format Purpose
* Request applies to the server itself, not a resource
absoluteURI Used when request is being made to a proxy
abs_path Most common form, used to identify a resource on an server or gateway
authority Used for CONNECT method
Table 25 - Purpose of the Different Example URI Formats
The request header fields are used to allow the client to pass on extra information
about the request and itself.
Figure 18 - HTTP Request to Northumbria University's Learning Platform
Figure 18 shows a HTTP request using the GET method on the ‘/’ resource. This is an
‘abs_path’ URL. The host is ‘elp.northumbria.ac.uk’ so the full location of the
resource is ‘elp.northumbria.ac.uk/’. There are request header fields in the
connection. The user-agent field is displaying the browser information that the request
was sent from. This particular request will ‘Accept’ media types in a range of formats.
The preferred language is English US, then English which is indicated by the ‘q=0.5’
relative quantity factor. The encoding of this request is gzip or deflate. There is a
DNT field, which means ‘Do Not Track’. It is used to request that a web application
disable its tracking. A value of 1 means that this request has disabled tracking. DNT is
not a legal or technical requirement for HTTP. It is added by the browser (Firefox in this
example). The final field is the Connection which is set to keep-alive indicating that
the connection will not be dropped after the request has been received. This is known
as a HTTP persistent connection. In HTTP 1.1, persistent connections are default
unless declared otherwise. The benefit of this is less processing and memory usage,
reduced network traffic, reduced latency and improved error recovery as they can be
reported without closing the connection.
GET / HTTP/1.1
Host: elp.northumbria.ac.uk
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
47. 47
HTTP Response
After receiving and processing a HTTP request from the client, the server responds with
an HTTP response. The HTTP response consists of a Status-Line & Response-Headers
Fields. The Status-Line consists of the protocol version followed by a return code and its
associated meaning. A return code is a three-digit integer number representing a response
to the attempt to interpret and satisfy the HTTP request. Perhaps the famous HTTP
response is ‘404 – Not Found’.
As with the request, there a number of possible header fields to pass extra information in
the response.
Figure 19 - HTTP Response from Northumbria University's Learning Platform
Figure 19 shows the HTTP response to the HTTP request in Figure 18. The first line is the
HTTP version number followed by the return code and its meaning. In this case, ‘302
Moved Temporarily’ indicating that the original resource has been moved. HTTP return
code 302 is a common way of performing URL redirection. Beneath this line, the
Location field shows the new location. The Connection field is set to close, meaning
the connection will be closed. The remaining fields indicate that there will be no caching.
HTTPS
Hypertext Transfer Protocol Secure is a protocol for secure communication over a
network. HTTPS provides authentication and bi-directional encryption. HTTPS was
primarily used for online payment transactions and secure email but recently it has begun
to see widespread usage on all types of websites.
HTTP is not encrypted and is vulnerable to man in the middle attacks. HTTPS uses port
443 by default and URLS being with ‘HTTPS://’. HTTPS extends HTTP security by
adding an encryption layer of Secure Sockets Layer (SSL) / Transport Layer Security
(TLS) (IETF, 2000).
HTTP/1.1 302 Moved Temporarily
Location: https://elp.northumbria.ac.uk/
Connection: close
Cache-Control: no-cache
Pragma: no-cache
48. 48
Other application protocols include:
Protocol Purpose RESTful?
Z39.50 Search and retrieval of information in databases NO
WAIS Client-Server text searching system NO
POP3 Retrieve emails from a mail server NO
IMAP Retrieve emails from a mail server NO
SMTP Send emails to a mail server for relaying POSSIBLE
FTP Transfer files between client/server POSSIBLE
Gopher Distribute, search and retrieve files over the internet NO
IRC Text communication between client/sever NO
AS2 Securely transport data over the internet POSSIBLE
OFTP Used for EDI between business partners NO
Table 26- Application Protocols
(NISO, 2003) (IETF, 1994) (IETF, 1996) (IETF, 2003) (IETF, 2008) (IETF, 1985) (IETF, 1993)
(IETF, 2000)
There are a number of protocols that could be made into RESTful API’s however HTTP is
by far the most common and simplest to adapt. An additional alternative would be to
create a custom protocol however this can be a redundant and time consuming task as
HTTP is a perfect fit for creating RESTful web services.
WADL
Web Application Description Language (WADL) is an XML description of HTTP based
applications, primarily used to describe RESTful web services.
WADL is not as necessary to REST services as WSDL is to SOAP services. This is
because RESTful services have a much simpler interface. (Richardson & Ruby, 2007).
WADL was submitted to the W3C by Sun Microsystems in 2009 but has not been officially
made into a standard (IETF, 2009).
49. 49
Development Tools
Java Platform Enterprise Edition (J2EE)
J2EE was created in 1999 by Sun Microsystems and is a development of Java Platform,
Standard Edition (Java SE).
Java SE is a platform used for development and deployment of code for servers and
desktops (Oracle, n.d.). Java SE uses object-orientated programming to define a wide
range of general APIs such as the Java Language Specification and Java Virtual Machine
Specification (Oracle, 2006).
J2EE extends Java SE by providing an API for web services, object mapping and for
designing distributed and tiered architectures. Javaworld’s definition is that J2EE is a java-
based technology stack that has the ability to build enterprise applications that are secure,
reliable and maintainable (Monteiro & Sheil, 2002).
Component Definition
Java Server Pages (JSPs) Auto generates platform independent web pages
Servlets Small Java program that receives and responds to
requests from web clients
Enterprise Java Beans (EJB) Used to encapsulate business logic
Java Connectivity Architecture (JCA) Connects to applications to servers (typically legacy)
Java Messaging Service (JMS) Used for sending messages between multiple clients
Java Management Extensions (JMX) Used for management and monitoring applications
Java Naming & Directory Interface
(JNDI)
Allows objects to be looked up by name
Java Database Connectivity (JDBC) Connects applications to databases
Hotspot Virtual Machine Java VM for desktops and servers
Table 27 - J2EE Key Components (Monteiro & Sheil, 2002) (Oracle, 2013) (Apache Tomcat,
2012)
50. 50
JDK
A common implementation of J2EE is Oracles Java Development Kit (JDK).
Figure 20 - JRE & JDK Conceptual Diagram (Oracle, 2014)
JDK includes a complete Java Runtime Environment (JRE) plus tools for developing,
debugging and monitoring applications (Oracle, 2014). JDK is a development environment
for building applications, applets and components using the Java programming language
(Oracle, 2014). JDK has a built in ORB which can greatly help in integrating distributed
systems.
Oracle JDK is more stable than the open-source alternative; Open-JDK. Oracle JDK is a
slight improvement of Open-JDK as it has more classes, bug-fixes and is thoroughly tested
(Java, 2006). Open-JDK uses open libraries whereas Oracle JDL uses closed libraries
(Technfun, 2013).
JVM
A Java Virtual Machine is an emulation machine that enables a computer to execute a
Java program (Oracle, 2015). JVM is software that sits on top of an Operating System
(OS). JVM is a fundamental part of the JSE and J2EE framework as it enables all other
components to execute. Please see Figure 20.
51. 51
JVM does not know the Java language; however, it does recognise the binary format of
the class file format. The class file contains JVM instructions called bytecode or
portable code. This is used by the JVM to define a single class or interface. (Oracle, 2015,
p. 69)
JMS
Java Messaging Service (JMS) is an API for message orientated middleware (MOM). JMS
is part of J2EE and thus JDK. The official specification describes JMS as “an API for
accessing enterprise messaging systems from Java programs” (Sun Microsystems, 2002).
JMS is a mechanism for Java programs to create, send, receive and read messages.
Messaging is a broad term in computing. It is used to describe emails, operating system
concepts but in the MOM perspective, it is used to describe asynchronous
communications between applications.
A JMS application consists of these parts:
Part Definition
JMS Clients Java programs that send and receive messages
Non-JMS Clients Clients that don’t use the JMS API.
Messages Messages that are used in communication between
clients.
JMS Provider A messaging system that implements JMS on top of
a messaging product.
Administered Objects Preconfigured JMS Objects
Table 28 - JSM Application Components
JMS clients can also use the JDBC API in the same transaction. This is often achieved
automatically by implementing clients as EJB’s. (Sun Microsystems, 2002)
JBI
Java Business Integration (JBI) is a specification for an approach for implementing a SOA.
“JBI defines an environment for plug-in components that interact with a services model
based directly on WSDL 2.0” (Oracle, 2010). The plug in components can be providers,
consumers or both.
JBI consists of Service Engines, Binding Components and Component Loggers. Service
Engines are components that provide services within the JBI environment and consume
local or remote services. Binding Components are proxies for consumers or providers
outside the JBI environment. They are typically based on a standard communication
52. 52
protocol like HTTP, FTP, JMS or SMTP and or call an external service. Component
Loggers are self-explanatory.
EJB
An essential part of the J2EE platform is Enterprise Java Beans (EJB). EJB is an API that
provides the architecture to develop and deploy high performance, highly scalable and
robust applications. The EJB container automatically provides many services such as
transaction handling, logging, load balancing and security. This allows the developer to
focus on the business logic of the application.
The original Java Bean specification was published in December 1996. It defined a set of
policies that enabled Java Objects to be reusable and easily incorporated into applications
(Sun Microsystems, 1996). They were originally intended as a general method of defining
reusable application components (Walls, 2010).
EJB was originally developed in 1997 by IDM but was then taken over by Sun
Microsystems. In 1998, Sun published the first EJB specification (Sun Microsytems, 1998).
An enterprise bean is a Java component that when combined with other resources, can
create distributed client/server applications. EJB’s allow the combination of different tools
from different vendors to help build distributed applications. They make it easier to write
applications as developers can focus on the business logic knowing that transaction
management, multi-threading and resource pooling automatically being handled. EJB can
be used with CORBA to provide interoperability with EJB and non-java applications (IBM,
2013).
There are three types of beans:
Entity Beans
Entity Beans permanently store data. Often used to access databases.
Session Beans
Sessions beans do not require database access but can get it indirectly via an entity bean.
They use resource references to obtain database access.
Message-Driven Beans
Act as a message consumer within a JMS messaging system. They can perform business
logic on message contents. Message-driven beans process multiple JMS messages
asynchronously and have no remote interface so cannot be accessed directly by external
clients.
53. 53
Typically all three types of beans are used together in an enterprise application (IBM, n.d.).
EJB’s mandate deployment descriptors and remote/local interfaces which makes them
complicated to develop. As a result, many developers have looks for an easier alternative
(Walls, 2010).
JCA
Java Connector Architecture is used as part of Enterprise Application Integration to
connect Enterprise Information Systems with an Application Server (Oracle, 2013).
The connectors defined by JCA specifications are called resource adapters. They can be
used to implement an optional Common Client Interface (CCI) to provide J2EE clients to
the information system. JCA specifications defines a set of Service Provider Interfaces
(SPI) as System Contracts. These are used to host resource adapters on application
servers. JCA Resource Adapters support two way communication between J2EE
components and Enterprise Information Systems.
Outbound Communication – Started by J2EE component acting as a client to access the
information system
Inbound Communication – Started by the information system to the J2EE component. It
is an asynchronous communication that used the messaging infrastructure provided by the
application server (IBM, 2006).
By using JCA, vendors no longer have to customize each their products for each
application server or extend its application server whenever a new information system is
introduced (Oracle, 2013).
Figure 21 - JCA Inbound and Outbound Scenarios
54. 54
JDBC
Java Database Connectivity (JDBC) is an API that defines how a client can access a
database. Applications using the JDBC API can execute Structure Query Language (SQL)
queries then receive results and execute the changes to a data source. JDBC can also be
used to interact with multiple data sets in a distributed environment.
JDBC was introduced in 1997 in JSE and J2EE editions of the Java platform. JDBC was
derived from the X/Open SQL common language infrastructure. From the concepts
defined in the X/OPEN CLI and SQL standards, JDBC has created a natural and easy to
use mapping using the Java language (Oracle, 2011). JDBC must use a separate driver in
order to actually access a database. See Figure 22 below.
Advantages Drawbacks
Consistent with SQL Standards Correct drivers need to be deployed for each type
database
Vendor-Neutral Database Specific SQL queries needed
Simple to develop Performance can be affected when multiple
connections are created and closed.
Object-Orientated
Enhances Reliability, Availability &
Scalability by enhancing support in
resource management, re-use of prepared
statements & error handling.
Forward compatibility with connectors
Portable – DB connection identified via URL
No configuration on client side
Enables development by providing meta
data access
Table 29 - Advantages and Drawbacks of JDBC (Java Language Experts, 2013) (Oracle, 2011)
55. 55
Figure 22 - JDBC Architecture. Image from (DevelopersBook.com, n.d.)
ODBC
Open Database Connectivity (ODBC) is a vendor-neutral API for accessing databases.
ODBC is an important industry standard for Windows and Macintosh applications
(Microsoft, 2016). It was created in 1992 by the SQL Access Group (mainly Microsoft)
(Easysoft, 2009). It allows applications to use SQL statements without knowing the
proprietary interfaces to the databases meaning most data sources can be accessed. It is
important to note that ODBC is just an interface. ODBC is mostly used for simultaneous
access to different sources of data (mySQL, 2016).
JDBC and ODBC are not rival technologies. They can be used together to provide access
to database for applications. The JDBC component could use the JDBC interface or the
ODBC interface with the help of a bridging application.
56. 56
.NET
.NET is a framework by Microsoft that enables developers to create applications on
Microsoft platforms (Microsoft, 2013). It is written in C# which is Microsoft’s object-
orientated programming language (Microsoft, 2016).
.
Figure 23 - History of .NET Framework (Microsoft, 2016)
.NET has evolved considerably since its initial mention in 2000, adding more functionality
with each release. There are currently three types of the framework available:
Name Description
.NET Framework The standard framework for desktop and servers
.NET Compact Framework Stripped-down version for embedded devices
.NET Micro Framework For ‘deeply’ embedded devices. Not OS required – Open Source
Table 30 - Types of .NET Frameworks (Egli, 2015)
Technologies such as DCOM, CORBA and Java Beans allow programmers to implement
component-orientated applications. DCOM is difficult to master and Java doesn’t easily
allow for much interoperability. .NET utilises these previous technologies strengths and
learns from their weaknesses (Löwy, 2005).
The .NET Framework is built around two major components. The Common Language
Runtime (CLR) and the .NET Framework class library (FCL).
57. 57
The Common Language Runtime (CLR) is the backbone of the .NET framework. It is a
mechanism that manages code execution and provides valuable services such as memory
and thread management whilst ensuring security (Microsoft, 2016). The FCL is a
repository of reusable components that integrate with the CLR.
Key .NET technologies:
Table 31 - Key .NET Technologies (Microsoft, 2016)
Figure 24 - .NET Framework Architecture
Advantages Drawbacks
Supports Managed and Unmanaged code Managed code can be slower than native code
WPF + WCF work well together Invokes supplier ‘lock-in’
Fully integrated Visual Studio IDE Expensive to move applications to .NET
Interoperability of languages
4000+ Reusable Components
Integrates with Microsoft products easily
Table 32 - Advantages and Drawbacks of .NET Framework (Houwing, 2010) (Rongala, 2015)
Name Definition
ASP.NET Classes & tools for creating dynamic web
applications
ADO.NET Classes that expose data services
Windows Presentation Foundation (WPF) Renders User Interface (UI) in Windows applications
Windows Coms Foundation (WCF) Model for building service-orientated applications
Visual
Studio.NET
Windows COM+ Services
Common Language Runtime
.NET Framework Base Classes (FCL)
ASP.NET Windows Forms
Common Language Specification
VB C++ C# JScript ….
ADO.NET XML Threading IO
ASP.NET Security Diagnostics Etc…
58. 58
VERT.X
VERT.X is a multiple-language (polyglot), event-driven, open-source framework that runs
on the JVM (Wolff, 2012). VERT.X is toolkit but can also function as a platform. It offers a
range of API’s for web development, database access, mail clients, authentications and
authorization, HTTP/TCP access, Rx-Java callback API’s and testing tool-kits (VERT.X,
2016). VERT.X is non-blocking and uses a “small number of kernel threads” to handle
concurrency (VERT.X, 2016). VERT.X has one of the smallest overheads and is one of the
fastest frameworks (TechEmpower, 2013). Created by Tim Fox in 2011, VERT.X moved to
Eclipse in 2012 after legal disputes with VMWare (Blewitt, 2013). In 2014 VERT.X was
awarded the JAX Innovation Award (JAX Awards 2014, 2014).
Spring Framework
An alternative to using EJB is the popular and open source Spring Framework. Spring is
the most popular development framework by enterprises (Tutorials Point, n.d.).
Spring Framework was developed by Rod Johnson in 2002 (Johnson, 2002) and was
released under Apache 2.0 in 2003. Spring has the same benefits of J2EE but without the
complexity. It can be seen as a development of J2EE. Spring was created to simplify the
complexity of Enterprise Application Development. Craig Walls (Walls, 2010, p. 5) defines
this through 4 key strategies:
Lightweight and minimally invasive development of Plain Old Java Objects (POJO)
Loose coupling through dependency injection and interface orientation
Declarative programming through aspects and common conventions
Boilerplate reduction through aspects and templates
Service Use
Inversion of Control Configuration of components via dependency injection
Aspect-Oriented Programming Enables cross-cutting concerns
Security Authentication and Authorization
Data Access JDBC and mapping tools to access databases
Messaging Listeners for message consumption from via JMS
Remote Access Supports RMI, CORBA and HTTP-based Web Services
Transaction Management Unifies several TM APIs
Remote Management Remove configuration via JMX
Table 33 - Spring Framework Key Features - (Walls, 2010) (Johnson, 2005) (Johnson, 2004)
(Johnson, 2002)
