Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dissertation - Ashley Kingscote

230 views

Published on

  • Although I'm a KS3 student, I decided to give Jeevan's guide a try because I know GCSE and KS3 are fairly similar. Looking back now, it was one of the best decisions I made. The guide has helped me jump from a level 6A to a level 8C in maths, and I'm only in year 8! Achieving a level 8 in maths is regarded as a gifted individual. Thank you for this terrific guide and I will recommend it to anyone taking a maths exam! ➤➤ http://t.cn/AirrSv7D
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Dissertation - Ashley Kingscote

  1. 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. 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. 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. 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. 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. 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. 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
  8. 8. 8 Analysis.......................................................................................................................... 60 Business A Data.......................................................................................................... 61 Business B CRM......................................................................................................... 62 EAI Technologies........................................................................................................ 63 Java RMI, CORBA and DCOM Comparison .......................................................................... 63 XML-RPC, SOAP and RESTful Web Services Comparison .................................................. 64 Development Tools ................................................................................................................. 64 Messaging................................................................................................................... 67 Data Mapping.............................................................................................................. 68 Other Tools ................................................................................................................. 68 Chosen Approaches.................................................................................................... 69 Resources............................................................................................................................... 69 Concept 1................................................................................................................................ 69 Concept 2................................................................................................................................ 70 Concept 3................................................................................................................................ 70 Requirements.............................................................................................................. 70 Concept 1 – RESTful WS ....................................................................................................... 71 Concept 2 – SOAP WS........................................................................................................... 71 Concept 3 – Message Broker ................................................................................................. 71 Concept Key Metrics............................................................................................................... 72 Basic Risk Assessment........................................................................................................... 73 Synthesis........................................................................................................................ 74 Environment Setup...................................................................................................... 74 Business A.................................................................................................................. 76 Business B.................................................................................................................. 77 Database Connectivity ................................................................................................ 79 Concept 1 – RESTful WS............................................................................................ 80 Design..................................................................................................................................... 80 Implementation ....................................................................................................................... 82 Testing .................................................................................................................................... 85 Concept 2 – SOAP WS ............................................................................................... 92 Design..................................................................................................................................... 92 Implementation ....................................................................................................................... 93 Testing .................................................................................................................................. 103 Concept 3 – Message Broker.................................................................................... 116 Design................................................................................................................................... 116 Implementation ..................................................................................................................... 116 Testing .................................................................................................................................. 121
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)

×