41,07 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
In Detail
We are moving towards a standards-based Service-Oriented Architecture (SOA), where IT infrastructure is continuously adapted to keep up with the pace of business change. Oracle is at the forefront of this vision, with the Oracle SOA Suite providing the most comprehensive, proven, and integrated tool kit for building SOA based applications.
Developers and Architects using the Oracle SOA Suite, whether working on integration projects, building composite applications, or specializing in implementations of Oracle Applications, need a hands-on guide on how best to harness and apply this technology.
This book will guide you on using and applying the Oracle SOA Suite to solve real-world problems, enabling you to quickly learn and master the technology and its applications.
The initial section of the book is aimed at providing you with a detailed hands-on tutorial to each of the core components that make up the Oracle SOA Suite; namely the Oracle Service Bus, BPEL Process Manager, Human Workflow, Business Rules, and Business Activity Monitoring. Once you are familiar with the various pieces of the SOA Suite and what they do, the next question will typically be: "What is the best way to combine / use all of these different components to implement a real-world SOA solution?"
Answering this question is the goal of the next section. Using a working example of an online auction site (oBay), it leads you through key SOA design considerations in implementing a robust solution that is designed for change. Though the examples in the book are based on Oracle SOA Suite 10.1.3.4 the book will still be extremely useful for anyone using 11g.
The final section addresses non-functional considerations and covers the packaging, deployment, and testing of SOA applications; it then details how to use Web Service Manager to secure and administer SOA applications.
Use and apply the Oracle SOA Suite in the implementation of real-world SOA applications.
Approach
This book is a comprehensive guide, split into three sections. The initial section of the book provides an introduction to the Oracle SOA Suite and its various components, and will give you a fast-paced hands-on introduction to each of the key components in turn. The next section illustrates the usage of the various components of the SOA Suite to implement a real-world SOA-based solution with the help of an example of an online auction site (oBay). The final section covers other considerations such as the packaging, deployment, testing, security, and administration of SOA applications.
Who this book is for
This book targets developers and technical architects who work in the SOA domain. The primary purpose of the book is to provide them with a "hands on" practical guide to using and applying the Oracle SOA Suite in the delivery of real-world composite applications.
It presumes basic understanding of the concepts of SOA, as well as some of the key standards in this space, including web services (SOAP, WSDL), XML Schemas, and XSLT (and XPath).
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 760
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
Oracle SOA Suite Developer's Guide
Matt Wright
Antony Reynolds
Oracle SOA Suite Developer's Guide
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: March 2009
Production Reference: 1120309
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847193-55-1
www.packtpub.com
Cover Image by Vinayak Chittar (<[email protected]>)
Credits
Authors
Matt Wright
Antony Reynolds
Reviewers
Jason Jones
Phil McLaughlin
Acquisition Editor
Bansari Barot
Development Editor
Swapna V. Verlekar
Technical Editor
Gagandeep Singh
Editorial Team Leader
Akshara Aware
Production Editorial Manager
Abhijeet Deobhakta
Project Team Leader
Lata Basantani
Project Coordinator
Rajashree Hamine
Indexer
Rekha Nair
Proofreader
Laura Booth
Production Coordinator
Rajni R. Thorat
Cover Work
Rajni R. Thorat
Foreword
Over the past several years, we have seen a growing momentum in the adoption of Service-Oriented Architectures, which continues to accelerate. At this point in its evolution, SOA has started to cross the chasm between the early-adopter, bleeding-edge IT architects and the mainstream IT and software development community. And what enables this progression to continue gathering steam is the sharing of knowledge, experiences, and lessons learned between the early adopters in the community and those following their footsteps. As such, I am very enthusiastic about Oracle SOA Suite Developer Guide because Matt Wright and Antony Reynolds are exactly the right people to share this knowledge with us.
I joined Oracle in 2004 through the acquisition of Collaxa, which is where the Oracle BPEL Process Manager came from. At Collaxa, I was responsible for all the interfaces between our SOA products and our customers and the developer community. It was very clear, shortly after the acquisition, that the Oracle field was going to be a tremendous asset to the adoption of our products, our customers' success, and to the advancement of SOA in general.
As Oracle became a leader in the SOA space over the next several years, building out a full SOA platform through continued development and further acquisitions, Antony and Matt continued to stand out as leaders among the special community of Oracle SOA field representatives. Along the way, they built a knowledge base that enabled customers to get over (and better yet, avoid…) common hurdles, and feed customer requirements back into the engineering organization. We are highly appreciative of the fact that they have undertaken the monumental task of incorporating this knowledge into a book that is built on the existing documentation, and will provide great value to experienced SOA practitioners and newbies alike.
SOA is about more than just tools, a fact that is clear even to those of us who work for software vendors. However, to be effective with any software development products, requires detailed knowledge of the products, APIs, features, and capabilities. Antony and Matt cover these basics in this book in great detail.
But even more importantly, developers need to know about edge cases, design patterns, and how these products fit into the full development life cycle. This information comes best from real-world experiences with the products, even more than from the people who build a product. It is particularly valuable that Antony and Matt focus the majority of the content in this book on deeper topics such as SOA exception handling, full life cycle support for testing, security, and migration across environments. If I had a quarter for every customer who has asked me, over the past eight years, about best practices to move their SOA composites from dev to test to production… well, let's just say you can save your quarters and read Chapter 18 instead.
Finally, even as SOA adoption matures, it is still important to understand why you are adopting SOA, what the expected benefits are, and to measure your progress toward those as objectively as possible. Today, most people state goals such as:
I believe that this book, coming from pragmatic practitioners in the field, will specifically help developers realize these benefits from their SOA implementations by providing clear and useful information on Oracle's SOA platform.
On behalf of the Oracle SOA Engineering and Product Management team, as well as all the customers and partners who have asked for this book, we heartily thank Antony and Matt for the investment of their time and energy, and hope that this book helps you achieve your SOA goals.
David Shaffer
Vice President, Product Management
Oracle Integration
About the authors
Matt Wright has been involved with standards-based Service-Oriented Architecture (SOA) since shortly after the initial submission of SOAP 1.1 to the W3C in 2000, and has worked with some of the early adopters of BPEL since its initial release in 2002. Since then, he has been a passionate exponent of SOA and has been engaged in some of the earliest SOA-based implementations across EMEA and APAC.
He is currently a Director of Product Management for Oracle Fusion Middleware in APAC, where he is responsible for working with organizations to educate and enable them in realizing the full business benefits of SOA in solving complex business problems. As a recognized authority on SOA, Matt is also responsible for evangelizing the Oracle SOA message and is a regular speaker and instructor at private and public events. He also enjoys writing and publishes his own blog (http://blogs.bpel-people.com). Matt holds a B.Sc. (Eng) in Computer Science from Imperial College, University of London.
It seems a long time ago that I first suggested to Antony that we write this book. Since that day there have been numerous twists and turns, not least the acquisition of BEA which resulted in many revisions and re-writes. Having Antony as my co-author throughout this process was invaluable; Antony's continued conviction and enthusiasm throughout was instrumental in ensuring the book finally made the light of day.
Throughout this process, everyone at Oracle has been very supportive. I would like to make a special mention to Andy Gale for guiding us in the right direction when we first suggested the idea and to John Deeb for his continual support and encouragement throughout. I would also like to express my gratitude to everyone in the SOA Development team; in particular to David Shaffer, Demed L'Her, Manoj Das, Neil Wyse, Ralf Mueller, and Mohamed Ashfar who contributed to this book in many ways.
A major part in the quality of any book is down to the reviewers, so I would like to say a big thank you to Phil McLaughlin, Jason Jones, and James Oliver for all their incredibly valuable feedback, which has made this a clearer and simpler book to read.
The staff at Packt Publishing Pvt. Ltd. helped a great deal to make this book a reality. I would like to thank Rajashree Hamine the Project Coordinator, Swapna Verlekar the Development Editor, and Gagandeep Singh the Technical Editor.
Finally, writing a book is challenging at the best of times, to do it whilst re-locating half way round the world from the UK to Australia probably isn't the best timing! So I would like to say a special thank you to my wife Natasha and my children Elliot and Kimberley for their constant support and understanding throughout this period.
Antony Reynolds has worked in the IT industry for more than 24 years, since getting a job to maintain yield calculations for a Zinc smelter while still an undergraduate. After graduating from the University of Bristol with a degree in Maths and Computer Science he worked first for a software house, IPL in Bath, England, before joining the travel reservations system Galileo as a development team lead. At Galileo he was involved in development and maintenance of workstation products before joining the architecture group. Galileo gave him the opportunity to work in Colorado and Illinois where he developed a love for the Rockies and Chicago style deep pan pizza. He joined Oracle in 1998 as a sales consultant and has worked with a number of customers in that time, including a large retail bank's Internet banking project for which he served as chief design authority and security architect.
Antony currently is lucky to work with customers on the early stages of many interesting projects, providing advice on sizing models and architecture for the SOA Suite.
Outside of work Antony is a bishop in the Church of Jesus Christ of Latter Day Saints (Mormons) and is responsible for a congregation of 350. His wife and four children make sure that he also spends time with them, playing games, watching movies, and acting as an auxiliary taxi service.
I would like to thank my wife Rowan, and my four very patient children, who have put up with their husband and father disappearing into his office in the roof far too often. Several reviewers have provided invaluable advice and assistance. Phil McLaughlin of Oracle has been a constant source of encouragement and constructive criticism as the book has homed in on its target platform. Iswarya Dhandapani of Luton Borough Council took the time to try out all my code samples and identify ones which didn't work as well as providing feedback on my chapters from the view of someone who has to use SOA Suite to provide real solutions. Oracle ACE Jason Jones came a little late to the reviewing but managed to review every chapter and made clear what worked for him and what didn't. Simone Geib of Oracle Product Management provided valuable feedback on the sections covering Oracle Service Bus. I particularly appreciated the way all the reviewers not only pointed out the problems in the book but also identified the positive parts. Edwin Khodabachian is no longer with Oracle, but his team created the BPEL Process Manager at Collaxa, which was bought by Oracle and became under Edwins guidance the foundation of the SOA Suite. Finally, I would like to express appreciation to Thomas Kurian at Oracle who had the vision of a single integrated product suite, the Oracle SOA Suite, and has always been willing to listen to provide advice and guidance to me.
About the reviewers
Jason Jones is a software architect specializing in SOA and Java technologies. Since 2003, Jason has worked for Zirous, an Oracle Certified Partner, where he currently holds the position of Senior System Architect. In 2007, Jason was named an Oracle ACE Director, a prestigious international group of Oracle experts. Jason has been accepted as a speaker at Oracle OpenWorld, IOUG COLLABORATE, ODTUG Kaleidoscope, and has a published article on OTN.
Jason's more than 8 years of experience in IT that includes SOA technologies such as BPEL, ESB, SOAP, WS-Security, XML, and Enterprise Java technologies such as Spring, Struts, JMS, JPA, Hibernate, and EJBs among many others. Jason is a Sun Certified Java Programmer (SCJP), Sun Certified Web Component Developer (SCWCD), and holds a BS in Computer Science from Iowa State University.
Jason's blog can be found at <realjavasoa.blogspot.com>.
Phil McLaughlin has 20 years of early adopter experience with the technologies associated with SOA, working with architectural models such as object orientation before they were mainstream. In the late 1980s and early 1990s this was largely with the Smalltalk programming language and associated tools but he was asked to investigate and teach Java in 1997. Since then, he has maintained his interest in the development of distributed composite applications intially with CORBA, then J2EE and more recently SOA itself.
Phil's experience of SOA spans the theoretical and practical, having been a senior lecturer in academia until 1997 specializing in object oriented software (which could reasonably be argued as providing the foundations of the SOA architectural model), and how to transfer the requisite skills to developers often struggling with new and different architectural paradigms. Since 1997, he has worked in a number of specialist consultancies covering topics such as analysis and design methods, development and implementation from the OO/SOA perspective.
Phil Joined Oracle Corporation (UK) in 2002 when Oracle acquired the TopLink persistence management framework from WebGain and since then has specialized in working with Partners/System Integrators to educate them on best practice around the use of Oracle Java technology and more recently the Oracle SOA Suite. Phil currently holds the position of Master Principal Sales Consultant in the UK SOA pre-sales team where he provides initial advice and solution mapping to customers and partners about Oracle's SOA offerings.
Phil has worked with both authors for a number of years and is very pleased that thay have decided to share their wealth of knowledge and practical experience with the wider community. For anyone working with Oracle SOA suite, this is a 'must have' book.
Preface
Service-oriented architecture is not just changing how we approach application integration, but the mindset of software development as well.
Applications as we know them are becoming a thing of the past. In the future we will increasingly think of services and how those services are assembled to build complete "composite" applications that can be modified easily and quickly to adapt to a continually evolving business environment.
This is the vision of a standards-based service-oriented architecture (SOA), where the IT infrastructure is continuously adapted to keep up with the pace of business change.
Oracle is at the forefront of this vision, with the Oracle SOA Suite providing the most comprehensive, proven, and integrated tool kit for building SOA based applications.
This is no idle boast. Oracle Fusion Applications (the re-implementation of Oracle's E-Business Suite, Siebel, PeopleSoft, and JD Edwards Enterprise as a single application) is probably the largest composite application being built today and it has the Oracle SOA platform at its core.
Developers and architects using the Oracle SOA Suite, whether working on integration projects, building new bespoke applications, or specializing in large implementations of Oracle Applications will need a book that provides a hands-on guide on how best to harness and apply this technology. This book will enable them to do just that.
The initial section of the book is aimed at providing the reader with an overview of the Oracle SOA Suite and its various components, followed by a hands on introduction to each of them. This will provide the reader with a good feel for each of the components and how to use them.
Once the reader is familiar with various pieces of the SOA Suite and what they do, the next question will typically be:
What is the best way to combine/use all of these different components to implement a real world SOA solution?
Answering this question is the goal of the next section. Using a working example of an online auction site (oBay), it leads the reader through key SOA design considerations in implementing a robust solution that is designed for change. It explores topics such as:
Before an application is complete and moves from development into production, it must also meet non-functional criteria such as security, availability, and scalability requirements. The final section addresses these issues and covers considerations such as the packaging, deployment, testing, security, and administration of composite applications as well as the overall deployment of the infrastructure. Topics addressed include:
What this book covers
The book is divided into three sections. Let us have a look at these three sections in detail.
Section 1: Getting started
This section provides an overview of the various components of the Oracle SOA Suite and gives the reader a fast-paced, hands-on introduction to each of the key components.
Chapter 1 gives an initial tour of the constituent parts, which make up the Oracle SOA Suite as well as detailing related elements of the Oracle Fusion Middleware stack and how they relate to the SOA Suite.
Chapter 2 provides an initial look at the Oracle BPEL Process Manager and Oracle Service Bus, by stepping us through the process of developing, deploying, and running our first service.
Chapter 3 looks at a number of key technology adapters and how we can use them to service enable existing systems.
Chapter 4describes how we can use the Oracle Service Bus to build services that are implementation agnostic. Doing so allows us to change the service location, communication protocol, or even replace a service implementation with another, with no impact on the client.
Chapter 5 describes how we can use BPEL to assemble services to build composite services as well as how we can link together a number of services to build a long-running business process. It also introduces the concepts of synchronous and asynchronous services.
Chapter 6 looks at how human tasks can be managed through workflow activities embedded within a BPEL process.
One of the key motivations behind SOA is Agility, the ability of an organization to respond rapidly to changes in market conditions and hence gain a competitive advantage.
Chapter 7 introduces the concept of externalizing "decision points" in a BPEL process as business rules, allowing us to change the flow through a process without having to make any changes to the deployed process.
Chapter 8examines how Business Activity Monitoring (BAM) can be used to give business users a real-time view into how the business process is performing.
Section 2: Putting it all together
This section uses the example of an online auction site (oBay) to illustrate how to use the various components of the SOA Suite to implement a real-world SOA based solution.
Each chapter covers a specific area that needs to be considered when developing a SOA based solution, such as the design of the service contract, validation, error handling, and message interaction patterns.
To highlight and demonstrate key design considerations, chapters use examples based on key parts of the oBay application to illustrate what's been covered, as well as providing a step-by-step guide on how to implement these techniques.
Chapter 9 introduces oBay and details the overall business requirements of the online auction site. Next, we present our outline for a typical SOA architecture, highlighting some of the key design considerations behind this. Finally, we use this to derive the overall architecture for oBay.
The first step in building a sustainable SOA based solution, that is, one that easily accommodates future change, is careful design of the service contracts. Chapter 10 gives guidance on designing these contracts and provides strategies for managing change when it occurs.
Once we know what service we require, we need to select the appropriate way of providing it. In Chapter 11, we examine different approaches to this, either through service enabling an existing application, using someone else's service, or building the service from scratch.
A common question with SOA is "Where do I put my validation?" At first glance this may seem like an obvious question, but once we consider the layered approach to SOA, it soon becomes clear that there are a number of choices each with their own advantages and disadvantages. Chapter 12 provides us with guidelines on where to put our validation and how to implement it.
Chapter 13 examines strategies for handling errors in SOA based systems. It covers system errors such as a network connection going down meaning a web service is temporarily unavailable, and business errors such as service being invoked with invalid data.
In every business process messages are exchanged between participants. So far, we have only looked at simple interactions, that is a single request followed by a reply, whether synchronous or asynchronous.
In Chapter 14, we look at messaging in a lot more detail. In particular, how we handle more complex interactions such as multiple requests and responses, unscheduled events, timeouts, and message correlation (both system and business).
In Chapter 15, we look at workflows involving complex chains of approval, including parallel approvers and the different options that are available. We also look at how we can use the Workflow Service API to integrate workflow into a user's existing user interface as an alternative to accessing it through the out of the box worklist application.
The Rules engine uses the Rete Algorithm, which was developed by researchers into Artificial Intelligence in the 1970s. In Chapter 16, we look at some of Rete's unique qualities, and how we can use them to implement particular categories of first class business services.
When we talk about web services, most people assume that we are going to bind (that is, connect to) the service using SOAP over HTTP. Indeed, this is often the case; however, Oracle SOA Suite supports binding to web services over multiple protocols. Chapter 17 looks at the different bindings supported and the various advantages they have, including better support for transactions and improved performance.
Section 3: Other considerations
This final section covers other considerations such as the packaging, deployment, testing, security, and administration of composite applications as well as the overall deployment of the infrastructure.
Chapter 18 examines how to package up the various artifacts that make up a composite application in order to enable easy deployment into multiple environments such as test and production. We also look at suitable deployment topologies for the SOA Suite based on run-time requirements for high availability, disaster recovery, and scalability.
Chapter 19 looks at how to create, deploy, and run test cases that automate the testing of composite applications. Testing is dealt with at several levels: unit testing, component testing, and finally assembly testing.
Chapter 20examines how we can centrally define policies that govern the operation of web services, such as security and access policies, auditing policies, and the management of service level agreements.
Who is this book for
The primary purpose of the book is to provide developers and technical architects with a practical guide to using and applying the Oracle SOA Suite delivering real-world SOA based applications.
It is assumed that the reader already has a basic understanding of the concepts of SOA, as well as some of the key standards in this space, including web services (SOAP, WSDL), XML Schemas, and XSLT (and XPath).
Conventions
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.
Code words in text are shown as follows: "Each schema can reference definitions in other schemas by making use of the xsd:import directive."
A block of code will be set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:
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".
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
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.
Customer support
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.
Downloading the example code for the book
Visit http://www.packtpub.com/files/code/3551_Code.zip to directly download the example code.
The downloadable files contain instructions on how to use them.
Errata
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 let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata are added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide the location address or website name immediately so we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
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.
Chapter 1. Introduction to Oracle SOA Suite
The Oracle SOA Suite is a large and complex piece of software. In this chapter we will provide a roadmap for your use of the SOA Suite. After a review of the basic principles of SOA we will look at how the SOA Suite provides support for those principles through its many different components. Following this journey through the components of SOA Suite, we will introduce Oracle JDeveloper as the primary development tool that is used to build applications for deployment into the SOA Suite.
Service-oriented architecture in short
Service-oriented architecture (SOA) has evolved to allow greater flexibility in adapting the IT infrastructure to satisfy the needs of business. Let's examine what SOA means by examining the components of its title.
Service
A service is a term that is understood both by the business and IT. It has some key characteristics:
The break-out box uses the example of a laundry service to make the characteristics of a service more concrete. Later we will map these characteristics onto specific technologies.
Tip
A clean example
Consider a laundry service. The service provider is a laundry company, and the service consumer a corporation or individual with washing to be done.
The input to the company is a basket of dirty laundry. Additional input parameters may be a request to iron the laundry as well as wash it, or to starch the collars. The output is a basket of clean washing with whatever optional additional services such as starching or ironing were specified. This defines the interface.
Quality of service may specify that the washing must be returned within 24 or 48 hours. Additional quality of service attributes may specify that the service is unavailable from 5PM Friday until 8AM Monday. These service level agreements may be characterized as policies to be applied to the service.
An important thing about services is that they can be understood by both business analysts and IT implementers. This leads to the first key benefit of service-oriented architecture.
Note
SOA makes it possible for IT and the business to speak the same language, that of services.
Services allow us to have a common vocabulary between IT and the business.
Orientation
When we are building our systems we are looking at them from a service point of view or orientation. This implies that we are oriented or interested in the following:
Thinking of everything as a service leads us to another key benefit of service-oriented architecture—composability.
Note
Composing new services out of existing services allows easy reasoning about the availability and performance characteristics of the composite service.
By building composite services out of existing services, we can reduce the amount of effort required to provide new functionality as well as being able to build something with prior knowledge of its availability and scalability characteristics. The latter can be derived from the availability and performance characteristics of the component services.
Architecture
Architecture implies a consistent and coherent design approach. This implies a need to understand the inter-relationships between components in the design and ensure consistency in approach. Architecture suggests that we adopt some of the following principles:
Tip
Extending Antony's house
My wife and I designed our current house. We built in the ability to convert the loft into extra rooms and also allowed for a conservatory to be added. This added to the cost of the build but these were foreseen extensions. The costs of actually adding the conservatory and two extra loft rooms were low because the architecture allowed for this. In a similar way it is relatively easy to architect for foreseen extensions, such as additional related services and processes that must be supported by the business. When we wanted to add a playroom and another bathroom, this was more complex and costly as we had not allowed for it in the original architecture. Fortunately our original design was sufficiently flexible to allow for these additions but the cost was higher. In a similar way the measure of the strength of a service-oriented architecture is the way in which it copes with unforeseen demands, such as new types of business process and service that were not foreseen when the architecture was laid down. A well architected solution will be able to accommodate unexpected extensions at a manageable cost.
A consistent architecture when coupled with implementation in SOA Standards gives us another key benefit—inter-operability.
Note
SOA allows us to build more inter-operable systems by being based on standards agreed by all the major technology vendors.
SOA is not about any specific technology. The principles of service-orientation can be applied equally well using assembler as they can in a high level language. However, as with all development it is easiest to use a model that is supported by tools and is both inter-operable and portable across vendors. SOA is widely associated with the web service or WS-* standards presided over by groups like OASIS. This use of common standards allows SOA to be inter-operable between vendor technology stacks.
Why SOA is different
A few years ago distributed object technology in the guise of CORBA and COM+ were going to provide benefits of reuse. Prior to that third and fourth generation languages such as C++ and Smalltalk based on object technology were to provide the same benefit. Even earlier the same claims were made for structured programming. So why is SOA different?
Terminology
The use of terms such as "services" and "processes" allows business and IT to talk about items in the same way, improving communication and reducing impedance mismatch between the two. The importance of this is greater than what it appears initially, because it drives IT to build and structure its systems around the business rather than vice versa.
Inter-operability
In the past there have been competing platforms for the latest software development fad. This manifested itself as CORBA and COM+, Smalltalk and C++, Pascal and C. This time around the standards are not based upon the physical implementation but upon the service interfaces and wire protocols. In addition these standards are generally text based to avoid issues around conversion between binary forms. This allows services implemented in C# under Windows to inter-operate with Java or PL/SQL services running on Oracle SOA Suite under Windows, Linux or UNIX. The major players like Oracle, Microsoft, IBM, SAP, and others are agreed on how to inter-operate together. This agreement has always been missing in the past.
Note
WS Basic Profile
There is an old IT joke that standards are great, there are so many to choose from! Fortunately this has been recognized by the SOA vendors and they have collaborated to create a basic profile, or collection of standards, that focus on inter-operability. This is known as WS Basic Profile and details the key web service standards that all vendors should implement to allow for inter-operability. SOA Suite supports this basic profile as well as additional standards.
Extension and evolution
SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level it focuses on how services are described and how they inter-operate in a standards-based world.
Reuse in place
A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not just on reuse of the code functionality but also upon the reuse of exiting machine resources to execute that code. When a service is reused the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies but it does mean that performance of existing users may be impacted if care is not taken in how services are reused.
SOA Suite components
SOA Suite has a number of component parts, some of which may be licensed separately.
Services and adapters
The most basic unit of a service-oriented architecture is the service. This may be provided directly as a web service enabled piece of code or it may be exposed by encapsulating an existing resource.
Services are defined by a specific interface, usually specified in a Web Service Description Language (WSDL) file. A WSDL file specifies the operations supported by the service. Each operation describes the expected format of the input message and if a message is returned it also describes the format of that message. The structure of WSDL files are described in Chapter 17.
Services are often surfaced through adapters that take an existing piece of functionality and "adapt" it to the SOA world so it can interact with other SOA Suite components. An example of an adapter is the file adapter that allows a file to be read or written to. The act of reading or writing the file is encapsulated into a service interface. This service interface can then be used to receive service requests by reading a file or to create service requests by writing a file.
Out of the box the SOA Suite includes licenses for the following adapters:
The database adapter and the file adapter are explored in more detail in Chapter 3 and Chapter 11. There is also support for other non-SOAP transports and styles such as plain HTTP, REST, plain TCP/IP, and Java.
Services are the most important part of service-oriented architecture and in this book we focus on how to define their interfaces and how to best assemble services together to create composite services with a value beyond the functionality on a single atomic service.
ESB—service abstraction layer
To avoid service location dependencies it is desirable to access services through an Enterprise Service Bus (ESB). This provides a layer of abstraction over the service and allows transformation of data between formats. The ESB is aware of the physical endpoint locations of services and acts to virtualize services.
Services may be viewed as being plugged into the service bus.
An Enterprise Service Bus is responsible for routing and transforming service requests between components. By abstracting the physical location of a service an ESB allows services to be moved to different locations without impacting the clients of those services. The ability of an ESB to transform data from one format to another also allows for changes in service contracts to be accommodated without recoding client services. The service bus may also be used to validate that messages conform to interface contracts and to enrich messages by adding additional information to them as part of the message transformation process.
Oracle Service Bus and Oracle ESB
Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus) and the Oracle ESB. The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle ESB, which will be known as the Mediator component in the 11g release of SOA Suite, but we believe that for most cases the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, the current release of the Oracle Service Bus, only executes on the Oracle WebLogic platform. So when running SOA Suite on non-Oracle platforms there are two choices:
We will focus on the Oracle Service Bus in this book, as that is the preferred direction for ESB functionality within the SOA Suite. Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.
Service orchestration—BPEL Process Manager
In order to build composite services, that is services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.
Business Process Execution Language is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL Process Manager in SOA Suite includes support for the BPEL 1.1 standard with some constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running, seconds and minutes, or long running, hours and days.
The BPEL standard says nothing about how people interact with it, but BPEL Process Manager includes a Human Workflow component that provides support for human interaction with processes.
The BPEL Process Manager may also be purchased as a standalone component, in which case it ships with the Human Workflow support and the same adapters as included in the SOA Suite.
We explore the BPEL Process Manager in more detail in Chapter 5 and Chapter 14. Human workflow is examined in Chapter 6 and Chapter 15.
Oracle also package the BPEL Process Manager with the Oracle Business Process Management (BPM) Suite. This package includes the former Aqualogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle position BPEL as a system-centric process engine with support for human workflow while BPM is positioned as human-centric process engine with support for system interaction.
Rules
Business decision making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.
SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository. The rules engine is also included in the Oracle Application Server Enterprise Edition.
In Chapters 7 and 16 we investigate how to use the rules engine.
Security and monitoring—OWSM
One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.
The Oracle Web Services Manager has several roles to play within an SOA. Firstly it serves as a policy enforcement point for security, ensuring that only requests that comply with policy are accepted. Secondly it provides a monitoring service to ensure that services are compliant with their service level agreements.
Security policy may also be applied through the Service Bus although policy definition is currently different between the Service Bus and OWSM the direction is for Oracle to have a common policy management in a future release.
Applying security policies is covered in Chapter 20.
Active monitoring–BAM
It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.
