Using the Service-Oriented Approach (SOA) to build Information Technology A report prepared by Guy LeBlanc November 2007Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 2 of 54 Using the Service-Oriented Approach to build Information Technology Table of Contents Background Information ..................................................................................................... 4 Introduction ..................................................................................................................... 4 Purpose ............................................................................................................................ 5 Objectives ........................................................................................................................ 5 Scope ............................................................................................................................... 5 Present IT Situation ............................................................................................................. 6 The Challenges of IT ....................................................................................................... 6 Trends and Opportunities ................................................................................................ 6 Business Management‟s whishes .................................................................................... 8 IT Strategic Planning ......................................................................................................... 10 Popular IT Shop Strategies ............................................................................................ 10 Informal IT Shop ........................................................................................................... 10 Formal IT Shop ............................................................................................................. 10 Outsourcing ................................................................................................................... 11 COTS (Commercial Off-the-Shelves) ........................................................................... 11 Determining Factors for selecting a Strategy ................................................................ 12 IT Strategic Planning ..................................................................................................... 12 IT Planning Steps .......................................................................................................... 12 The Theory of Service Orientation .................................................................................... 14 The Future of IT Development ...................................................................................... 15 Principles of Service Orientation .................................................................................. 15 Reusability ..................................................................................................................... 16 Discoverability .............................................................................................................. 17 Loose Coupling ............................................................................................................. 17 Abstraction .................................................................................................................... 17 Composability ............................................................................................................... 18 Autonomous .................................................................................................................. 18 Statelessness .................................................................................................................. 19 Technology-agnostic nature .......................................................................................... 19 Business Services .......................................................................................................... 19 Types of service delivery .............................................................................................. 20 Service-Orientation Components .................................................................................. 21 Application versus Service ............................................................................................ 22 Examples of reusable services ....................................................................................... 22 Open Standards ................................................................................................................. 24 Introduction ................................................................................................................... 24 Definition of a “Standard” ............................................................................................. 24 Open Standards defined ................................................................................................ 25 Benefits of Open Standards ........................................................................................... 25 Well-known Standards Bodies ...................................................................................... 26 Principles of Open Standards ........................................................................................ 26 Business Case for Open Standards ................................................................................ 26 Well-known Open Standards ........................................................................................ 27 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 3 of 54 OASIS ........................................................................................................................... 27 W3C‟s XML Standard .................................................................................................. 27 Risks of Using Open Standards ..................................................................................... 28 Web Services Architecture ................................................................................................ 29 Introduction ................................................................................................................... 29 Web Service Explained ................................................................................................. 29 The Mechanics of Web Services ................................................................................... 31 The Standards of Web Services .................................................................................... 31 WSDL ............................................................................................................................ 32 UDDI ............................................................................................................................. 32 XML .............................................................................................................................. 32 SOAP ............................................................................................................................. 33 Service-Oriented Architecture ........................................................................................... 34 Introduction ................................................................................................................... 34 Definition ...................................................................................................................... 35 Modern or Contemporary SOA ..................................................................................... 35 Newcomer and Lomow ................................................................................................. 35 Service-Oriented Architecture ....................................................................................... 36 Example of a Simplified Point of Sale process ............................................................. 37 The Business Process for Sales ..................................................................................... 37 The Process-enabled SOA ............................................................................................. 37 The Enterprise before the Computer ............................................................................. 38 Characteristics of the enterprise before the computer ................................................... 38 Enterprise using the traditional approach ...................................................................... 39 Flaws with the traditional approach .............................................................................. 40 Improving the Enterprise with SOA .............................................................................. 40 Generic use of the word Service ................................................................................... 41 Elementary SOA Model with ESB ................................................................................ 42 SOA Block Model ......................................................................................................... 42 SOA definition of Service ............................................................................................. 43 The Business Case for SOA .............................................................................................. 44 Introduction ................................................................................................................... 44 Benefits .......................................................................................................................... 44 More about Benefits ...................................................................................................... 45 Costs and Benefits ......................................................................................................... 45 Risks and Potential Downfalls ...................................................................................... 47 SOA Security Vulnerabilities ........................................................................................ 47 Counter-measures against threats .................................................................................. 48 Security Layers .............................................................................................................. 49 WS-Security Specification ............................................................................................ 49 WS-Security drafts ........................................................................................................ 49 WS-Security Enhancements .......................................................................................... 49 Conclusion ......................................................................................................................... 50 Conclusion ..................................................................................................................... 50 Recommended Actions ................................................................................................. 50 References ......................................................................................................................... 51 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 4 of 54 Background Information Introduction Current Information Technology infrastructures have reached a crossroad as more and more Enterprises seek ways to restructure, reorganize and re-align their IT shops. Many believe that in 5 to 10 years from now, Information Technology (IT) will be transformed as the old methods of building huge monolithic systems are likely to give way to more efficient and agile methods. Thanks to recent advancements in the Internet and Web Services technologies a new approach to building IT systems called the “Service-Oriented Architecture” (or simply SOA) is quickly gaining momentum and acceptance. This new approach, modeled from modern schools of engineering and architecture, is setting the stage for assembling applications at runtime through the use of reusable “plug and play” services. This new way of thinking could not have come at a better time as today‟s organizations are seeking ways to control development and maintenance costs and to consolidate IT infrastructure. To do so, most organizations realize that they will have to re-invent their information systems into services (rather than applications) to improve the flexibility and agility needed to support all business processes. A well-planned strategy based on Service-Oriented Architecture (SOA) will put the Department of Postsecondary Education, Training and Labor in the driver‟s seat in terms of procuring cost-effective agile IT services. The SOA approach results in a vendor and technology agnostic environment where services can be acquired from either an internal IT Shop or from outside vendors of SOA-enabled services. SOA goes beyond the current methods of concentrating solely on the microscopic reusability of objects and programming code by encouraging the reusability and scalability of business-focused services instead. This approach results in an organization whose processes behave more like a dynamic living organism. In other words, our applications can dynamically re-align themselves to the changing needs of the enterprise on-the-fly (during runtime). The approach helps us in designing “plug-compatible” services rather than building gigantic complex and inflexible applications. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 5 of 54 Background Information, Continued Purpose The purpose of this report is to introduce the concepts of Service-Orientation (SO) methods (a.k.a. Service-Oriented Approach or SOA) as a sound architectural platform for the implementation of Information Technology (IT) and eGovernment. The information is to serve as a Business Case for the using the emerging Service-Oriented Architecture (SOA) as a means to weave the Information Technology (IT) tapestry of our organization. Objectives This document is to be used as a decision-support platform for investigating the viability of using Service-Oriented Architecture (SOA) as a strategic means to implement information systems for the organization. The report focuses on the following main objectives:  to present a viable IT strategic vision using SOA to concentrate on Service-Oriented Architecture1 and its underlying technologies (i.e. Web Services and Open Standards) to serve as a learning device for management to unveil the underlying benefits as well as some of the potential risks involved Scope This report was written especially for: the decision-makers who are mostly interested in knowing how this new approach can help them improve their business processes the projects managers and stakeholders who might be interested in finding innovative ways of approaching application integration and maintenance just about anyone who is generally interested about the SOA approach 1 The terms Service-Oriented Architecture, Service-Oriented Approach, Service-Based Applications are used interchangeably throughout this report to mean one and the same thing. The acronym “SOA” is also used extensively. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 6 of 54 Present IT Situation This section examines the issues of today‟s traditional IT environment. These issues are symptoms of the traditional methods used for building business applications. A good understanding of these can be useful to demonstrate the effectiveness of the SOA approach later on. The Challenges of IT Today‟s IT Shop faces many challenges:  How do we provide robust, adaptable and flexible solutions to meet an ever-changing business environment? How do we deliver our systems on time and on budget? How can we build and organize IT so that it automatically realigns itself with business objectives and expectations? How do we plan and manage the diverse and often incompatible applications? (Many or most IT environments are heterogeneous in nature and are composed of islands of disparate and often incompatible technologies that only serves to lock us in deeper into the grips of the technology vendors. All technology-driven methods eventually lead to our inability to change effectively as the need arises.) How can we deliver business services without sacrificing the security, privacy and confidentiality of our information? How do we organize the IT Shop to deliver flexible agile services? Can we build applications that are truly inter-operable and integrated? What can be done to improve our support of the business processes? Do we have ways of extracting knowledge from all the disparate databases we have been collecting over the years (Business Intelligence)? How can we provide a flexible environment where applications, COTS (Commercial Off-The-Selves), CRM and ERP applications can co-exist and be easily integrated? Do we need to re-write applications every time a new technology comes into the picture? How do we cope with proprietary technologies? How can we prevent being pushed into costly technology-driven locks – a strategy that only serves the vendor‟s interest? Trends and Opportunities Trends have an impact on how we manage IT. Here is a short list of what might be considered trendy: Decreasing IT budgets: Consolidation and centralization of IT infrastructure. Organizations are trying to find ways to improve efficiency of operations and to lower their costs. With the Y2K boom days over, management is less willing to throw huge sums of dollars for the “re-writing” of existing applications. Application Servers and multi-tier platforms: IT Shops are now Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 7 of 54 implementing application servers such as .NET2, J2EE3 and LAMP4.  Web Services and Open Standards: The emergence of Open Standards from the W3C5 organization (i.e. the Web Services Architecture papers) has created new possibilities and opportunities like eBusiness and eGovernment. Nowadays, anything that starts with the “e” attracts lots of attention and opportunities. On-Demand Computing: Web Services have sparked innovations in the application delivery arena such as the “On-Demand” or the “pay-as-you-go” models. On-Demand computing borrows the ideas of the “power utilities” where citizens pay as they go according to their consumption. This is opening new possibilities for outsourcing and especially CRMs (Customer Relationship Management) and other COTS6. One-Stop Shop (Portals): Many institutions like Governments have created centralized portals where various services are easily discoverable and accessible by customers. The One-Stop Shop was a great success by those pioneering institutions like Service New Brunswick. Service New Brunswick has become the model around the world for building Government Web portals. Outsourcing: Outsourcing development projects appears to be cheaper because organizations no longer have to keep developers on the payroll for extended periods. Many organizations are outsourcing to developing countries abroad such as India. Outsourcing development projects could represent a substantial cost saving measure. Thin Client Computing: Thin Client is a model introduced in the late 90‟s by Netscape and SUN Microsystems where clients use low-cost terminals connected to a server that does all of the processing. The idea never really caught on back then. However, today it is a different story. The technology is designed to save money by installing stripped-down versions of the personal computer on user desks and invest on cutting-edge servers for all processing needs. This method has enormous potential and great benefits for the organization. It is estimated that for every desktops converted into a thin client environment could potentially save up to $1,150 annually. Assuming that 10,000 desktops could easily be migrated to thin clients, it is then conceivable that the NB Government would save around $11,000,000 annually7. Web 2.0: Web 2.0 generally refers to Web services that let people collaborate and share information online. In contrast to the first generation of Web offerings, Web 2.0 applications are more interactive, giving people an experience similar to a native desktop application as opposed to a static 2 “.Net” is Microsoft‟s application server competing against the well-established J2EE (Java) and the emerging LAMP stack from the Open Source community. 3 J2EE is SUN‟s Java application server. See footnote number 4 above. 4 LAMP (Linux Apache MySQL Python) is the Open Source application server (a very recent newcomer) competing directly with the two well-established front runners. 5 The World Wide Web Consortium is an Open Standards organization overseeing the protocols and technologies of the Internet and Web Services. 6 Commercial Off-The-Shelves software. 7 Total cost of ownership was calculated from 2X‟s website: http://www.2x.com/whitepapers/fat2thinsavings.htm (a well-known Thin Client vendor). The NB Government presently supports around 13,000 desktops (and much more if schools and other agencies are included). The $1,150 per PC cost savings was calculated by adding $1000 for administration costs, $200 for hardware cost, and subtracting $50 for additional hardware. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 8 of 54 Web page. Web 2.0 contains new collaborative concepts such as Blogs8, Google, Wikipedia, On-Demand Services, and Service-Oriented applications. Web 2.0 increases the participation of internet users by welcoming the sharing of information and knowledge.  Data Warehousing and Business Intelligence still remain a major topic as the enterprise seeks to extract more value from the corporate databases. Service-Oriented Architecture (SOA): In very recent years, SOAs (Service Oriented Architectures) have become increasingly popular by adding a special layer between the business processes and the application or technology layer (i.e. the application server). SOA promises to do for internal IT applications what Service New Brunswick did for improving access for government customer services. Linux, a very popular Open Source9 Operating System, is slowly gaining more popularity and many will agree that it is now ready for the enterprise. Linux is freely available to anyone who wants it. In most aspects, Linux appears to be as robust or more than Windows XP. Linux has made great gains in the server market but still lacks momentum for the desktop mainly due to product image and the lack of compelling personal and home software. Gaming might offer the greatest opportunity to push Linux on the Home desktop. Open Docs: Open Docs is an Open Standard designed to level the playing fields between all the major office productivity suites such as MS Office, Corel and Star Office by standardizing all the popular file format to achieve 100% file compatibility. Gone are the days when Word Perfect could not read or write MS Word documents. Open Docs has the potential of revolutionizing document file sharing to new heights. Open Standard file formats will gain increased acceptance as more organizations seek inter-operability, integration and universality10. ERP and CRM Vendors (like IBM, SAP, ORACLE, Siebel, etc) are in a race to get their flagship applications ready for the SOA. The idea is to add agility and to make them “plug-compatible” – so to speak. SOA-enabled packages will compete directly with the internal IT shop. Security: Products aimed at improving our security against the threats of viruses, hackers, worms and whatever else will continue to flourish. New opportunities are emerging with the introduction of the SOA-enabled enterprise. Business Management’s whishes The following list describes the ideal IT environment for business managers. They would like an IT that: Responds quickly to changes (i.e. agility and flexibility). IT should 8 Wikipedia defines a Blog as: “A website where entries are made in journal style and displayed in a reverse chronological order. 9 The Open Source model is a concept where a software component is distributed free of charge. On the other hand, the Proprietary model is one where “if you use it you must pay for it”. The Open Source vendor usually earns profits from services as a result of a consumer using it instead of profiting from the selling price of the software as in the case of Proprietary-based. 10 This word is used to convey the idea that the sharing documents or files should be a global and cooperative aim of all vendors. It shouldn‟t matter what software you use to work with any of those files. It makes sense to be able to work together instead of being locked in working with a proprietary document format, which only the more privileged can afford. The underlying motivation of SOA is based on Open Standards, which are designed to undo the shackles of proprietary file formats. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 9 of 54 align effectively to enterprise re-organizations, restructures and mergers. (The inability of IT to accommodate change and flexibility within business processes continues to be a major hurdle. The discontinuity of business processes caused by the monolithic nature of legacy information applications does not reflect the natural flow and boundaries of the Enterprise and its business units.)  Is cost-effective. Management needs the ability to control and manage existing assets – including IT. The need to reduce TCO (Total Cost of Ownership) is very important. Can deliver business results in a timely fashion. Is resilient and less affected by technological changes. Management is weary of being pushed and pulled into high-cost migrations for no real business reasons other than technology. Eliminates all integration problems between applications. The failure of integrating applications through traditional methods is a major concern. Can be improved on development time and costs. (Many managers believe that the dependency on high-cost maintenance, technical support and developers should ease off over time as our Information Systems are developed. Instead, they fall victim to the endless cycles of re-development and the high cost of the traditional IT shop methods.) Is flexible enough to accommodate Commercial Off-the-Shelves CRM and ERP packages. If solutions are available off-the-shelves, why should we need to build them? Couldn‟t we simply have plug-compatible components that could easily integrate with other applications effortlessly? Can accommodate Business Intelligence tools, data warehousing and other managerial tools to improve reporting and decision-making. Management is more than aware of all the silo applications that cannot report high-level information to senior management. Can integrate security seamlessly into applications without sacrificing functionality. Has little or no down times. Can easily incorporate mobile employees. The mobility of employees has grown considerably thanks mainly to telecommunications advances. It is important to connect mobile employees and outside resources with internal systems. Is Strategic to the Enterprise. Strategy or long-term planning of our Information Systems requires sound strategic planning practices. John Zachman, the foremost authority on Enterprise Architecture, often made the remarks: “The Enterprise is our Information Systems and our Information Systems is the Enterprise.” Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 10 of 54 IT Strategic Planning Popular IT Shop Strategies Organizations adopt IT strategies based on their mission. The effectiveness of an organization‟s IT is a function of the underlying strategy used to deliver IT. The following list identifies the most popular means to implement IT:  Some organizations use an Informal (Organic) internal IT Shop. Some will eventually decide to Outsource IT Some will invest a traditional Formal IT shop Others will purchase or rent COTS (Commercial Off-The-Shelves) applications including CRMs and ERPs The brave will organize IT under an Enterprise-wide Architecture strategy. Informal IT Shop The Informal IT strategy is one where the IT planning functions are not formalized in any way. This is typical of startup firms that need to function organically in order to promote growth, innovation and competitive prowess. These organic enterprises (in their infancy stage) will often take on a “jack of all trades” approach as they seek to penetrate new markets and to align quickly to business needs. They usually adopt a “lean and mean” structure (i.e. flat pyramid) to improve cost-effectiveness and competitiveness. Informal IT shops have no real IT governance in place and very little bureaucracy. The lack of “red tape” can be effective to stimulate growth early on where quick and efficient execution is necessary to stay viable. However, with no formal governance in place, IT will eventually (in the long-term) become very difficult to manage and control because IT projects are not planned, coordinated and organized for integration and architectural fit. Formal IT Shop In bigger mature organizations, IT has evolved into a distinct responsibility area along with a formal managerial structure and specialized functions. The formal structured IT shop has a mandate to deliver IT applications. To do so, it takes on a more bureaucratic nature as it seeks to control rising IT costs and to improve the quality of its products or services. In these typical shops, there is a formal methodical process for the purpose of prioritizing the various IT projects (i.e. a Governance policy). The roles and responsibilities of employees are usually well defined within the framework of a very formal methodology. Despite all good intentions, bureaucratic IT structures do not necessarily guarantee cost-efficiency and productivity. In many instances, especially during the growth phase, a more organic “lean and mean” approach is definitely preferable. Bureaucracy slows down the process somewhat by instituting the splitting of employee responsibility and accountability roles. The freedom to experiment, initiate and innovate is a much lesser priority. The greatest threat to any bureaucracy is the stagnation and the high cost of losing out to new Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 11 of 54 opportunities and new ideas. Outsourcing Outsourcing strategies have been very popular and will continue to be for some time. This is a strategy where the responsibility of IT operations (like development work or technical support) is handed over (in full or in part) to an outside provider. The idea is that substantial savings can be generated by taking advantage of the competition amongst the vendors or service providers. This strategy can give the organization great leverage in negotiating the most “bang” for the buck. Outsourcing also offers the cost advantage of not having to bother with managing a team of IT developers and other things such as employee seniority and pensions. Organizations that outsource part of their IT operations must weigh the risks and costs of handing over their business versus the costs of having their own internal resources. Most organizations use hybrid structures where outsourcing is used in combination with an internal IT function. Outsourcing, in many instances, is only considered when the IT function is stretched to the max and when the organization wishes to eliminate certain costs such as development. In many situations, the outsourced IT operations are returned to the customer once the project life-cycle is completed – the end of a development project for example. This makes sense once an internal IT shop has acquired the necessary resources to maintain the outsourced application. COTS (Commercial Off-the-Shelves) One way to build an IT environment is to purchase or lease pre-built packaged applications sold by outside developers. The idea is that an organization can save a substantial amount of dollars and time by simply adopting a generic pre-built application instead of developing a custom-made application. COTS have been a very popular strategy for many organizations that could not afford a team of IT developers. COTS include CRM and ERP vendors like ORACLE, Siebel, PeopleSoft and many more. COTS (Commercial Off-the-Shelves) (continued) The success of COTS depends largely on the degree of customization needed to fit the requirements of the target environment and on the degree of change imposed on the user community. For those reasons, COTS applications have a substantial cost disadvantage during the implementation phase. It is a well-known fact that many COTS-based projects have a questionable success rate simply because they took too long (& too many resources) to customize and implement in the long run. Risk and change management must be well executed for the effective implementation of COTS applications. Lately, however, CRMs, ERPs and COTS have a renewed sense of vigor and market potential as new methods, like those of the Service-Oriented Architecture, are replacing otherwise inflexible applications. This is why in SOA circles we avoid using the term „application‟, which is often delivered as one big executable. Services offer greater organizational agility because they can easily be replaced without having to bring the whole house down. CRM Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 12 of 54 and ERP vendors are embracing Web Services and SOAs in the hope of improving the agility of their applications (and therefore the businesses that buy them). Determining Factors for selecting a Strategy IT Strategic Planning is influenced by a number of factors especially the goals and objectives of the organization, resource availability, costs and time of development and implementation such the costs of maintenance and development. Figure 1 IT Strategic Planning IT Strategic Planning is needed for the health, growth and the sustainability of the overall organization. To achieve this, a Governance process must be implemented. Governance is the structure and organization that is responsible for stimulating change and realigning IT work to the business objectives and mission. The Governance roles are:  To develop an IT Strategic Plan. A Strategic IT Plan realigns IT activities to those of the business organization, who in turns controls the Organizational or Business Strategic Plan. The plan is strategic in the sense that it is usually develop in the long-term and could take ten to 20 years to complete it. To establish the process for decision-making. The process for deciding what gets done, when and where is extremely important for guidance and for directing development activities within IT. To organize and coordinate IT activities. The structure and organization of Governance must be coordinated across the whole enterprise and must include the participation of CEOs and Upper Management. This is in recognition to the fact the “Organization is its Information Systems and vice-versa”. IT Planning Steps In Figure 211, the IT Planning function is illustrated as involving three essential high-level stages: 11 I modified the original diagram to fit the intended audience of this report. I unfortunately lost the original source document or book reference. I will produce a reference when and if I find it. Please forgive me. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 13 of 54 1. The Vision This is the goals and objectives usually stated in a visionary document that spells out what it will accomplish in the future. This vision is often expressed in the organization‟s mission or other visionary documents – like the Enterprise Strategic Plan – designed to inspire and align people. An Enterprise Architectural Plan (EAP) is likely to be distributed to all stakeholders at this stage. 2. Evaluation This stage occurs when the existing strategy is assessed against the new targets i.e. objectives and new requirements. 3. Implementation This is the step where the actual execution of the EAP takes place. A formal control process is put in place to organize and coordinate IT budget and other resources. Figure 2 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 14 of 54 The Theory of Service Orientation The purpose of this section is to explain the underlying principles involved in using services to build our information systems rather than the traditional approach of building applications. Service-Orientation is not really a new concept. Many IT pioneers and architects like John Zachman have made exhaustive references to principles such as reusability and standardization of IT components or parts. Many readers familiar with J2EE, .Net or Object-Oriented Programming (OOP) in general will find the principles of Service-Orientation very familiar (although services and objects are quite different in scope). In Service-Orientation, a service is a business function area that can easily be converted into a computerized “Service” (i.e. mostly a service built from information technology). The service forms the building blocks (i.e. architecture) to be reused across the whole Enterprise in building business applications. In modern or contemporary IT Shops, services are likely to take the form of Web Services. Yet, some organizations have been using Service-Orientation theory quite successfully since the 70‟s proving that Service-Orientation promotes application agility regardless of the technology platforms. If we program our applications using the newest technologies such as Web Services but are still doing it through traditional methods then it is nothing more that replacing or rewriting the application all over again (i.e. the endless cycles of re-writing applications). The enterprise that is constantly rewriting their monstrous apps produces competitive disadvantages because of the high costs and time to re-write, test and implement. In fact, they would most likely be better off to keep heritage applications built with Power Builder or COBOL. Services – as defined in this section – replaces the traditional word “application” with the word “services” instead. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 15 of 54 The Future of IT Development The future of IT development is at a crossroad and will drastically change in the next five to ten years or so. We will mass-produce reusable code, business functions and services through the use of technologies such as J2EE (or Java), .Net and Web Services. With the production of reusable services12 as a means to assemble our next-generation applications, we will no longer be building rigid and costly applications from scratch. SOA pundits (Agilists13 in particular) believe that the enterprise applications will eventually be built on the fly directly from the Business Analyst‟s desk instead of going through a never-ending costly development life-cycle. The task of creating or modify a business automated system will consist primarily in identifying the services in the business process and then knitting those services together with a communication medium that contain the rules of the business, usage and security. This is how one might picture the Business Analyst assembling an application in the future:  The Business Analyst (BA), armed with a strong understanding of the business needs (through high-level business models usually), will identify the services needed for the target business process. Those readily-available services will be easy to find by looking up a “Directory of Services”. Those services will be prebuilt for reusability and once created they will have an existence of their own – independent of whoever or whatever consumes them. This is what agility means – the ability to build an application on-demand so that the application re-aligns itself automatically (or almost) to the changing needs and nature of the enterprise. The BA might then create a “Bill of Services” (similar to a Purchase Order or a Functional Specification) containing things like the services, the business process and security rules. The Bill of Services would then be forwarded to the Service Provider(s) who is in charge of assembling the new application specification. The Service Provider could be your internal IT Shop (if you have one at the time) or it could be a competing external supplier of IT services. The assembly of those services will be made into a custom-made application that fits exactly the needs of the organization in a matter of minutes or even seconds. This assembly of services might not even involve any IT personnel at all. Creating business applications in a matter of minutes – as oppose to weeks and months – is what the agile enterprise of today needs. Principles of Service Orientation The idea behind Service-Orientation is the concept of using services as a means to build the enterprise (instead of the traditional monolithic application). This is no different from today‟s business designs where it is a common practice to emphasize “customer services” as a means to improve customer relations and therefore the business. Along those same lines, 12 Reusability (to achieve organizational agility) is one of the main goals of SOA. Reusability is great if and only if it can be achieved. Many services will not necessarily become „reusable‟ depending on the application. 13 A term used to refer to scholars who promote the Agile methods in building IT applications. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 16 of 54 Information Technology must be treated as a place where we offer services that clients (or other services) can consume. In Service-Orientation, applications are really composites of services that are consumed by other services rather than one big application that has everything programmed into one chunk. “Services” under the Service-Orientation Approach (SOA) must behave or adhere to specific characteristics otherwise Service-Orientation would not be possible at all. Thomas Erl, author of the highly acclaimed book entitled “Service-Oriented Architecture”14, explains those principles as:  Services are designed to be reusable (whenever possible) Services are loosely coupled Services are defined and discoverable (through the use of contracts and directories) Services abstract the underlying code i.e. SOA is a technology-agnostic architecture and/or language Services can be composed of other services (composability) Services are autonomous and stateless Note: From the view of business end-user, a service is synonymous to an office procedure within the business process. A procedure is a unit of work usually done by one worker (in a business responsibility area). The service, like the office procedure, is often capable of being reused in many other processes within the business. The business process is the logical flow of all those procedures (i.e. services) that go from one hand to another in the organization. A service is described in a language that is easy to understand by the business worker. The level of abstraction is closer to the natural business language than the object artifacts – for those familiar with OOP jargon. Reusability Reusability in IT has been around for a long time. When things are designed to be “reusable”, it means that we intend to make them into standards whenever possible. In IT, those standard parts (i.e. services) can be easily integrated to assemble (rather than built from scratch) many complex business systems. By reusing parts as oppose to building from scratch each time, the development time and costs of projects are drastically reduced over time. With those reusable services, an enterprise benefits from the economies of scale and improves its return on investments (ROI). As a general rule, services behave like any other type of reusable common business functions – for example most of the Human Resources functions, the Payroll, and other accounting services. The concept of reusable business services is a common practice in most (if not all) of our successful manufacturing firms. It is much cheaper to design a 14 This best selling book is considered one of the most significant works in the SOA field. It is a highly recommended for anyone involved in building SOAs. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 17 of 54 production line for multiple products than it is to design a production line for each product. Take for example Intel, the dominant microprocessor manufacturer, where it is very common practice to design silicon foundries (or chip lithography) to be reusable for many different types or class of integrated chips. For Intel, this represents a substantial competitive advantage given that a foundry requires hundreds of million dollars to setup. Discoverability Services must be easy to discover (to identify and access) if they are going to be used as standard parts in many applications. One way of making them “discoverable” is to make them accessible through a directory or repository so that developers and services can easily used them. This central repository of services contains information such as the terms of usage, the contract or the Service Level Agreement (SLA) and other critical information. This is where all the details – that tells the Business Analyst how to use the service – are stored. A contract might describe things like the structure of data information to be processed, the typical responses that will be given, the error handling and the security requirements. Loose Coupling Loosely coupled services are a fundamental and critical requirement leading to agile Service-Oriented environments. A service is said to be “loosely coupled” when its execution is not tied (i.e. locked) on a specific technology or when it is not hard coded with dependencies on underlying technologies or when its state is not dependent on the services that previously called it. The purpose of SOA services is to design a technology-agnostic platform that relates more to the natural abstraction of the business processes. Services must be designed in a manner as to eliminate any dependencies that might cause inflexibility towards change. This concept of being oblivious to the underlying technologies used to provide that service is in one of the greatest strengths of SOA. Loose Coupling (continued) Building tightly coupled services or applications is what makes your IT so rigid and costly to maintain. Typical examples of how we build inflexible tightly-coupled systems are:  Hard coding things like the location of the servers and databases Hard coding IP addresses or server names in the code Using back door methods for integration with other applications Hard coding the business rules and processes Purchasing and incorporating third party objects in our library of objects Tightly interfacing your applications with Office Suites or other technologies Abstraction The principle of abstraction is an indirect feature of building loosely couple autonomous services. It means that in order to use a service, the business Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 18 of 54 does not need to fret over the underlying programming code or technology that was actually used to program that service. The business side of the organization should not typically be concerned about how or what technology was used to build its services. What matters, is that the process be broken up into more manageable business services that can be easily be made into a business process. Abstraction means that the language used to describe an SOA process is the same natural language used by business executives. Service-Orientation is in fact an attempt at expressing the business process flow at a level (of abstraction) that the business executive can easily understand and relate with. In effect, this abstraction of the business is quite resilient to the underlying technology. By creating an IT on how the business sees its services literally puts the business in the “driving seat” when designing SOAs (instead of being driven by the relentless forces of technology changes). Composability The Wikipedia website defines composability as “a system design principle that deals with the inter-relationships of components. A highly composable system provides recombinant components that can be selected and assembled in various combinations to satisfy specific user requirements. The essential attributes that make a component composable are: 1) It is self-contained (i.e., it can be deployed independently -note that it may cooperate with other components at run-time, but dependent components are either replaceable.) 2) It is stateless (i.e., it treats each request as an independent transaction, unrelated to any previous request)15” Composability refers to the ability to assemble applications during runtime rather than through a one-time compilation step used in traditional methods. With composability, the components (i.e. services) are designed as standard pieces and can be combined in various ways to accommodate a business process on-the-fly. These components can be assembled during “runtime” to meet the requirements of a specific business process. A big advantage of composability is the fact that the entire application does not necessarily fail when one of its services fail. In this scenario, when a service fails, enough intelligence is programmed in the process to resolve errors and to execute alternate services. Flexibility and agility can be achieved by composing services that adjust automatically to the situation by picking and choosing alternate routes and acceptable services. For example, after purchasing an online item, a customer can pay the item by using any Credit Card services, PayPal or some other payment arrangements – all of which are alternate online means to pay for purchased items. Autonomous Services are said to be “autonomous” when they can function independently of other components or services. It means that they are self-governing or self-controlling and have total control over what goes on within the boundaries of 15 Retrieved from "http://en.wikipedia.org/wiki/Composability" Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 19 of 54 its function. As in the pre-computer age, where business work units functioned asynchronously and autonomously from each other, services too can be designed to function independently from other services. For example, in an Accounting system, a Journal can function independently of the General Ledger (GL). The accounting functions are more likely to function independently (exactly as services) and they do not need to be executed at the same time for the process to work (i.e. synchronously). Statelessness Most of our present-day applications keep track of information like the state or status of the application – things like the status of a previous transaction or user preferences. A service is easier to be reusable when it is designed so that it is not affected by anything or state that was done previously. This is a very familiar concept for OOP (Object-Oriented Programming) developers. From the SOA view, a stateless service is a service that, when invoked (i.e. consumed), do not maintain any state information. Within the SOA framework, there are methods to alleviate the burden of states through the implementation of special services to store and track the states and/or through the WS-Coordination16 specification. Technology-agnostic nature Service Orientation (SO) principles can be applied using just about any technology platform known. Service Orientation does not care about the technologies used to develop the services. In fact, services can be programmed with just about any modern technology without affecting the business mission, goals and objectives. The language of Services is likely to be easier to understand by the business community (than it is to techies) simply because it corresponds very closely to natural jargon of the business. Services are often expressed and represented by high-level business process diagrams already in use by business executives. Implement a SOA does not necessarily equate to re-writing existing heritage17 applications either. In fact, many of our heritage applications can be easily adapted as reusable services using technology readily available by a number of companies like BEA, IBM, Microsoft – just to name a few. Any applications regardless of the technology can be easily integrated and wrapped into services that can then be used to compose service-oriented applications. Business Services A service is a concept that the business is already quite familiar with. For the business, services are the equivalent of existing business responsibility areas or work units. Work units (or business services) are organized as independent business functions that can pretty much function on their own regardless of the state of other work units. Work units (i.e. services) are put together to form the enterprise. They each have specific objectives that are combined together in a 16 An Open Standard from the OASIS committee and developed by BEA, IBM and Microsoft. 17 Heritage is the term that replaces the word “legacy” in SOA jargon. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 20 of 54 process to achieve the synergic mission of the overall enterprise. The service is a concept defined at a coarser grained level, closer to the business abstraction level, than the finer granularity of objects used in present-day OOP technologies (as mentioned previously). Business services must also communicate between themselves through some means – usually through asynchronous messages. Before the dawn of the computer age, the enterprise communicated through paper memos, letters and especially through the use of business paper forms like invoices, purchase orders and more. Modern SOA applications work no differently. We use the electronic equivalent of the business paper forms – electronic asynchronous forms or messages (like XML with SOAP) – to share and collect corporate information amongst services. Types of service delivery Eric Newcomer and Greg Lomow18 describe the Service-Oriented Business into three categories:  Human-mediated delivery This type service involves people serving customers or citizens such as Call Centers, Service New Brunswick regional centers and salesman. Self-service delivery This type involves having the customer or the citizen to service themselves through the use of technology like the telephone and the Internet. Examples: Service New Brunswick Website, Connect NB kiosk, banking machines and Portals. System-to-system service delivery Type of service is used to interconnect entities or applications from departments and other businesses together. Good examples are Business-to-Business (eBusiness) and eGovernment applications. 18 This block was taken from the book “Understanding SOA with Web Services” by Newcomer and Lomow. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 21 of 54 Service-Orientation Components In the book, entitled “Enterprise SOA, Service-Oriented Architecture Best Practices”19, authors describe SOA as an environment consisting of: 1. The Application Front-end: the interface (e.g. the application screens) that provides the business functionality to the business users. 2. The Service Repository: the place (i.e. like a server or website) where services are easily discovered by developers and/or services and clients. This is a centralized area containing vital information regarding like the usage, rules and security information. Often this is done through an open standard called UDDI (Universal Description Discovery and Integration). 3. The Services: These are the business services available (e.g. Web Services) consisting of. o A contract (The description or specification on the usage and constraints of the service in question. This information is usually included in a document referred to as a Service Level Agreement (SLA). o The implementation (The business rules and logic and the data) o The interface (Describes how the clients and other services can interface or use this service.) 4. The Enterprise Service Bus (ESB): The ESB (a.k.a. the Service Bus) is an asynchronous communication layer or middleware composed of several components:  Transport and network transport protocols such as CORBA or SOAP. This also referred to as the messaging router or message-oriented middleware. A directory (to make services discoverable) such as UDDI (Universal Description Discovery and Integration), which holds information as described in the service contract or SLA. (Many architects are quick to point that the Enterprise Service Bus is not necessarily a mandatory element of elementary SOA. Services can still be composed using pure Web Services Architecture methods only. ) ** Figure 3 illustrates the components of the SOA model as proposed by the authors. 19 Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 22 of 54 Figure 3 Application versus Service An application under SOA is often referred to as Service-Oriented Application. It is an assembly of services put together in a façade during runtime execution of an automated process (composed of various services). When SOA methods are used, services are constructed to be reusable (whenever possible) so that they don‟t have to be re-written or re-developed for every new SO Application. SOA applications are never compiled into rigid applications. Rather, they are dynamically linked together during runtime, which means that they have the potential of being automatically realigned as the business process demands20 or changes. SOA services are assembled (into an application) on-the-fly during runtime and it is important that they adhere to the principles explained earlier. An SOA application is not something pre-compiled into a huge monolithic executable (like the traditional way of building apps) although the services themselves are usually compiled just like objects. Note: To eliminate the confusion between the word “application” and the word “service”, many authors have simply dropped the word “application” altogether and simply replaced it by the word “service” or “Web Service”. Examples of reusable services Here is a list of potential reusable services:  A telephone directory Calculate gross pay services Online MasterCard Transaction Services (and most other Cards) Client registration Word Processing 20 This is especially true when implementing a business process-centric SOA. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 23 of 54  Loan application entry Printing checks Inventory A Web store front (like eBay) A schedule of disbursement Etc. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 24 of 54 Open Standards Introduction The ultimate goal of a SOA is to have an agile IT environment unaffected by all the disparate technologies that might be used to develop its services. SOA pundits have long realized that the nature of most organizations is composed of heterogeneous computing environments because different business units perceive their needs differently from one another. Standardization of all programming objects into one proprietary technology defeats the ultimate aim of enterprise agility. Standardization should remove the locked chains of technology dependency. The “put all your eggs in the same basket” scenario must avoided or else reap the high risks and costs of being locked and controlled by external forces. To achieve this, SOA must be based on nothing else but Open Standards. Enterprises, just like any member of our society, must take steps to protect themselves against the threats of dependency. Open Standards level the playing fields and therefore vendors have no choice but to work in the best interest of its customers. Customers can pick and choose freely based on the quality of service and relations with vendors. Definition of a “Standard” In the general sense, a standard can be anything tangible or intangible that is recognized and administered by a standards organization (usually representing a given industry). Standards are developed with a genuine desire to cooperate for the overall benefit of the industry and its customers. Standards have true benefits like:  Reusability: Standards can be reused through the enterprise and will hopefully result in major economies of scale. Quality: Standards are a great tool to benchmark the quality of artifacts. Interoperability: Standards are developed through a cooperative group effort to resolve issues around the sharing and interoperability of their products. They offer a common language for defining interoperability and communications. Definition of a “Standard” (continued) Consumer Protection: Standards are often established to protect the consumer from poor quality and to motivate manufacturers to “measure up” to acceptable requirements. Using a true standard is often a good way to protect oneself from liability due to patents (e.g. Intellectual Property Rights or IPR). Patents are often used by firms to gain a competitive edge. When it comes to the case of open standards, the standards organization is likely to be the owner of the patents in question. Note: A proprietary technology could potentially progress to a true Open Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 25 of 54 Standard as in many cases like Sun’s Open Office file format. Open Standards defined Open Standards are regulated published standards governed by a recognized institution for the purpose of making it available to everyone in a given market sector. Those standards are available to the public at large as long as the implementation of those standards complies with the rules and regulations of the committee in charge. No one is allowed to modify the property without consent and approval by the standards committee. This therefore lessens the risks of those choosing to adopt the standards21. Standards are necessary to improve the compatibility of technologies of similar functionality. Without standards, the market could turn into a chaos and would possibly be dominated by a small number of dominant firms (or even a monopoly). The lack of standards could lead to serious flaws in areas of interoperability and information exchange (e.g. telecommunications). Open Standards are designed to level the playing fields so that technological progress can continue without being hindered by a few commercial entrenched firms. Open Standards remove the barriers to new potential entrants. They offer a fair, unbiased and ethical approach to eliminating costly and unnecessary incompatibilities and rivalries amongst products of similar functionality. Benefits of Open Standards Open Standards are critical for the success of IT in this day and age. This is especially true for the purpose of integration, inter-operability and communications. Open Standards offer real value and benefits:  Improved quality, interoperability and sharing: The benefits of Open Standards are quite dramatic when it comes to sharing of information and the integration of applications that are base on Open Standards. Reduction of development and research costs: Can substantially reduce the costs of developing applications based on those standards. There is no need to re-develop or spend dollars to research something that is readily available and open to everyone. Economies of scale: Drives the prices down because it increases the chances of new entrants in the market place. Vendors who implement open standards are very likely to differentiate their products based on value-added services and features. The underlying technologies remain fully compatible amongst each other as long as they are compliant with established standards. File Compatibility: It doesn‟t matter what brand software you decide to acquire because your documents are guaranteed to be fully compatible with everyone else‟s. There will be no more fear of the lack of compatibility with others. All the open standards brands will be compatible with each other. Vendor Independence: The Standards body in charge will control and 21 Understandably, dominant commercial firms can be vulnerable in the face of emerging open standards. To combat this, some have resorted to “predatory” practices where they initially “embrace” the standard and then release their own “extended” version of that standard. This practice has disastrous consequences for the standard. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 26 of 54 manage the compatibility issue between subsequent releases thereby reducing the risk of obsolescence. The body can develop the standards for backward compatibility for the purpose of preserving historical facts and formats. It makes it easy to switch from one vendor to another when the need arises.  Innovation: Open Standards can spark new innovations by opening the doors to potential entrants and new markets. The Internet is a perfect example of how innovation can be stimulated when technologies are not controlled or monopolized by a dominant firm. Well-known Standards Bodies The following organizations are well-known: W3C (World Wide Web Consortium, the governing body for our web standards.) IEEE (Institute of Electrical and Electronics Engineers, a committee developing standards for computers and electronics.) OASIS (Organization for the Advancement of Structured Information Standards, a consortium dedicated to developing e-business and web service standards especially SOA.) CSA (Canadian Standards Association) IETF (Internet Engineering Task Force) ISO (International Standards Organization) ATIS (Alliance for Telecommunications Industry Solutions) And, many more. Principles of Open Standards Open Standards are designed with the ideas that all technology should be accessible to every member of our society and that anyone choosing to use those standards should exercise some social responsibility. The main principles are: To maximize availability (Open for anyone to read and implement) To maximize user choices (By creating a fair and competitive market) To minimize or eliminate cost of acquisition (Open Standards are available for free to implement with no royalty and other fees). To eliminate discrimination (Open Standards favors all members of our society – not just the privileged) To let governing committee control and certify any extension or subset (The governing body must take steps to prevent „Predatory Practices‟ through licensing and agreements with vendors). Business Case for Open Standards In the article “Business Case for Open Standards22”, author Erik Sliman describes the benefits of Open Standards as: Reduction of overall risk Improved flexibility Improved durability of solutions 22 This was taken from the OpenStandards.net website. See http://www.openstandards.net/viewOSnet1C.jsp?showModuleName=businessCaseForOpenStandards Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 27 of 54  Improved quality Improved vendor independence and selection Decreased vendor costs Optimized interoperability and integration Improved reusability of processes Optimized communication Increased acceptance of solutions Increased Return on Investments (ROI) Well-known Open Standards Here is a short list of Open Standards examples: Hypertext Markup Language (HTML) WiFi or 803.11a/b/g (Wireless networking protocol from IEEE) X.509 standards for Public Key Infrastructure (from the IEFT) Web Services Architecture (from W3C) XML or “eXtensible Markup Language” from W3C OASIS OASIS (Organization for the Advancement of Structured Information Standards) is one of the most important non-profit organizations in the Web Services field promoting Open Standards in eBusiness. It was formed in 1993 by a group of well established firms like IBM, SUN, BEA, SAP, Microsoft and many others for the purpose establishing standards in business-to-business transactions. OASIS is continually helping to drive “Open Standards” by issuing very important standards and specifications identified by the “WS-*” prefix (example: WS-Security). More information on OASIS can found at the following website: www.oasis-open.org W3C’s XML Standard XML or the Extensible Markup Language is an Open Standard created by the W3C, the organization promoting the Internet founded in the 1960s. XML is a language (resembling the HTML language used to build Web Pages) that adds some elements of “intelligence” in forms, messages or documents exchanged via the Internet. XML is the standard foundation for all implementations of today‟s modern SOA initiatives. It is used in a multitude of information and data sharing applications. XML introduced two important standards: XSD (XML Schema Definition language) used for preserving the integrity and validity of messages XSLT (XSL Transformation Language) used for interoperability of dissimilar data sources through schema mapping XML is often used in combination with other Web-based messaging standards and protocols like SOAP (Service Oriented Access Protocol). SOAP is the transport mechanism that lets XML messages go from one Web Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 28 of 54 Service to another. XML has become the core technology of distributed Internet architecture and therefore SOA environments. W3C’s Web Services (i.e. Web Services Architecture) are so important nowadays – especially if an organization is intent on implementing a modern SOA environment, that a section of this report has been dedicated to it. Risks of Using Open Standards Open Standards are actually designed to lower consumer risks. The risks of adopting open standards are quite insignificant in comparison to proprietary commercial technologies. However, one might argue that, in many cases, standards are:  Slow to emerge: Adoption of Open Standards can be a long process. Standardization usually evolves when a given industry life-cycle has reached a certain maturity. Only then will the rivalry subside enough to allow for inter-operability. It is usually in that stage of maturity that standards are established. Market adoption can be slow: Adoption of standards is not guaranteed to go smoothly depending on the extent of rivalry amongst the vendors. The more dominant firms are often uncooperative or reluctant to comply because standards could negatively affect their profitability and viability. Organizations that study and publish standards are usually non-profit in nature and often do not have the necessary funds to adequately promote their standards fast enough to meet consumer demand. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 29 of 54 Web Services Architecture Introduction The SOA theory and approach has been around for almost ten years but was not taken seriously until the introduction of W3C‟s Web Services Architecture. Most of today‟s SOA implementations are based on the Web Services set of technologies. Technology-agnostic Open Standards form the basis of today‟s Web Services. Of all the technologies out there, Web Services is guaranteed to be easiest way to build an enterprise SOA. It is interesting to note that for most people, when we speak of the word “service”, we truly mean “Web Services” (although a service has really nothing to do with the choice of underlying technologies). For the remainder of this report, the word “service” will be used synonymously with “Web Services”. Web Service Explained One way to explain how Web Services works is to examine the evolution of the programming languages and their associated technologies. When the first Generation of high-level programming languages (i.e. procedural languages) were introduced – like Fortran, Basic and Cobol – we included procedures and functions that were chunks of programming code that could be reused inside a program that someone was developing. The only problem was that this procedure was only reusable inside a given program and could not be shared with other programs (i.e. they had to be rewritten each time). The code had no reusable structures outside the program itself. Later on, we came up with reusable programming code structures in languages such as Pascal and C. This is also known as modular programming. The developers were able to create programming code structures that were only reusable inside the program itself on top of the procedures already available. This was an improvement because it made it easier to understand what the developers were actually doing in their programs. Then, came the object oriented programming (OOP) languages like Java and Visual Basic where developers could share reusable code called objects. Those reusable objects were stored in a library inside the developer‟s toolkit so the developer didn‟t have to write them. Objects were artifacts like data grids, drop down menus, and many others. The objects were reusable amongst all the programs that were being developed by a developer. The problem however was that one program could be develop using those within the same organization but shareable with other incompatible OOP language being used. For example, objects designed for Power Builder could not be used with those of Visual Basic. To improve the sharing of computerized objects, Microsoft then invented the .Net framework where objects were stored on a central server (aka Application Server) and developers could call any of those objects into their programs regardless of the programming language used (as long as they were .Net compliant). This was quite a revolutionary way of building apps because Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 30 of 54 instead of executing all the objects inside one computer we could actually execute an object on separate computer (i.e. Application server) inside the confines of the network wall. This also added the advantage of using standardized objects to build applications. Then, in the 90s, the World Wide Web Consortium (W3C) introduced a set of Internet technologies to make improve the sharing of information and data between organizations and individuals – HTML Web Pages and XML for examples. Using those Open standards, people could now write code that resided on a computer anywhere on the planet as long as it could speak the language of the Internet. This meant that a developer could now call (inside his/her program) objects or procedures that could be stored on a server anywhere on the Globe. Objects no longer had to reside within the confines of a private network. This essentially describes the underlying concept of a Web Services i.e. that it is nothing more than an object, a procedure or a collection of objects and programming code that resides anywhere on the Internet and that the developer can use in his/her program (just like the local procedures or objects). The only difference between an object and a service at this stage is that the service is often at a coarser grain – meaning that they do more work on a single invocation than a simple object would. Languages Reusability of Programming Code How does the reusable parts exchange data? Procedural Languages Programming code is reusable to limited extent within the program through the procedures. The compiled program is executed inside one computer. Everything communicates synchronously inside the electronic bits & bytes of the machine. Program is coupled to the computer. Structured Languages Programming code is made reusable through code structures and procedures. The compiled program is executed inside one computer. Everything communicates synchronously inside the electronic bits & bytes of the machine. Program is coupled to the computer. Object Oriented Programming (OOP) Code is made reusable through objects stored in a personal programmer‟s toolkit. Objects can be reused under the control of one programmer. Objects must reside in the computer that executes them. Objects are assembled synchronously through the electronic brain of the computer. Program is coupled to the computer. .Net or J2EE Objects are stored and served through an Application Server inside a private local network. The presentation layer (what the user sees) is executed in the user‟s computer or on a Web Server in the case of a Web Application. However, the objects are called to and from the Application Server using a synchronous network protocol like RPC or HTTP. Object is decoupled from the desktop computer but coupled (still dependent) to the location of the Application Server. Web Services (XML & SOAP) Objects or services can be stored and served on any server connected to the Internet regardless of location. Anyone can use a Web Service as part Services communicate with other services or Web Apps through asynchronous XML messages and SOAP (as the delivery mechanism). The service is completely Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 31 of 54 of their application in as long as they adhere to its contract and Service Level Agreement. decoupled form the location (i.e. where it is executed). Services usually perform much more work than the fine-grained objects (and that is why the service is easier grasp than the object by the business). The Mechanics of Web Services How does a Web Service or Web Application call or execute a Web Service? The answer to that question can be explained through this diagram: 1. The Web Service Provider is the people responsible for publishing their service on the Web through the use of a WSDL (the XML document that describes how to use the service) 2. The WSDL is published on a repository – called the UDDI – to make it easy for other developers to discover the service so that they can use in their application. 3. A Service Consumer (i.e. a developer building a Web service or a Web App) consults the UDDI for a published service. When the service is found, the UDDI provides the consumer with the WSDL document. 4. From the WSDL, an XML document is created and sent via SOAP to the Web Service. This document contains the data information accepted by the Web Service. 5. The Web Service responds by sending the results using XML on SOAP back to the consumer. The Standards of Web Services Web Services are founded on a number of open standards and specifications. The most important of these being:  WSDL (Web Services Description Language) UDDI (Universal Description, Discovery and Integration) XML (eXtensible Markup Language) SOAP (Simple Object Access Protocol) Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 32 of 54 WSDL WSDL 23(Web Services Description Language) is the Web language used to describe how a service will be access through the Internet. This standard contains the information that is needed by developers (or other services and consumers) to link to and execute the Web Service of interest. The WSDL is written in the XML language and takes the form of a contract or document describing how the Web Service is to be handled like the input parameters and output results. The WSDL can be access through a repository also known as UDDI, which contains all the services available to the developers. WSDL are service descriptions implemented on a server that uses the UDDI (Universal Description, Discovery and Integration) standard. UDDI is a directory has the benefit of centralizing the service descriptions and therefore making it easy to discover them. (The reader might recall from the previous section on “Services” that discoverability is an essentially concept of SOA.) UDDI UDDI is an acronym for “Universal Description, Discovery and Integration”, which is essentially a directory/repository service that makes it easy for consumers or developers to find published services. UDDI adds a layer that separates the services‟ location and technology of the service providers (those that are responsible for maintaining the service) and the consumers of those services. UDDI provides a means to easily discover the enterprise services. It acts as an intermediary between the consumer and the service provider. Once a service has been identified for consumption, it is the role of UDDI to invoke the appropriate service for the consumer or calling service. This directory allows easy access to services by other services, applications or consumers. Services listed have a description (i.e. WSDL) with important information on how to use and access them. A service description might contain things such as the XML protocols, the type of data, location and many other rules. XML XML or “eXtensible Markup Language” is the most crucial W3C Open Standard medium. It resembles the HTML language (used to make Internet web pages). It is a formatting language designed to make it easy to read and exchange data information between machines (as well as humans). XML represents the core technology that enables disparate technologies to integrate and exchange information. XML documents are used for the express purpose of exchanging information between Web Services. XML documents are likely to be transmitted via a network protocol called SOAP, which is essentially a messaging technology (or they can be transmitted through FTP, SMTP or HTTP just like any electronic like a Word doc can). 23 WSDL was developed by IBM and Microsoft to provide a way for individuals and other businesses to access services electronically. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 33 of 54 XML and SOAP are often implemented through the use of a router or server (i.e. the XML Router) and is the fundamental communication device of Web Services. The XML message is a business form or document (like a Word document) that can take the form of an invoice, an application form, a contract, and etc. XML docs are readable by both humans and computers alike. This document will often contain data information such as the business rules, business data, error handling instructions and security rules. XML documents can easily be converted into HTML, PDF and other types such as word processing (like MS Word or Open Office docs for example). The SOAP protocol is an envelope or the transport mechanism that wraps the XML document just like a paper envelope wraps your mail at the Post Office. Most of today‟s organizations implementing SOA use a special technology layer called the Enterprise Service Bus (ESB). The ESB is designed to make “integration” so much easier in SOA environments. By connecting to the ESB, it is a fairly easy game to share and exchange information amongst SOA-enabled legacy applications and other services in the organization. SOAP SOAP (Simple Object Access Protocol) is the transport mechanism that is used to deliver XML messages, back and forth, to Web Services. It is a protocol consisting of three parts:  An envelope that defines a framework for describing what‟s in the message Instructions on how to process the message Rules for expressing instances of application-specific data information. In today‟s SOA, XML represents the “message” while SOAP is the means to transport that message across the network to its destinations. SOAP can be pictured as a courier service such as Purolator delivering packages to their destined customers. To assure a prompt and quality service, Purolator packages have stickers on them to tell the driver where to find the customer (i.e. customer address) and how to handle the package like “handle with care”, “breakable items” and more. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 34 of 54 Service-Oriented Architecture Introduction Those who have a good understanding of Web Services or who have actually created Web Services will greatly appreciate the SOA approach. In fact, is you can build a Web Service, then you are already quite skilled in going to the next step – that is to call a number of Web Services together into a Web Application or to orchestrate the Web Services together on-the-fly very much like eBay or Amazon does. Under the SOA approach, you use Web Services to build an enterprise application instead of objects. A Service performs much more work when it is invoked than an object does – although an object could very well become a service. For example, let us consider creating a simple object or procedure that calculates the tax owed from the purchase of an item: Total Price = Item Price * 0.12 Using XML and SOAP, the developer would send the Item Price to the Web Service and the Web Service would return the result back to the developer (i.e. the consumer) with the results. If we had 10 items to process, we would have to call the Web Service 10 times. This illustrates one of the problems with OOP – that while the 10 transactions are being calculated it is also creating a lot of network traffic which could eventually bring it down to its knees. Now, let us expand this example a little further and imagine that the organization has all kinds of situations where invoices and purchase orders and probably others are being used in a wide scale. This type of procedure is probably easy to standardize so that developers don‟t have to rewrite it each time. So, instead of using the simple object above, what if we could duplicate the procedure to do more work instead and to lower the traffic back and forth? The truth is that we could indeed build this procedure into a service that would do all this work in one invocation by simply sending the series of items, their prices, the quantity and maybe the Tax rate to be applied. This is one of the underlying concepts of the SOA approach. Of course, there is much more to SOA than what was illustrated above. But, it does introduce a couple of important concepts that are simple enough to be understood by anyone. The use of reusable Web Services to build the enterprise brings another important concept – the one where we strive to build agility to the enterprise. To build agile applications, the organization must abolish the idea of building big monolithic applications (i.e. the traditional systems approach). The days when we spend weeks, months and even years to develop IT solutions or applications24 will have to change to something more proactive. The enterprise can only become agile through the use of plug-compatible services 24 The word „application‟ refers to the monstrous hard-coded computer systems of the traditional IT shops. The word „application‟ is deliberately avoided by many SOA authors. From the SOA perspective, we only have one application, which is the enterprise and its services that make it happen. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 35 of 54 that can be easily replaced, substituted, removed, modified and reused as the organizational requirements change over time. It is interesting to note that in SOA, the Enterprise can take the role of a true “virtual” organization where the physical location, names, technologies and other locking mechanisms are not longer dictating the overall structure of the organization (i.e. the concepts of “loosely coupled” and technology-agnostic). Definition Service-Oriented Architecture (SOA) is an approach (e.g. strategy or paradigm) where reusable business services (that form the enterprise) are assembled together during runtime (as the need to do so occur). The business organization can be built on re-usable technology-agnostic services using services either built internally through the IT Shop or through external service providers. SOA is a vendor and technology-agnostic approach that endorses Open Standards allowing otherwise dissimilar technologies to become fully interoperable. The SOA approach is fully compatible with any existing methodologies and Governance or Enterprise-Wide Architecture plan in place. The difference is that we concentrate more on the coarser grained business services rather than at the finer grained programming objects and procedures. It is a business-driven approach guaranteed to bring organizational agility (when implemented through some Governance). Modern or Contemporary SOA Thomas Erl, author of Service-Oriented Architecture (2005) offers this definition: Contemporary SOA25 is a form of technology architecture that adheres to the principles of service –orientation. When realized through Web Services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise. (Those principles are discussed throughout this report.) Newcomer and Lomow According to Newcomer and Lomow, authors of a best selling book entitled “Understanding SOA with Web Services”, a service is defined at a higher level of abstraction than an object (for those who are familiar with object-oriented programming or OOP). A service is a coarse-grained interface that accepts more data in a single invocation than an object because of the need to map to an execution (business) environment. This definition means that a service sits on top of the application server layer (such as J2EE, .NET or LAMP) and is much closer to the conventional definition of a business service. Other definitions of services (from a Service-Orientation context) have been suggested :  A service behaves as a commodity so that it becomes easy to swap it in assembling applications. In a home stereo system, for example, a 25 Thomas Erl explains that a SOA can be implemented regardless of underlying technologies (i.e. primitive definition). But, when Web Services are used, it evolves into a Contemporary SOA. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 36 of 54 particular component can easily be swapped by another brand. Services are the equivalent of those stereo components.  A service is a business artifact easily depicted in a high-level process of the business. It should be constructed so that it is re-usable across the Enterprise26 (whenever it can be reused). A service is some part of an organization that produces something of value for a consumer. In IT, a service is likely to be the form of a computer program that returns information to the requestor of that service (i.e. another service). (In modern or Contemporary SOAs, the word “service” is really means “Web Services”.) Service-Oriented Architecture Service-Oriented Architecture using Web Services can be defined using this somewhat sophisticated diagram: This diagram is explained in more details at http://www.service-architecture.com/a website dedicated in promoting SOA and in the book “Web Services and Service-Oriented Architectures – The savvy manager’s 26 It is important to note that as a rule, Service Orientation promotes the reusability of services. However, it is recognized that some services are very difficult to be made into reusable services. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 37 of 54 guide” by Douglas K. Barry, Morgan Kaufmann Publishers, 2003. There are a lot of resources available on the internet that makes use of this illustration. The reader should read more about it. Example of a Simplified Point of Sale process In this section, the idea of SOA will be illustrated using the example of a simplified Point-of-Sale business process. The reader should keep in mind that the example is for the purpose of illustrating the concept of services and SOA only. The example starts with a Point-of-Sale scenario where a retailer sells items (books for example) to customers. Let‟s say a consumer comes in and wants to buy a book. The customer must interact with the bookstore Sales Clerk to complete the sales transaction. The Sales Clerk must first check the inventory to make sure that the item is available. If that item is available then the Sales Clerk proceeds to complete the transaction. If the item is not available then the Sales Clerk must order more of that item. The Business Process for Sales The business process for the sales of an item might look something like this: Note that the diagram contains a number of procedures (or services rather) that represent the business workflow logic. The process diagrams are used extensively for describing business workflows. The Process-enabled SOA We can re-illustrated the process to show how business forms or XML documents could be used to communicate between entities (i.e. services) such as: The idea in process-enabled SOA is to reflect the true nature of the business process and the services that compose it. In an SOA, the applications and services are in harmony with the natural workflow. The architecture is much more understandable and more representative of how the business really works. It also illustrates the underlying concept of re-using business documents (i.e. XML) to connect business units together instead of hard-coding all of the rules, processes and databases in one big chunk (like the Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 38 of 54 traditional method of building apps). Using messages or documents in the form of XML on SOAP illustrates some of the real benefits of SOA:  The XML message is the transaction containing the business rules and all other things such as security and the handling of errors. XML messages are continuously stored and updated as they move through the business process. The XML form is indeed an audit trail document recording all the transactions. Great payoffs for quality and auditing requirements. XML documents or messages forms the basis of the middleware layer in SOA and solves the puzzle of inter-operability and integration. XML documents are transmitted asynchronously to take advantage of the broadband networks of today and to preserve all the characteristics of a service i.e. loosely coupled, statelessness, and autonomous. XML transactions can easily be managed centrally through a Server or Router – the idea of having an Enterprise Service Bus (ESB). The Enterprise before the Computer The SOA approach is like going back to where we started to the times before the computer was invented. Before the advent of those machines, efficient enterprises were designed using very simple and rational architecture. The rough diagram below depicts a generic enterprise with many divisions as it might have looked like before the computer age. Characteristics of the enterprise before the computer The pre-computer age enterprise had the following characteristics: Every function is a specialized work unit, division or responsibility center of the business process (examples: Accounts Payable, Sales, Inventory, etc). The work units are somewhat independent of each other and can work without affecting the state of the other units. This is what we have defined earlier as “statelessness” under the definition of service. A function performs services or work for the overall business enterprise. This is another principle of service orientation. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 39 of 54  A function could be re-usable in many instances. For examples: the Sales function, an assembly line, a store front, credit department, and many others. Reusability is an ideal target whenever possible. Business functions communicate amongst themselves using standard business forms and other documents such as mail, faxes and the telephone (the technologies). This corresponds to the concept of using XML documents to link services together. The rules of the business are actually printed on the forms or documents (a neat way to learn about them). Example, an invoice would have the terms of payments, interest rates and other rules. XML is a very sophisticated vehicle to program all the business rules, policies and error handling. The documents are the vehicle for collecting and recording critical business information. In SOA, XML can record all critical information and actions taken during the process. Organizational design is very simple and is asynchronous27 in nature (depicted by the “Doc” in between the two linkages). Business restructuring exercises should not pose a problem because of the simplicity of this service design. In legacy applications, all business rules and functions are hard coded and therefore organization re-structures can fail because we cannot easily split today‟s rigid applications. Enterprise using the traditional approach The figure below attempts to illustrate the today‟s Enterprise that has a centralized IT Shop through the use of traditional methods in building applications. 27 Asynchronous means that we have a natural delay caused by the time it takes to create and then to expedite the business form or document. On the other hand, synchronous links are interactive instantaneous (real time) communications. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 40 of 54 Flaws with the traditional approach From the figure above, it is interesting to note the following:  The business functions have become “discontinuous” because the information does not naturally flow from one function to another function as it should. The monolithic application has programmed (i.e. hard coded) everything conceivable and has created inflexibility, confusion and a maintenance horror. The screens are usually the only things that separate one function from another. Often, different players from distinct work units are even forced to work within the same screens, which effectively blurs the natural boundaries between business work units. Many of the old communication tools such as the paper business forms and paper trails have been eliminated – perhaps to conserve paper. Yet, the elimination of the business forms has had consequences such as the lost of audit trails and the proof of transactions. Tangible paper and documents have been replaced by intangible real-time synchronous electronic communication links. The business logic and rules are hidden and hard coded into complex computer programming code. We built rigid applications based on the assumption that the business requirements and processes would never change. The reality however is that the business rules and processes are in constant evolution. Applications were likely built by different teams at different times with different technologies using different methods and approaches. This created the disintegration of the enterprise. In an attempt to make applications “talk” to each other (i.e. integration), developers had to employed a number of techniques that increased the unreliability and the cycles of development, maintenance and re-testing. This resulted in a costly explosion of maintenance effort. Improving the Enterprise with SOA With the introduction of the SOA, the Enterprise can eliminate many of the problems mentioned above through: The XML document (e.g. the business forms) can be used to communicate data information between work units or services (along a given process). They behave exactly like the business forms of the old days. The asynchronous nature of communications and interaction between the different work units of the enterprise will restore the natural flow and audit trails of information between business services. The business transaction is handled through the XML doc and all auditing and tracking information are added and recorded on that document. This is the enterprise‟s audit trail. The SOA model has also restored synchronicity28 into the enterprise. Today‟s Web-based applications like instant messengers, email and popular Websites like eBay and Amazon are all asynchronous in 28 In networking, synchronous applications are ideal for situations where we have point-to-point direct connections. Asynchronous applications are ideal in “multi-hop” situations like in the WWW universe (Internet) where data travels via multiple points or routers – ideal for SOA. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 41 of 54 nature i.e. they do not involve real-time direct connections to anything. But, because of today‟s high speed network lines, one gets the impression that things occur interactively in real-time. The distinction between asynchronous and synchronous communications becomes less obvious as the speed of hardware and telecommunications increases.  There is still a role for IT in SOA-enabled organizations. But that role has changed somewhat. IT Shops will be competing more than ever with Commercial Off-the-Shelves services – especially if those services are SOA-enabled and “plug-compatible” with the Enterprise Service Bus (ESB). When a service fails or is no longer preferred, the enterprise only needs to replace it by another service of similar function. The re-testing of everything for every new release becomes a thing of the pass since each service is a separate, stateless and autonomous service backed up by the contract and the Service Level Agreement (SLA). When a service fails, the other services will still remain fully operational unaffected by the failure of one service. A problematic service doesn‟t have to bring the whole organization or business function to its knees (like the traditional monolithic application of today). The business form reappears in the SOA model in the form of an electronic file or message via XML. This new electronic document is as easily read by a person as it is for a computer. Centralized Security Management: The XML documents are centrally and securely routed through the ESB or the routers. Security appliances can be added to audit all the security requirements of the enterprise. Generic use of the word Service The generic use of the word “service” in business jargon is used to describe a business work unit that serves customers with intangible benefits and qualities (that are of value to the paying customers). A service is therefore the non-material equivalent of a good. It is an activity where the consumer does not receive anything tangible (no object is actually received) but does receive some intrinsic benefits and satisfaction of having been served. A service is intangible work that creates intrinsic value for the consumer by facilitating a change in customer relations, a change in their physical possessions, or a change in their intangible assets29. Examples of Service-based enterprises: Government services in general (see Services NB) Educational institutions like schools, colleges and online universities Knowledge-based industry like consultants and Call Centers. Hospitality and Tourism sectors like Provincial Parks and hotels 29 Definition was taken from “en.wikipedia.org”. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 42 of 54 Elementary SOA Model with ESB The Service-Oriented Approach is based on the concept that services interact amongst themselves in an asynchronous fashion. Services are closer to the real business layer than mere programming objects such as in .Net and J2EE (or any technologies). The Enterprise Service Bus is the layer that orchestrates the services. This can be illustrated in the following diagram: SOA Block Model As explained in previous sections, the SOA model is the asynchronous interaction of services using XML documents as the means to transport data information. The simplest representation of two services interacting looks like this: Figure 4 Special note:  A service can act as either the Provider or the Requestor (consumer) or even both. The XML Server is a message-oriented middleware (MOM) that works like the familiar “instant” messaging service MS Messenger. The difference is that this layer has some intelligence – they can read, route and control XML messages just like people can. MOM is an Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 43 of 54 asynchronous service that relies on a queue to process XML/SOAP messages. SOA definition of Service According to Newcomer and Lomow, authors of a best selling book entitled “Understanding SOA with Web Services”, a service is defined at a higher level of abstraction than an object (for those who are familiar with object-oriented programming or OOP). A service is a coarse-grained interface that accepts more data in a single invocation than an object because of the need to map to an execution (business) environment. This definition means that a service sits on top of the application server layer (such as J2EE, .NET or LAMP) and is much closer to the conventional definition of a business service. Other definitions of services (from a Service-Orientation context) have been suggested :  A service behaves as a commodity so that it becomes easy to swap it in assembling applications. In a home stereo system, for example, a particular component can easily be swapped by another brand. Services are the equivalent of those stereo components. A service is a business artifact easily depicted in a high-level process of the business. It should be constructed so that it is re-usable across the Enterprise30 (whenever it can be reused). A service is some part of an organization that produces something of value for a consumer. In IT, a service is likely to be the form of a computer program that returns information to the requestor of that service (i.e. another service). (In modern or Contemporary SOAs, the word “service” is really means “Web Services”.) 30 It is important to note that as a rule, Service Orientation promotes the reusability of services. However, it is recognized that some services are very difficult to be made into reusable services. Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 44 of 54 The Business Case for SOA Introduction This section examines the benefits in implementing a Service-Oriented Architecture and to expose any potential risks. The cost of setting up this type of environment depends largely on the ability to adapt and learn new ways of assembling services together and the money saved by reorganizing and improving IT as a whole. To lower the risks (and therefore the costs), most experts encourage a phased evolutionary strategy. Organizations interested in leaping forward can easily take advantage of the experience and services that are already being implemented in pioneering institutions. Benefits SOA offers plenty of new opportunities and benefits for the organization especially:  Reusability and the Assembly-line approach. Applications are transformed into reusable recyclable assets. Using ready-made reusable services (instead of building applications from scratch) will produce economies of scale. This is an approach where applications are composed (assembled) using standard parts (the services). Improved mobility. By using Web/Internet technology to deliver services also means that mobile users can access their services anywhere (globally) anytime. The efficiency of the development life-cycle (i.e. decreasing the time to market). SOA simplifies the development of the enterprise application and lowers the reliance on IT development in the long run. SOA development concentrates on agile services that do not have to be redone and re-tested every time there is a new business process to automate. Interoperability and improved information sharing. Disintegration is a thing of the pass. Reduced IT infrastructure investments in the long term. This is a result of not having to rebuild the applications and therefore the enterprise needlessly. As the technology landscape continues to evolve, the SOA infrastructure and business processes will remain unaffected and agile. This implies a competitive advantage for an SOA-enabled organization. Short-term payoffs: SOA incorporates many ways to breathe new life into existing heritage applications. These applications can use adapters to create services that are plug-and-play compatible with the ESB (Enterprise Service Bus). This method is guaranteed early ROI. The CRM and ERP vendors (like ORACLE, SAP and more) are now in a race to decompose their flagship products into SOA-enabled services. The SOA approach can co-exist with existing SDLC (System Development Life Cycle) methodologies already in place. SOA is an approach and not a methodology. Reduced dependency on technology vendors. Disparate technologies Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 45 of 54 (like J2EE and .Net) can coexist seamlessly and can remain viable under the SOA. SOAs are extremely efficient at disabling vendor-locking strategies. More about Benefits In the book, “Enterprise SOA, Service-Orients Architecture Best Practices”, authors31 have classified the benefits as follows: 1. Improved Agility 2. Business Costs Savings 3. IT Costs Savings 4. Reusability 5. Technology Independence 6. Improved Organizational Infrastructure 7. Efficient Development Process 8. Evolutionary Approach Costs and Benefits In the second section of this report entitled “Present IT Situation”, we highlighted some of the problems encountered with the traditional approach. But, how does SOA offset those issues? The following table presents some answers. Traditional Approach SOA Solution and Benefits Costs Factors Inflexibility of applications We eliminate the inflexibility of applications. We assemble services on-the-fly instead therefore creating the ideal agile enterprise. Agility means efficiency of business operations. Agility reduces the costs of redevelopment and retesting. Inability to deliver on time and on budget. When something needs to be upgraded (very often), the whole application must be tweaked. If something goes wrong, the whole application goes down. The whole app goes through a cycle of re-development and re-testing. SOA uses “services” that are supported autonomously and separate from each other – the divide and conquer analogy applies here. When a service needs some tweaking, only that service needs to be maintained. The other services do not go down and still function normally. Only the affected service goes through the cycle of re-development and re-testing. Maintenance of services can represent a substantial cost saving measure. Let‟s say, if an application can be replaced by 10 services, over time, the organization could make costs savings by a factor of 10. Example, if a traditional application has a maintenance cost of $100,000 yearly then we could save up to $90,000 yearly under a SOA because we use less development time and resources. Traditional applications cannot realign to changing business objectives. Process-enable SOA environments are designed specifically to change with the business. Processes and rules are never hard coded. It is the task of the ESB to orchestrate the business process and rules. Well designed services never need fixing because a business process has changed. The savings here is enormous because all we have to do is change the business process, which is not hard-coded. It is nothing more that resetting the rules (on the XML documents) to reflect the process change. Security, privacy and confidentiality are issues that affect every aspect of the organization. Many tools exist to help counter the The issues of security are the same as other approaches. SOA can help by centralizing all XML documents through the ESB. The ESB can be As with any approach, the cost of security nowadays is a serious matter. The ability to centralize security could save headaches and 31 Dirk Krafzig, Karl Banke and Dirk Slama, Prentice-Hall, 2005 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 46 of 54 threats. retrofitted with security devices where all transmissions are forced to go through the ESB. There is no back door access to data and services allowed. Make sure you do your security risks assessments! therefore costly accidents. Integration and Interoperability is next-to-impossible. It requires enormous resources to achieve. It is estimated that 80% of all maintenance costs is directly attributable to integration problems. To solve this problem, many organizations have implemented Data Warehouses. SOA solves this dilemma once and for all. Integration is one of the main reasons why we build services in the first place thanks to Open Standards such as XML/SOAP. The integration costs is completely eliminated when the enterprise is built on nothing but services. It is a non-issue under SOA. Locking mechanism of the technologies SOA is built around Open Standards to eliminate the locking and dependencies on proprietary technologies. OA levels the playing field for everyone. Different technology platforms now have a means to exchange information and integrate. The inability of proprietary technologies to coexist is a serious matter in traditional shops. The use of Open Standards opens the door for vendors to compete on price and value (instead of locking their customers). The difficulties of applications to coexist with CRM and ERP COTS. Under the SOA approach, all services, applications and COTS must be designed to be plug compatible with the ESB. There is no longer an issue to acquire a COTS application in as long as it is pluggable to the infrastructure in place. Under SOA, we can purchase plug-compatible services from outside sources. This could represent a substantial cost saving measure. IT drives the solution instead of the business. Business-driven solution because services are designed to reflect the real business unlike the traditional application. A technology change often means a lengthy and costly exercise of redevelopment. Often, migration means rewriting the whole application. Under SOA, technology changes are still a fact of life. The advantage however is that services are designed so that the business does not have to be weary about the underlying technology. In most cases, services are managed by independent teams and it is the responsibility of that team to meet the obligations of the service contract and Service Level Agreement. When the service is upgraded to a new technology, the business is often not aware nor needs to be. Technology changes costs money no matter what. Using outsourced services however relieves the business of these headaches. When an application goes down the whole business process goes down with it. Down Times of traditional applications is a great concern to Systems Managers. SOA is organized into many independent services rather than one big application. When a service goes down the remaining services remain functional. In fact, it is common practice in SOA environments to have alternate services available when a service is not available. This means that down times can be virtually eliminated. Down times of applications are very costly because many employees from many work units depend on it to do their jobs. With SOA the only people affected are the ones associated to the unavailable service. But, if the SOA is implemented with contingent services then this becomes a non-issue. The traditional IT shop does have any Strategic Enterprise-Wide Architectural Plans or Governance. (Because if they did they wouldn‟t build their monstrous applications!) SOA is often used as the Strategic Architectural Plans of the enterprise. The Services and Objects become the essential standard building blocks to build upon. Strategically, SOA represents substantial cost savings for the organization. The services are the standard reusable blocks. The organization will reap the Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 47 of 54 economies of scale in using services. Risks and Potential Downfalls SOA also has a number of potential risks to overcome:  Resistance to change ways of doing things – the beast wants to preserve itself. “Internal Experts” are likely to discredit any attempts in changing the IT organization and structure. Expectations and change must be well managed through Governance and sound Change Management practices. IT funding and procurement could become an issue especially if the IT infrastructure needs revamping. To lower the costs, organizations will rather use a phased approach to implement SOA. The ESB, for example, may not be a high priority in the very early phases because the IT shop will have to learn how to build Web Services first. Once Web Services have been mastered then the next step is probably to start thinking about managing services through a centralized ESB. Inadequate Project Management practices like weak business requirements, the lack of models, specifications, planning, estimations, and insufficient senior management support (which is why Governance is extremely important for an Enterprise-wide solution). IT experience and know-how. The move towards SOA represents quite a steep learning curve for those not familiar with the technologies of Web Services. Proper change management plans are important at this stage and should include training, coaching and incentives. The benefits of Web Services are also attached with the issues of security. Security risk analysis cannot be overlooked. Organizations will have to officially monitor risks and QA initiatives. Dealing with the possibility of “analysis paralysis”. Analysis can be a big stumbling block if not properly managed. In SOA, the use of pre-existing analytical models like the organization‟s Strategic Information Plans, UML or Agile models can help greatly. To aid in the coordination and design of services, the OASIS organization has released the Business Process Execution Language aka BPEL. Effective Asset Management is necessary. A Governance structure or an SOA Board should be created where responsible decision-makers can sit together and prioritize development efforts. SOA Security Vulnerabilities Modern SOAs using Web Services will introduce a number of security vulnerabilities or threats32. Some of which are identified as: Message Intercepts (XML messages traveling between two parties can be intercepted during transit. ) 32 “Understanding SOA with Web Services”, Newcomer & Lomow, Addison-Wesley, 2004 Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 48 of 54  Intermediaries (Intermediate equipment like routers in the middle of a stream could be used to intercept messages and sensitive data.) Spoofing (Attackers could assume the identity of a trusted party to relay messages and obtain classified data.) Denial-of-service Attacks (A previously transmitted message could be resent continuously by an attacker to overload a service and to bring it down.) Replay Attacks (An attacker could replay a message to obtain confidential information on the response obtained from the unsuspecting service.) Repudiation (Repudiation is the process of rejection or renunciation of a duty or obligation -usually arising from a disputed transaction.) Data Privacy breaches Weak application code (This is in reference to bad programming practices, for example, the lack of error handling and validation code.) Unauthorized Access to data and/or applications Viruses, Trojans, and more (It is extremely important for an organization to implement some kind of Governance that will oversee: Risk Assessment Security Assessments Standardization Change Management Prioritization of projects ) Counter-measures against threats Many or most of the security issues around SOA are no more alarming as those identified for Web Services where many or most of the security issues are already well understood. A number of security products and standards are being introduced (or about to be introduced) as we speak to manage and centralize security in a SOA environment. Here is a list of counter-measures to guard against potential threats: Encryption of communication devices (like XML body and network links) Authentication procedures Performing regular systems audits and QAs Training of technical support staff and the developers Establishing security systems policies and procedures Digital and electronic signatures Procedures that require audit trails for transactions Assessing the security level privileges of staff Writing safeguards during development through validation and proper error handling *The counter-measures to be used depend largely on the threats or vulnerabilities that we need to guard against. These threats and vulnerabilities are mostly identified through the exercise of performing a Using the Service-Oriented Approach for Building Information Technology Guy LeBlanc Page 49 of 54 Security Risk Analysis. Security Layers Security attacks can occur at different level of a modern IT application. In Web Services, we can identify three main layers: 1. Network Transport Layer (The technical network layer that deal with things like low-level TCP/IP protocols, routers, VPN, firewalls and encryption.) 2. Application Security Layer (The application development area dealing with the integrity and confi