Service-Oriented Architecture (SOA) is attracting a lot of buzz from every realm of the IT industry. Propelled by standards-based technologies like XML, web services, and SOAP, SOA is quickly moving from pilot projects to mainstream applications critical to business operations. One of the key standards accelerating the adoption of SOA is Business Process Execution Language for web services (BPEL). BPEL was created to address the requirements of composition of web services in a service-oriented environment. In the past two years, BPEL has effectively become the most significant standard to elevate the visibility of SOA from IT to business level. BPEL is not only commoditizing the integration market, but it is also offering organizations a whole new level of agility—the ability to rapidly change applications as per changing business landscape. BPEL enables organizations to automate their business processes by orchestrating services within and across the firewall. It forces organizations to think in terms of services. Existing functionality is exposed as services. New applications are composed using services. Communication with external vendors and partners is done through services. Services are reused across different applications. Services everywhere!
New technology, after being adopted by "technology enthusiasts" and "visionaries" is adopted by "pragmatists". Similarly, after proving its worth, SOA is breaking into the mainstream. Technology Acceptance Model is one of the most influential models to explain the process of technology adoption. According to TAM, SOA has to prove itself on two terms—perceived usefulness and perceived ease of use—for SOA to successfully cross the chasm and be adopted more widely. We think SOA has proven its effectiveness on both these fronts. Not only can SOA deliver on its promises of reusability and agility (usefulness) but it can also reduce the overall cost of ownership through the standards-based approach (ease of use). That is precisely the reason why SOA enables organizations to cut the cost of IT dramatically and use the resulting savings in building other innovations.
XML, SOAP, web services, and BPEL are basic artifacts of any SOA application. In the Business Process Execution Language for Web Services book (Packt Publishing, October 2004, ISBN 1‑904811-18-3) by Matjaž Jurič, we learned about the building blocks and how these technologies could be used to build a simple SOA solution. As organizations increase their SOA footprint, IT Managers, Architects, and developers are starting to realize that the impact of SOA on IT and business operations can be immense. After having gained confidence with web services, they want to take it to the next level. However, adopters are challenged with some basic questions: How do I SOA-enable my existing integration investment? Can I build flexible and agile business processes? How can I administer my SOA environment without spending fortune? There have been various best practices defined around SOA. However, missing from the map is the real-world flavor. People want to learn from people. The IT community is looking for real-world examples; examples to gain an understanding of how other companies are embarking on an SOA initiative and apply industry learning to their projects.
This book is not just another SOA best-practices manual providing generic recommendations. It is actually a best practice cookbook. You might wonder, "Why are they calling this a 'cookbook'?" After having been exposed to different ingredients (BPEL, WSDL, and web services), this book takes the adventure to the next level by helping you cook new recipes (SOA applications) using efficient kitchen techniques (best practices). Recipes and techniques help cook food faster. And we plan do this using real-life scenario: real stories from real adopters! 10 SOA practitioners have gotten together to share their SOA best practices and provide practical viewpoints to tackle many of the common problems SOA promises to solve. Their recommendations are based on projects in production; their existing projects could be your next ones. This book will help you learn through proven best practices and accelerate the progress of your SOA implementation.
While talking to different companies at various stages of the SOA implementation cycle, we realized one common pattern: all SOA initiatives were driven by a business need. As you start reading this book, you will be exposed to various business challenges faced by the organizations and how companies are leveraging SOA technologies to address them. Since you are reading this book, we think that there is a business need behind your investigation and curiosity. Whether it is the need to provide a 360-degree view of the customer or to reduce the time to market, we feel that business necessity should drive SOA initiatives and justify your investment in SOA. Hence, we ensured that every chapter we present in this book is tied to a specific business use case. By ensuring this business relevance, we want to drive home the point that SOA success, to a large extent, depends on the business sponsorship and desire to address a specific business problem.
SOA is rapidly emerging technology. However, there is some level of fear and anxiety among the IT community about SOA. Is SOA real? Do I need SOA? How is it done? Hence, when we started thinking about the strategy to organize the contents of this book, we decided to take an approach of "inspire and equip", as shown in the following figure:
The first two sections of the book will "inspire" you. You will be happy to know that SOA is a reality; it exists and you can do it as well. It will encourage you to take a plunge into the world of services and test-drive SOA yourself. If you are already amidst an SOA implementation, these sections will offer you fresh insight into your current approach to deal with specific business challenges and guide you with "best practices" architecture.
In the third section, we "equip" you with techniques to build a better SOA application. These techniques are best practices and code snippets ranging from development to administration of an SOA application. They are generic enough to be applied in any of your existing projects, and will help you reap more benefits from your SOA implementation.
Integration has long been a thorn in the flesh of any company. Whether you attribute it to the proprietary nature of the integration products or to the cost of procuring, implementing, and maintaining these products, integration has been dreaded by the IT community. SOA promises to alleviate this everyday problem by introducing a simple concept: don't integrate applications, rather integrate services. This combined with a standards-based approach lowers the total cost of ownership. It represents the sweet spot for SOA investment. Organizations are leveraging SOA to solve a variety of everyday integration problems, thereby making SOA a mainstream technology. In the first section, we introduce different SOA integration scenarios to inspire integration architects and developers.
Chapter 1: Extending Enterprise Application Integration: This chapter focuses on very common business problem i.e. siloed applications and segregated data glued together using proprietary integration solution. How can we best leverage SOA to add value on top of existing integration infrastructure? By service-enabling existing data-integration processes, business processes could be easily automated by orchestrating underlying services. Infosys, a leading systems integrator, has helped many of its customers leverage their existing EAI investment, and explains you how to do exactly this. This chapter takes an example of broken customer data synchronization between Siebel and SAP, and outlines a strategy to automate this process by integrating with proprietary integration solutions like TIBCO and webMethods.
Chapter 2: Service-Oriented ERP Integration: Driven by the business requirements of different departments, countries, and subsidiaries, many organizations end up with multiple ERP systems. The result is data fragmentation and manual processes. This, in turn, leads to poor customer service and loss of revenue. The problem is how to address this problem without re-architecting the entire solution. Sierra Atlantic, a leading consulting firm specializing in integration technologies, encountered a similar issue with its client. In this chapter, Lawrence Pravin, Architect at Sierra Atlantic, takes an example of a broken sales order creation process. He walks you through a step-by-step approach to automate it across PeopleSoft HR and Oracle E-Business Suite using BPEL in a service-oriented approach.
Chapter 3: Building the Service Value Chain: Not all integrations are limited within the enterprise. Processes interact with applications, people, and partners. You might have heard the term Business‑to-Business (B2B) frequently in the past few years. How can organizations build a network of services spanning multiple organizations? The European Space Agency built such a network of web services across more than 20 partners in nine different countries. The primary purpose of this network is to offer Earth Observation and Geographic Information System services to consumers. This chapter presents an initial strategy of how to architect and design a service-oriented partner‑friendly network using web services and BPEL for orchestration. The focus is on four important aspects of network design: defining partner relationships, enabling partner provisioning, offering a central registry of available services, and empowering partners and end users.
Chapter 3: Building the Service Value Chain: Not all integrations are limited within the enterprise. Processes interact with applications, people, and partners. You might have heard the term Business‑to-Business (B2B) frequently in the past few years. How can organizations build a network of services spanning multiple organizations? The European Space Agency built such a network of web services across more than 20 partners in nine different countries. The primary purpose of this network is to offer Earth Observation and Geographic Information System services to consumers. This chapter presents an initial strategy of how to architect and design a service-oriented partner‑friendly network using web services and BPEL for orchestration. The focus is on four important aspects of network design: defining partner relationships, enabling partner provisioning, offering a central registry of available services, and empowering partners and end users.
SOA represents an evolution in the way applications are architected and built. Functions, objects, and modules were some of the artifacts used to build applications in the 90s. In essence, SOA has captured many of the old architectures and refined them to provide a new approach in building applications to meet modern business needs. Modern businesses demand faster response time i.e. the ability to meet new business requirements as fast as possible in the most economical way. Modern applications are built with these requirements in mind. Composite Application Development, Service-Oriented Development of Applications (SODA), and Agile Programming are different but related paradigms of building such modern applications in an "incremental" fashion. This second section continues the charter to inspire architects (this time application architects) to build modern service-oriented applications.
Chapter 4: A Services-Oriented Approach to Business Rules Development: Organizations have processes, and processes have rules. Processes need to be automated. Rules need to be defined intuitively. BPEL automates process and a rules engine automates policies. These rules essentially drive the processes. IT organizations have so far struggled to delineate business processes from rules, leading to operational inconsistency and duplication. Policy Studies Inc. provides an approach to segregate rules from processes, and offers a blueprint to expose rules as services for building cleaner applications. Using BPEL and a rules engine, PSI has built a shared services platform to perform Medicare eligibility processing for different states. Kevin Geminiuc, former Architect at PSI, explains the development strategy to integrate BPEL with a rules engine resulting in a solution that is more agile and flexible. With this approach, it is possible to change a business process without touching policies. Policies can be changed graphically without affecting the business processes.
Chapter 5: Building Rich Internet Applications for Workflow and Process Monitoring: As we discussed before, processes interact with applications, people, and partners. How can we build an application that enables business users to interact with processes seamlessly? Applications should be built to enhance end-user experience. Enterra Solutions marries the world of SOA with the world of Web 2.0. In this chapter, Doug Todd, CTO of Enterra, presents a strategy to extend BPEL workflow in a rich user interface and build an application that not only automates processes, but also ups the ante in terms of aesthetic appeal. It also represents a unique approach to customize a platform, which is SOA ready.
Chapter 6: Building BPEL Process on the Fly: BPEL provides an opportunity to bring business and IT together. Business can help define the key processes, and IT provides the necessary infrastructure to run and automate those processes. Some might argue that BPEL is too technical to be handed over to analysts for process modeling. CenterStone software, a provider of workplace management solution, addressed this very concern by building a custom designer geared towards property managers to define processes for workplace management. CenterStone devised an approach to convert the processes designed using the custom designer into BPEL processes. This chapter will inspire you to build applications, which will facilitate tighter integration with your business counterparts. Jerry Thomas, Chief Architect at CenterStone Software, takes you into the guts of this approach by explaining how process definition can be stored in the database and how XQuery and Saxon parser can help you to build an executable BPEL process from its higher-level process definition.
By now, it is our sincere hope that integration and application architects are "inspired" to take on the SOA challenge. All the learning and encouragement might have invigorated you to apply SOA in your IT environment. However, as you start implementing SOA, you will need to "equip" yourself with best practices, which facilitate efficiency in design, development, and management of your SOA implementation. Best practices will accelerate your path to SOA success and help deliver on the traditional SOA promises, i.e. promote reusability by leveraging existing investment or increase business agility through flexible business processes. In this section, peers will offer you tips and tricks that add value in different stages of your implementation. This third section introduces you to four such "best practices" to derive maximum benefit from your investment. The step-by-step guides attempt to make it easy for you to adopt these proven techniques.
Chapter 7: Making BPEL Processes Dynamic: The benefit of agility has been belabored exhaustively in the industry. We decided to go back to basics and offer you a very simple technical insight into how SOA enables business agility. Agility is directly correlated to the ability to quickly respond to business changes. By using dynamic partner links, processes can effectively change their behavior to adapt themselves to external business conditions and thereby offer flexibility. SPS Commerce, provider of hosted EDI solutions, has built an SOA-enabled platform for enabling seamless exchange of EDI documents between different entities. In this chapter, SPS Commerce will explain the significance of dynamic partner links and walk you through a step‑by‑step guide to implement partner links in a sample loan-processing scenario. This approach will enable you to quickly add/delete service providers participating in a business process without actually changing the process.
Chapter 8: Using WSIF for Integration: Organizations operate in a heterogeneous environment. Applications are built using different technologies, from different vendors and different implementers. As you start building a process, you will realize that the underlying applications are not necessarily web services. More often than not, they are either .NET applications or applications built using J2EE, i.e. either purchased applications or home-grown Java Applications. Matjaž Jurič, author of the Packt book Business Process Execution Language for Web Services (ISBN: 1-904811-18-3) presents a strategy to integrate with Java resources using Web Services Invocation Framework (WSIF). Matjaž, professor of Computer Science at the University of Maribor, argues that although it is possible to expose these applications as web services and use them in the process, accessing these resources natively can improve the application performance significantly.
Chapter 9: BPEL with Reliable Processing: The success of any service in the SOA world depends upon its degree of reusability, which in turn depends upon the quality of service offered. As you run your SOA applications, many things could go wrong. Network connections may be lost, participating applications may go down, incoming data might be corrupted, etc. These external interruptions can degrade the quality of a particular application. How can you design an application that can withstand all these failures and still emerge as a winner? Qualcomm encountered this specific issue while leveraging SOA to build the Entitlement Provisioning application. Presented in the fashion of step-by-step tutorial, Jeremy Bolie, IT Manager, and Michael Cardella, Architect at Qualcomm, share with you a strategy to design a reusable BPEL process capable of offering any service and defeating rectifiable errors.
Chapter 10: Managing a BPEL Production Environment: The last chapter in this cookbook deals with an important aspect of any application—maintenance. More dollars are spent in maintenance and enhancement of an application than the combined amount spent during its design, development, and testing phases. Once the application is deployed into production, the real work begins. Belgacom, one of the leading telecommunications companies in Belgium, has automated DSL service provisioning and diagnosis using BPEL. Having been in production for a long time, Belgacom has vast practical experience in managing a BPEL infrastructure. In this chapter, Stany Blanvalet, former Architect at Belgacom, explains various strategies for managing a BPEL production environment. This is a must read for all the BPEL administrators.
Having progressed from "inspire" to "equip" mission, we are confident that you will have a strong real-world perspective of how SOA is put in use. Each of these chapters brings into focus a real‑world business issue and offers how a specific company has approached SOA to address that issue. This does not necessarily mean that this is the only best solution for the problem at hand. It is just one of the many solutions. However, after reading through these chapters, you will realize that your business environment might be similar and some (possibly all) ideas presented in a specific chapter are applicable to your situation. Some may require modification; some may be applied directly! If you are able to relate to at least one of the 10 business issues presented here and apply some of the strategies presented in this book, we have achieved what we set out to do.
Best of luck with your SOA journey! Enjoy the ride! Carpe Diem!
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
There are three styles for code. Code words in text are shown as follows: "We can include other contexts through the use of the include directive."
A block of code will be set as follows:
WhereCondition where = WhereConditionHelper.whereInstancesStale();
IInstanceHandle[] instances = getLocator(domainId, domainPassword).listInstances(where);
for(int i=0; i<instances.length; i++){
instances[i].delete();
}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:
WhereCondition where = WhereConditionHelper.whereInstancesStale();
IInstanceHandle[] instances = getLocator(domainId, domainPassword).listInstances(where);
for(int i=0; i<instances.length; i++){
instances[i].delete();
}
New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen".
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Visit http://www.packtpub.com/support, and select this book from the list of titles to download any example code or extra resources for this book. The files available for download will then be displayed.
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata have been verified, your submission will be accepted and the errata added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our best to address it.