Home > Store

Patterns of Enterprise Application Architecture

Best Value Purchase

Book + eBook Bundle

  • Your Price: $78.53
  • List Price: $134.38
  • Includes EPUB and PDF
  • About eBook Formats
  • This eBook includes the following formats, accessible from your Account page after purchase:

    ePub EPUB The open industry format known for its reflowable content and usability on supported mobile devices.

    Adobe Reader PDF The popular standard, used most often with the free Acrobat® Reader® software.

    This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.

More Purchase Options

Book

  • Your Price: $55.99
  • List Price: $69.99
  • Usually ships in 24 hours.

eBook (Watermarked)

  • Your Price: $51.51
  • List Price: $64.39
  • Includes EPUB and PDF
  • About eBook Formats
  • This eBook includes the following formats, accessible from your Account page after purchase:

    ePub EPUB The open industry format known for its reflowable content and usability on supported mobile devices.

    Adobe Reader PDF The popular standard, used most often with the free Acrobat® Reader® software.

    This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.

Also available in other formats.

Register your product to gain access to bonus material or receive a coupon.

About

Features

A handbook for enterprise system developers guiding them through the intricacies and lessons learned in application development.

° The latest book from noted technology guru Martin Fowler

° Provides proven solutions to the everyday problems facing information systems developers

° Patterns are supported by code examples, in both Java and C#

Description

  • Copyright 2003
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 560
  • Edition: 1st
  • Book
  • ISBN-10: 0-321-12742-0
  • ISBN-13: 978-0-321-12742-6

The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned.

Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology--from Smalltalk to CORBA to Java to .NET--the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform.

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book's lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

The topics covered include

·  Dividing an enterprise application into layers

·  The major approaches to organizing business logic

·  An in-depth treatment of mapping between objects and relational databases

·  Using Model-View-Controller to organize a Web presentation

·  Handling concurrency for data that spans multiple transactions

·  Designing distributed object interfaces

Sample Content

Online Sample Chapters

Enterprise Application Architecture: Mapping to Relational Databases

Framework Design Guidelines: Data Source Architectural Patterns

Framework Design Guidelines: Domain Logic Patterns

Downloadable Sample Chapter

Click below for Sample Chapter(s) related to this title:
Sample Chapter 3

Sample Pages

Download the sample pages (includes Chapter 3 and Index)

Table of Contents



Preface.

Who This Book Is For.

Acknowledgements.

Colophon.



Introduction.

Architecture.

Enterprise Applications.

Kinds of Enterprise Application.

Thinking About Performance.

Patterns.

The Structure of the Patterns.

Limitations of These Patterns.

I. THE NARRATIVES.

1. Layering.

The Evolution of Layers in Enterprise Applications.

The Three Principal Layers.

Choosing Where to Run Your Layers.

2. Organizing Domain Logic.

Making a Choice.

Service Layer.

3. Mapping to Relational Databases.

Architectural Patterns.

The Behavioral Problem.

Reading in Data

Structural Mapping Patterns.

Mapping Relationships.

Inheritance.

Building the Mapping.

Double Mapping.

Using Metadata.

Database Connections.

Some Miscellaneous Points.

Further Reading.

4. Web Presentation.

View Patterns.

Input Controller Patterns.

Further Reading.

5. Concurrency (by Martin Fowler and David Rice).

Concurrency Problems.

Execution Contexts.

Isolation and Immutability.

Optimistic and Pessimistic Concurrency Control.

Preventing Inconsistent Reads.

Deadlocks.

Transactions.

ACID.

Transactional Resources.

Reducing Transaction Isolation for Liveness.

Business and System Transactions.

Patterns for Offline Concurrency Control.

Application Server Concurrency.

Further Reading.

6. Session State.

The Value of Statelessness.

Session State.

Ways to Store Session State.

7. Distribution Strategies.

The Allure of Distributed Objects.

Remote and Local Interfaces.

Where You Have to Distribute.

Working with the Distribution Boundary.

Interfaces for Distribution.

8. Putting it all Together.

Starting With the Domain Layer.

Down to the Data Source.

Data Source for Transaction Script.

Data Source Table Module (125).

Data Source for Domain Model (116).

The Presentation Layer.

Some Technology-Specific Advice.

Java and J2EE.

.NET.

Stored Procedures.

Web Services.

Other Layering Schemes.

II. THE PATTERNS.

9. Domain Logic Patterns.

Transaction Script.

How It Works.

When to Use It.

The Revenue Recognition Problem.

Example: Revenue Recognition (Java).

Domain Model.

How It Works.

When to Use It.

Further Reading.

Example: Revenue Recognition (Java).

Table Module.

How It Works.

When to Use It.

Example: Revenue Recognition with a Table Module (C#).

Service Layer(by Randy Stafford).

How It Works.

When to Use It.

Further Reading.

Example: Revenue Recognition (Java).

10. Data Source Architectural Patterns.

Table Data Gateway.

How It Works.

When to Use It.

Further Reading.

Example: Person Gateway (C#).

Example: Using ADO.NET Data Sets (C#).

Row Data Gateway.

How It Works.

When to Use It.

Example: A Person Record (Java).

Example: A Data Holder for a Domain Object (Java).

Active Record.

How It Works.

When to Use It.

Example: A Simple Person (Java).

Data Mapper.

How It Works.

When to Use It.

Example: A Simple Database Mapper (Java).

Example: Separating the Finders (Java).

Example: Creating an Empty Object (Java).

11. Object-Relational Behavioral Patterns.

Unit of Work.

How It Works.

When to Use It.

Example: Unit of Work with Object Registration (Java) (by David Rice).

Identity Map.

How It Works.

When to Use It.

Example: Methods for an Identity Map (Java).

Lazy Load.

How It Works.

When to Use It.

Example: Lazy Initialization (Java).

Example: Virtual Proxy (Java).

Example: Using a Value Holder (Java).

Example: Using Ghosts (C#).

12. Object-Relational Structural Patterns.

Identity Field.

How It Works.

When to Use It.

Further Reading.

Example: Integral Key (C#).

Example: Using a Key Table (Java).

Example: Using a Compound Key (Java).

Foreign Key Mapping.

How It Works.

When to Use It.

Example: Single-Valued Reference (Java).

Example: Multitable Find (Java).

Example: Collection of References (C#).

Association Table Mapping.

How It Works.

When to Use It.

Example: Employees and Skills (C#).

Example: Using Direct SQL (Java).

Example: Using a Single Query for Multiple Employees (Java) (by Matt Foemmel and Martin Fowler).

Dependent Mapping.

How It Works.

When to Use It.

Example: Albums and Tracks (Java).

Embedded Value.

How It Works.

When to Use It.

Further Reading.

Example: Simple Value Object (Java).

Serialized LOB.

How It Works.

When to Use It.

Example: Serializing a Department Hierarchy in XML (Java).

Single Table Inheritance.

How It Works.

When to Use It.

Example: A Single Table for Players (C#).

Loading an Object from the Database.

Class Table Inheritance.

How It Works.

When to Use It.

Further Reading.

Example: Players and Their Kin (C#).

Concrete Table Inheritance.

How It Works.

When to Use It.

Example: Concrete Players (C#).

Inheritance Mappers.

How It Works.

When to Use It.

13. Object-Relational Metadata Mapping Patterns.

Metadata Mapping.

How It Works.

When to Use It.

Example: Using Metadata and Reflection (Java).

Query Object.

How It Works.

When to Use It.

Further Reading.

Example: A Simple Query Object (Java).

Repository (by Edward Hieatt and Rob Mee).

How It Works.

When to Use It.

Further Reading.

Example: Finding a Person's Dependents (Java).

Example: Swapping Repository Strategies (Java).

14. Web Presentation Patterns.

Model View Controller.

How It Works.

When to Use It.

Page Controller.

How It Works.

When to Use It.

Example: Simple Display with a Servlet Controller and a JSP View (Java).

Example: Using a JSP as a Handler (Java).

Example: Page Handler with a Code Behind (C#).

Front Controller.

How It Works.

When to Use It.

Further Reading.

Example: Simple Display (Java).

Template View.

How It Works.

When to Use It.

Example: Using a JSP as a View with a Separate Controller (Java).

Example: ASP.NET Server Page (C#).

Transform View.

How It Works.

When to Use It.

Example: Simple Transform (Java).

Two Step View.

How It Works.

When to Use It.

Example: Two Stage XSLT (XSLT).

Example: JSP and Custom Tags (Java).

Application Controller.

How It Works.

When to Use It.

Further Reading.

Example: State Model Application Controller (Java).

15. Distribution Patterns.

Remote Facade.

How It Works.

When to Use It.

Example: Using a Java Session Bean as a Remote Facade (Java).

Example: Web Service (C#).

Data Transfer Object.

How It Works.

When to Use It.

Further Reading.

Example: Transferring Information about Albums (Java).

Example: Serializing Using XML (Java).

16. Offline Concurrency Patterns.

Optimistic Offline Lock (by David Rice).

How It Works.

When to Use It.

Example: Domain Layer with Data Mappers (165) (Java).

Pessimistic Offline Lock (by David Rice).

How It Works.

When to Use It.

Example: Simple Lock Manager (Java).

Coarse-Grained Lock (by David Rice and Matt Foemmel).

How It Works.

When to Use It.

Example: Shared Optimistic Offline Lock (416) (Java).

Example: Shared Pessimistic Offline Lock (426) (Java).

Example: Root Optimistic Offline Lock (416) (Java).

Implicit Lock (by David Rice).

How It Works.

When to Use It.

Example: Implicit Pessimistic Offline Lock (426) (Java).

17. Session State Patterns.

Client Session State.

How It Works.

When to Use It.

Server Session State.

How It Works.

When to Use It.

Database Session State.

How It Works.

When to Use It.

18. Base Patterns.

Gateway.

How It Works.

When to Use It.

Example: A Gateway to a Proprietary Messaging Service (Java).

Mapper.

How It Works.

When to Use It.

Layer Supertype.

How It Works.

When to Use It.

Example: Domain Object (Java).

Separated Interface.

How It Works.

When to Use It.

Registry.

How It Works.

When to Use It.

Example: A Singleton Registry (Java).

Example: Thread-Safe Registry (Java) (by Matt Foemmel and Martin Fowler).

Value Object.

How It Works.

When to Use It.

Money.

How It Works.

When to Use It.

Example: A Money Class (Java) (by Matt Foemmel and Martin Fowler).

Special Case.

How It Works.

When to Use It.

Further Reading.

Example: A Simple Null Object (C#).

Plugin (by David Rice and Matt Foemmel).

How It Works.

When to Use It.

Example: An Id Generator (Java).

Service Stub (by David Rice).

How It Works.

When to Use It.

Example: Sales Tax Service (Java).

Record Set.

How It Works.

When to Use It.

References

Index. 0321127420T10162002

Preface

In the spring of 1999 I flew to Chicago to consult on a project being done by ThoughtWorks, a small but rapidly growing application development company. The project was one of those ambitious enterprise application projects: a back-end leasing system. Essentially what this system does is to deal with everything that happens to a lease after you've signed on the dotted line. It has to deal with sending out bills, handling someone upgrading one of the assets on the lease, chasing people who don't pay their bills on time, and figuring out what happens when someone returns the assets early. That doesn't sound too bad until you realize that leasing agreements are infinitely varied and horrendously complicated. The business "logic" rarely fits any logical pattern, because after all its written by business people to capture business, where odd small variations can make all the difference in winning a deal. Each of those little victories is yet more complexity to the system.

That's the kind of thing that gets me excited: how to take all that complexity and come up with system of objects that can make more tractable. Indeed I belive that the primary benefit of objects is in making complex logic tractable. Developing a good Domain Model (133) for a complex business problem is difficult, but wonderfully satisfying.

Yet that's not the end of the problem. Such a domain model has to persisted to a database, and like many projects we were using a relational database. We also had to connect this model to a user interface, provide support to allow remote applications to use our software, and integrate our software with third party packages. All of this on a new technology called J2EE which nobody in the world had any real experience in using.

Even though this technology was new, we did have the benefit of experience. I'd been doing this kind of thing for ages now with C++, Smalltalk, and CORBA. Many of the ThoughtWorkers had a lot of experience with Forte. We already had the key architectural ideas in our heads, we just had to figure out how to apply them to J2EE. Looking back on it three years later the design is not perfect, but it's stood the test of time pretty damn well.

That's the kind of situation that is where this book comes in. Over the years I've seen many enterprise application projects. These projects often contain similar design ideas which have proven to be effective ways to deal with the inevitable complexity that enterprise applications possess. This book is a starting point to capture these design ideas as patterns.

The book is organized in two parts. The first part is a set of narrative chapters on a number of important topics in the design of enterprise applications. They introduce various problems in the architecture of enterprise applications and their solutions. However the narrative chapters don't go into much detail on these solutions. The details of the solutions are in the second part, organized as patterns. These patterns are a reference and I don't expect you to read them cover to cover. My intention is that you can read the narrative chapters in part one from start to finish to get a broad picture of what the book covers, then you can dip into the patterns chapters of part two as your interest and needs drive you. So this book is a short narrative book and a longer reference book combined into one.

This is a book on enterprise application design. Enterprise applications are about the display, manipulation and storage of large amounts of often complex data and the support or automation of business processes with that data. Examples include reservation systems, financial systems, supply chain systems, and many of the systems that run modern business. Enterprise applications have their own particular challenges and solutions. They are a different animal to embedded systems, control systems, telecoms, or desktop productivity software. So if you work in of these other fields, there's nothing really in this book for you (unless you want to get a feel for what enterprise applications are like.) For a general book on software architecture I'd recommend POSA.

There are many architectural issues in building enterprise applications. I'm afraid this book can't be a comprehensive guide to them. In building software I'm a great believer in iterative development. At the heart of iterative development is the notion that you should deliver software as soon as you have something useful to the user, even if it's not complete. Although there are many differences between writing a book and writing software, this notion is one that I think the two share. So this book is an incomplete but (I trust) useful compendium of advice on enterprise application architecture. The primary topics I talk about are:

  • layering of enterprise applications
  • how to structure domain (business) logic
  • the structure of a web user interface
  • how to link in-memory modules (particularly objects) to a relational database
  • how to handle session state in stateless environments
  • some principles of distribution
  • The list of things I don't talk about is rather longer. I really fancied writing about organizing validation, incorporating messaging and asynchronous communication, security, error handling, clustering, application integration, architectural refactoring, structuring rich-client user interfaces, amongst others. I can only hope to see some patterns appear for this work in the near future. However due to space, time, and lack of cogitation you won't find them in this book. Perhaps I'll do a second volume someday and get into these topics, or maybe someone else will fill these, and other, gaps.

    Of these, dealing with message based communication is a particularly big issue. Increasingly people who are integrating multiple applications are making use of asynchronous message based communication approaches. There's much to said for using them within an application as well.

    This book is not intended to be specific for any particular software platform. I first came across these patterns while working with Smalltalk, C++, and CORBA in the late 80's and early 90's. In the late 90's I started to do extensive work in Java and found these patterns applied well both to early Java/CORBA systems and later J2EE based work. More recently I've been doing some initial work with Microsoft's .NET platform and find the patterns apply again. My ThoughtWorks colleagues have also introduced their experiences, particularly with Forte. I can't claim generality across all platforms that ever have been or will be used for enterprise applications, but so far these patterns have shown enough recurrence to be useful.

    I have provided code examples for most of these patterns. My choice of language for the code examples is based on what I think most readers are likely to be able to read and understand. Java's a good choice here. Anyone who can read C or C++ can read Java, yet Java is much less complex than C++. Essentially most C++ programmers can read Java but not vice versa. I'm an object bigot, so inevitably lean to an OO language. As a result most of the code examples are in Java. As I was working on the book Microsoft started stabilizing their .NET environment, and their C# language has most of the same properties as Java for an author. So I did some of the code examples in C# as well, although that does introduce some risk since developers don't have much experience with .NET yet and so the idioms for using it well are less mature. Both are C-based languages so if you can read one you should be able to read both, even if you aren't deeply into that language or platform. My aim was to use a language that the largest amount of software developers can read, even if it's not their primary or preferred language. (My apologies to those who like Smalltalk, Delphi, Visual Basic, Perl, Python, Ruby, COBOL or any other language. I know you think you know a better language than Java or C#, all I can say is I do too!)

    The examples are there for inspiration and explanation of the ideas in the patterns. They are not canned solutions, in all cases you'll need to do a fair bit of work to fit them into your application. Patterns are useful starting points, but they are not destinations.

    Who This book Is For

    I've written this book for programmers, designers, and architects who are building enterprise applications and who want to either improve their understanding of these architectural issues or improve their communication about them.

    I'm assuming that most of my readers will fall into two groups: either those with modest needs who are looking to build their own software to handle these issues, or readers with more demanding needs who will be using a tool. For those of modest needs, my intention is that these patters should get you started. In many areas you'll need more than the patterns will give you, but my intention is to provide more of a head start in this field than I got. For tool users I hope this book will be useful to give you some idea of what's happening under the hood, but also help you in making choices between which of the tool supported patterns to use. Using, say, an object-relational mapping tool still means you have to make decisions about how to map certain situations. Reading the patterns should give you some guidance in making the choices.

    There is a third category, those with demanding needs who want to build their own software for these problems. The first thing I'd say here is look carefully at using tools. I've seen more than one project get sucked into a long exercise at building frameworks which weren't what project was really about. If you're still convinced, go ahead. Remember in this case that many of the code examples in this book are deliberately simplified to help understanding, and you'll find you'll need to do a lot tweaking to handle the greater demands that you'll face.

    Since patterns are common solutions to recurring problems, there's a good chance that you'll have already come across some of them. If you've been working in enterprise applications for a while, you may well know most of them. I'm not claiming to have anything new in this book. Indeed I claim the opposite--this is a book of (for our industry) old ideas. If you're new to this field I hope you'll like this book to help you learn about these techniques. If you're more familiar with the techniques I hope you'll like this book because it helps you communicate and teach these ideas to others. An important part of patterns is trying to build a common vocabulary, so you can say that this class is a Remote Facade (413) and other designers know what you mean.

    Martin Fowler, Melrose MA, May 2002
    http://martinfowler.com


    0321127420P08202002

    Index

    Click below to download the Index file related to this title:
    Index

    Updates

    Submit Errata

    More Information

    InformIT Promotional Mailings & Special Offers

    I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

    Overview


    Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

    This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

    Collection and Use of Information


    To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

    Questions and Inquiries

    For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

    Online Store

    For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

    Surveys

    Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

    Contests and Drawings

    Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

    Newsletters

    If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

    Service Announcements

    On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

    Customer Service

    We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

    Other Collection and Use of Information


    Application and System Logs

    Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

    Web Analytics

    Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

    Cookies and Related Technologies

    This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

    Do Not Track

    This site currently does not respond to Do Not Track signals.

    Security


    Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

    Children


    This site is not directed to children under the age of 13.

    Marketing


    Pearson may send or direct marketing communications to users, provided that

    • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
    • Such marketing is consistent with applicable law and Pearson's legal obligations.
    • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
    • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

    Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

    Correcting/Updating Personal Information


    If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

    Choice/Opt-out


    Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

    Sale of Personal Information


    Pearson does not rent or sell personal information in exchange for any payment of money.

    While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

    Supplemental Privacy Statement for California Residents


    California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

    Sharing and Disclosure


    Pearson may disclose personal information, as follows:

    • As required by law.
    • With the consent of the individual (or their parent, if the individual is a minor)
    • In response to a subpoena, court order or legal process, to the extent permitted or required by law
    • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
    • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
    • To investigate or address actual or suspected fraud or other illegal activities
    • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
    • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
    • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

    Links


    This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

    Requests and Contact


    Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

    Changes to this Privacy Notice


    We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

    Last Update: November 17, 2020