Chapter 6: Architectural Styles
J.D. Meier, Alex Homer, David Hill,
Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- Learn key architectural styles.
- Learn about the scenarios, key principles, and benefits of each style.
- Learn how to choose an appropriate architectural style for your application.
This chapter describes and discusses the architectural styles commonly used for applications today. These styles include client/server, layered architecture, component-based architecture, message-bus architecture, and service-oriented architecture (SOA). For
each style, you will find an overview, key principles, major benefits, and examples of its use. It is important to understand that the styles describe different aspects of applications. For example, some architectural styles describe deployment patterns, some
describe structure and design factors, and others describe communication factors. Therefore, a typical application will usually implement more than one of the styles described in this chapter.
What Is an Architectural Style?
An architectural style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently
You can think of architecture styles as sets of principles that shape an application. An architectural pattern, or as it is sometimes called, an architectural style was defined by Garlan and Shaw (January 1994, CMU-CS-94-166, available at
“…a family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they
can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.”
_David Garlan and Mary Shaw, January 1994, CMU-CS-94-166_
Benefits of Architectural Styles
Architectural styles provide a few benefits. The most important is that they provide a common language. Another benefit is that they provide a way to have a conversation that is technology agnostic. This allows you to facilitate a higher level of conversation
that is inclusive of patterns and principles, without getting into the specifics. For example, by using architecture styles, you can talk about client-server vs. N-Tier.
Architecture Style Frame
Architectural styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architectural styles.
Table 1 Architectural style frame
||Service-Oriented Architecture (SOA), Message Bus, Pipes and Filters
||Client/server, 3-Tier, N-Tier
||Domain Model, Gateway
||Component-Based, Object-Oriented, Layered Architecture
Key Architecture Styles
The following table lists the common architectural styles described in this chapter. It also contains a brief description of each style. Later sections of this chapter contain more details of each style, as well as guidance to help you choose the appropriate
ones for your application.
Table 2 Architectural styles and descriptions
||Segregates the system into two applications, where the client makes a service request to the server.
||Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces.
||Partitions the concerns of the application into stacked groups (layers).
||A software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
|N-tier / 3-tier
||Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
||An architectural style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
||Separates the logic for managing user interaction from the user interface (UI) view and from the data with which the user works.
|Service-Oriented Architecture (SOA)
||Refers to Applications that expose and consume functionality as a service using contracts and messages.
Architecture Style Combination
The architecture of a software system is almost never limited to a single architectural style but is often a combination of architectural styles that form the complete system. For example, you might have an SOA design composed of services developed using a
layered architecture approach and an object-oriented architecture style. The following examples show how combinations of some of these styles can be used to build applications:
A combination of architecture styles will be useful if you are building a public-facing Web application. Employ effective separation of concerns by using the layered architecture style. This will separate your presentation logic from your business logic and
your data access logic. Your organization’s security requirements might make you deploy the application using either the 3-tier deployment or a deployment of more than three tiers. The presentation tier may be deployed in the perimeter network, which sits
between an organization’s internal network and an external network. On your presentation tier (Web server), you might decide on a separated presentation architecture style for your interaction model, such as MVC. From a communication standpoint between your
Web server and application server, you might choose an SOA architecture style and implement message-based communication.
If you are building a desktop application (Windows Forms application), you might prefer to have a client that sends a request to a program on the server. Deploy the client and server using the client/server architecture style. Use the component-based architecture
to decompose the design further into independent components that expose the appropriate communication interfaces. It is recommended that you use the object-oriented approach to improve reuse, testability, and flexibility.
Choosing an Architectural Style
Many factors will influence the architectural styles that you choose. These factors include the capacity of your organization for design and implementation; the capabilities and experience of developers; and the hardware and deployment scenarios available.
The architecture styles are related, so effectively you will be choosing a mix of architecture for your scenario. For example, when choosing a layered architecture, you may also choose to use an object-oriented or component-based design. The following guidelines
will help you to determine the appropriate styles for your applications.
3-Tier/N-Tier Architectural Style
Consider either the N-tier or the 3-tier architectural style if:
- The processing requirements of the layers in the application differ. Processing in one layer could absorb sufficient resources to slow the processing in other layers.
- The security requirements of the layers in the application may differ. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers.
- You want to be able to share business logic between applications.
- You have sufficient hardware to allocate the required number of servers to each tier.
Consider the 3-tier architectural style if:
- You are developing an intranet application where all servers are located within the private network.
- You are developing an Internet application, and security requirements do not restrict implementing business logic within the public-facing Web or application server.
Consider using more than three tiers if:
- Security requirements dictate that business logic cannot be deployed to the perimeter network.
- The application makes heavy use of resources and you want to offload that functionality to another server
Client/Server Architectural Style
Consider the client/server architectural style if:
- Your application is server-based and will support many clients.
- You are creating Web-based applications exposed through a Web browser.
- You are implementing business processes that will be used by people throughout the organization.
- You are creating services for other applications to consume.
- You want to centralize data storage, backup, and management functions.
- Your application must support different client types and different devices.
Component-based Architectural Style
Consider the component-based architectural style if:
- You already have suitable components, or can obtain suitable components from third-party suppliers.
- Your application will predominantly execute procedural-style functions, perhaps with little or no data input.
- You want to be able to combine components written in different code languages.
- You want to create a pluggable architecture that allows you to easily replace and update individual components.
Layered Architectural Style
Consider the layered architectural style if:
- You already have suitable layers built for other applications that you can reuse.
- You already have applications that expose suitable business processes through service interfaces.
- Your application is complex, and the high-level design demands separation so that teams can focus on different areas of functionality.
- Your application must support different client types and different devices.
- You want to implement complex and/or configurable business rules and processes.
Message-bus Architectural Style
Consider the message-bus architectural style if:
- You have existing applications that interoperate with each other to perform tasks.
- You are implementing a task that requires interaction with external applications.
- You are implementing a task that requires interaction with applications hosted in different environments.
- You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation.
Separated Presentation Architectural Style
Consider the Separated Presentation architectural style if:
- You want improved testability and simpler maintenance of UI functionality.
- You want to separate the task of creating the UI from the logic code that drives it.
- Your UI view does not contain any request-processing code.
- Your UI processing code does not implement any business logic.
Object-Oriented Architectural Style
Consider the object-oriented architectural style if:
- You want to model the application based on real-world objects and actions.
- You already have suitable objects and classes that match the design and operational requirements.
- You need to encapsulate logic and data together in reusable components.
- You have complex business logic that requires abstraction and dynamic behavior.
Service-Oriented Architectural (SOA) Style
Consider the SOA style if:
- You have access to suitable services, or can purchase suitable services exposed by a hosting company.
- You want to build applications that compose a variety of services into a single UI.
- You are creating Software plus Services (S+S), Software as a Service (SaaS), or cloud-based applications.
- You need to support message-based communication between segments of the application.
- You need to expose functionality in a platform-independent way.
- You want to take advantage of federated services, such as authentication.
- You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.
- You want to support interoperability and integration.
Architecture Style Summaries
The following are summaries of each of the architecture styles listed earlier in this chapter. Each summary includes a brief description of the architecture style along with key principles, benefits, and some examples.
describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server. Standard networked functions such as e-mail exchange, Web access, and database access are
based on the client/server model.
The client/server architectural style has the following identifying characteristics:
- It is a style for defining distributed systems.
- It involves a separate client and server system, and a connecting network.
- It describes the relationship between the client and one or more servers, with the client making requests to the server, and the server sending responses.
- It can use a range of protocols and data formats to communicate information.
The following are the key principles of the client/server architectural style:
- The client initiates one or more requests, waits for replies, and processes the replies on receipt.
- The client usually connects to one or only a small number of servers at any one time.
- The client interacts directly with the user, perhaps using a graphical UI.
- The server does not initiate any requests.
- The server sends data responses to network requests from connected clients.
- The server typically authorizes the user and then carries out the processing required to generate the result.
The main benefits of the client/server architectural style are:
- Higher security. All data is stored on the server, which generally have offers greater control of security than clients do.
- Centralized data access. Because data is stored only on the server, access and updates to the data are far easier to administer than in other architectural styles.
- Ease of maintenance. Roles and responsibilities of a computing system are distributed among several servers known to each other through a network. This ensures that a client remains unaware and unaffected by a server repair, upgrade, or relocation.
The following are some examples of the client/server architectural style:
- Web browser–based programs running on the Internet or an intranet
- Windows Forms applications that access back-end services
- Applications that access remote data stores, such as e-mail readers, File Transfer Protocol (FTP) clients, and database query tools
- Tools and utilities that manipulate remote systems, such as system management tools and network monitoring tools
Variations on the client/server style include:
- Client-Queue-Client systems. Clients can read data from and send data to a server that acts simply as a queue to store the data. This allows clients to distribute and synchronize files and information.
- Peer-to-Peer (P2P) applications. Developed from the Client-Queue-Client style, the P2P style allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients.
- Application servers. A specialized client/server architectural style where the server hosts and executes applications that a thin client controls through specialized client-installed software.
Component-based architecture describes a software engineering approach to system design and development. It focuses on the decomposition of the design into functional or logical components that expose well-defined communication interfaces. This provides a higher
level of abstraction than object-oriented design principles, and does not focus on object-specific issues such as communication protocols and shared state.
The component-based architectural style has the following identifying characteristics:
- It is a style for designing applications made up of individual components.
- It places the emphasis on decomposing systems into functional or logical components that have well-defined interfaces.
- It defines a design approach that uses discrete components, which communicate through interfaces containing methods, events, and properties.
is a software object specifically designed to achieve a certain purpose. The key principles when designing components are that they should be:
- Reusable. Components are usually designed to be reused in different scenarios in different applications. However, some components may be designed for a specific task.
- Not context-specific. Components are designed to operate in different environments and contexts. Specific information, such as state data, should be passed to the component instead of being included in or accessed by the component.
- Extensible. A component can be extended from existing components to provide new behavior.
- Encapsulated. Components expose interfaces that allow code to use its functionality, and not reveal internal details of the processes or any internal variables or state.
- Independent. Components are designed to have minimal dependencies on other components. Therefore components can be deployed into any appropriate environment without affecting other components or systems.
The following are the main benefits of the component-based architectural style:
- Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.
- Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.
- Ease of development. Components implement well-known interfaces to provide defined functionality, allowing development without** impacting other parts of the system.
- Reusable. The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.
- Mitigation of technical complexity. Components mitigate complexity through the use of a component container and its services. Example component services include component activation, lifetime management, method queuing, eventing, and transactions.
Common types of components used in applications include:
- User interface components, such as grids and buttons, often referred to as “controls.”
- Helper components that expose a specific subset of functions used in other components.
- Components that are infrequency accessed, resource-intensive, and must be activated using the Just in Time (JIT) approach. This is common in remoting or distributed component scenarios.
- Queued components, whose method calls may be executed asynchronously using message queuing and store-and-forward.
Layered architecture focuses on a hierarchical distribution of roles and responsibilities by providing a highly effective separation of concerns. The role indicates the mode and type of interaction with other layers, and the responsibility indicates the functionality
being addressed. For example, a typical Web application design comprises a presentation layer (functionality related to the UI), a Business Layer (business rules processing), and a data layer (functionality related to data access).
The layered architectural style has the following identifying characteristics:
- It describes decomposition of services so that the majority of interactions occur only between neighboring layers.
- The layers of an application may reside on the same physical computer (the same tier), or may be distributed over separate computers (N-tier).
- The components in each layer communicate with components in other layers through well-defined interfaces.
- It has been described as an “inverted pyramid of reuse” where each layer aggregates the responsibilities and abstractions of the layer directly beneath it.
Common principles to apply when designing to use this style or architecture include:
- Abstraction. Layered architecture abstracts the view of the model as whole while providing enough detail to understand the relationship between layers.
- Encapsulation. The design does not make assumptions about data types, methods and properties, and implementation.
- Clearly defined functional layers. The design clearly defines the separation between functionality in each layer. Upper layers such as the presentation layer send commands to lower layers such as the business and data layers, and data flows both
up and down between the layers.
- High cohesion. Each layer contains functionality directly related to the tasks of that layer.
- Reusable. Lower layers have no dependencies on higher layers, allowing them to be reusable in other scenarios.
- Loose coupling. Communication between layers is based on abstraction that provides loose coupling between layers.
The main benefits of the layered architectural style are:
- Abstraction. Layers allow changes to be made at the abstract level. You can increase or decrease the level of abstraction you use in each layer of the hierarchical “stack.”
- Isolation. The layered architectural style allows you to isolate technology upgrades to certain layers in order to reduce risk and impact to the overall system.
- Performance.** Distributing the layers over multiple physical tiers can improve scalability, fault-tolerance, and performance.**
- Testability. Testability benefits from having well-defined layer interfaces as well as the ability to switch between different implementations of the layer interfaces.
- Independent. The layered architectural style removes the requirement to consider hardware and deployment issues and external interface dependencies.
Common types of layered applications include:
- Line of business (LOB) applications, such as accounting and customer-management systems.
- Enterprise Web-based applications and Web sites.
- Enterprise desktop or smart clients with centralized application servers for business logic.
The following are some variations on the layered architectural style:
- Strict layering. Each layer is only allowed to call the layer directly below it.
- Layer skipping. Layers are allowed to call layers deeper than the one directly below them. This is known as
layer skipping, and can increase performance but will impact portability.
- Black-box layering. Layer boundaries and dependencies are strictly defined using interfaces, which supports run-time extension, interception, and improved testability.
- White-box layering. Classes collaborating across layer boundaries are tightly coupled.
Message-bus architecture describes the principle of using a software system that can receive and send messages using one or more communication channels, so that applications can interact without having to know specific details about each other. The most common
implementations of message-bus architecture use either a messaging router or a Publish/Subscribe pattern.
The message-bus architectural style has the following identifying characteristics:
- It is a style for designing applications where interaction between applications is accomplished by passing messages over a common bus.
- Communication between applications using message-bus architecture is normally asynchronous.
- It is often implemented using a messaging system, such as Microsoft Message Queuing (MSMQ).
- Many implementations consist of individual applications that communicate using common schemas and a shared infrastructure for sending and receiving messages.
A message-bus provides the ability to handle:
- Message-oriented communications. All communication between applications is based on messages that use known schemas.
- Complex processing logic. Complex operations can be created by combining a set of smaller operations supporting specific tasks.
- Modifications to processing logic. Because interaction with the bus is based on common schemas and commands, you can insert or remove applications on the bus to change the logic used to process messages.
- Integration with different environments. By using a message-based communication model based on common standards, you can interact with applications developed for different environments, such as Microsoft .NET and Java.
The main benefits of the message-based architectural style are:
- Expandability. Applications can be added to or removed from the bus without having an impact on the existing applications.
- Low complexity. Application complexity is reduced because each application only needs to know how to communicate with the bus.
- Higher performance. Performance is higher due to the absence of intermediaries between communicating applications, limited only by how fast the message bus can move messages.
- Scalability. Multiple instances of the same application can be attached to a bus in order to handle multiple requests at the same time.
- Simplicity. Each application needs to support only a single connection to the message bus instead of multiple connections to other applications.
Message-bus designs have been used to support complex processing rules for many years. The design provides a pluggable architecture that allows you to insert applications into the process, or improve scalability by attaching several instances of the same application
to the bus.
Variations on the message bus style include:
- Enterprise service bus (ESB). Based on message-bus designs, an ESB uses services for communication between the bus and components attached to the bus. An ESB will usually provide services that transform messages from one format to another, allowing
clients that use incompatible message formats to communicate with each other
- Internet service bus (ISB). This is similar to an enterprise service bus, but with applications hosted in the cloud instead of on an enterprise network. A core concept around ISB is the use of Uniform Resource Identifiers (URI) and policies to control
the routing of logic through applications and services in the cloud.
Separated Presentation represents a style for handling requests or user actions, and for manipulating the UI and the application data. This style separates the UI elements from the application workflow and data manipulation. An example of an application of
the Separated Presentation style would be the Model-View-Controller (MVC) pattern. The MVC pattern separates UI processing into three specific roles known as the Model, the View, and the Controller. The Model represents data, the View provides a UI, and the
Controller provides processing logic and coordination between the Model and the View.
A Separated Presentation architectural style has the following identifying characteristics:
- It is a style for designing applications based on well-known design patterns.
- It separates the logic for managing user interaction from the UI view, and from the data with which the user works.
- It allows graphical designers to create a UI, while developers generate the code to drive it.
- It provides support for improved testability. Dividing the functionality into separate roles provides increased opportunities to test the behavior of individual roles.
The following are the key principles of the Separated Presentation architectural style:
- Separation of concerns. The Separated Presentation architectural style separates UI processing concerns into distinct roles; for example, MVC has three roles: the Model, View, and Controller. The Model represents data, the View represents a UI, and
the Controller is used to handle requests and perform operations.
- Improved testability. The Separated Presentation architectural style allows you to build mock objects that mimic the behavior of concrete objects during testing.
- Event-based notification.** The Observer pattern is commonly used to provide notifications to the View when data managed by the Model changes.
- Delegated event handling. The controller handles events triggered from the UI controls in the view.
The main benefits of the Separated Presentation architectural style are:
- Testability. In typical implementations, such as MVC the roles are only classes—they can be unit-tested in the same way as any other class. You can also replace one of these classes with mock objects that provide simulated behavior.
- Reusability. Roles promote reusability. For example, in MVC, the Controller can be reused with other compatible Views, and a View can be reused with other compatible Controllers.
- Manageability. Separation of core concerns helps to identify dependencies and organizes the code into more manageable sections.
Some examples of the MVC architectural style are:
- Model View Controller (MVC) pattern
- Passive View pattern
- Supervising ViewController pattern
N-Tier / 3-Tier Architecture
This architectural deployment style describes the separation of functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer. It evolved through the component-oriented
approach, generally using platform-specific methods for communication instead of a message-based approach.
The following are the key principles of the N-tier/3-tier architectural style:
- It is a style for defining the deployment of the layers of an application.
- N-tier application architecture is characterized by the functional decomposition of applications, service components, and their distributed deployment, providing improved scalability, availability, manageability, and resource utilization.
- Each tier is completely independent of all other tiers, except for those immediately above and below it. The nth tier only has to know how to handle a request from the n+1th tier, how to forward that request on to the n-1th tier (if there is one), and how
to handle the results of the request.
- N-tier architectures have at least three separate logical layers, or parts. Each layer has specific functionality that it is responsible for, and located on, physically different servers.
- A layer is deployed on a tier if more than one service or application is dependent on the functionality exposed by the layer.
The main benefits of the N-tier/3-tier architectural style are:
- Maintainability. Because each tier is independent of the other tiers, updates or changes can be carried out without affecting the application as a whole.
- Scalability. Because tiers are based on the deployment of layers, scaling out an application is reasonably straightforward.
- Flexibility. Because each tier can be managed or scaled independently, flexibility is increased.
- Availability. Applications can exploit the modular architecture of enabling systems using easily scalable components, which increases availability.
Some examples of the N-tier/3-tier architectural style are:
- A typical financial Web application, where security is important and the business layer needs to be deployed behind a firewall, which forces the deployment of the presentation layer on a separate tier in the perimeter.
- A typical rich client connected application, where the presentation layer is deployed on client machines and the business layer and data access layer are deployed on the server.
Object-oriented architecture is a programming style based on the division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object. An object-oriented design
views a system as a series of cooperating objects, instead of a set of routines or procedural instructions. Objects are discrete, independent, and loosely coupled; they communicate through interfaces, and by sending and receiving messages.
An object-oriented architectural style has the following identifying characteristics:
- It is a style for designing applications based on discrete units of logical and reusable code.
- It describes the use of self-sufficient objects that contain data and the behavior to work with that data, and have a distinct role or responsibility.
- It emphasizes reusability through encapsulation, modularity, polymorphism, and inheritance.
- It contrasts with the procedural approach, where there is a predefined sequence of tasks and actions. The object-oriented approach uses the concept of objects interacting with each other to perform a range of tasks.
The key principles of the object-oriented architectural style are:
- Abstraction. This allows you to reduce a complex operation into a generalization that retains the base characteristics of the operation. For example, an abstract interface can be a well-known definition that supports data access operations using
simple methods such as Get and Update. Another form of abstraction could be metadata used to provide a mapping between two formats that hold structured data.
- Composition. Objects can be assembled from other objects, and can choose to hide these “internal” objects from other classes or expose them as simple interfaces.
- Inheritance. Objects can inherit from other objects, and use functionality in the base object or override it to implement new behavior. Moreover, inheritance makes maintenance and updates easier, as changes to the base object are propagated automatically
to the inheriting objects.
- Encapsulation. Objects expose only the functionality through methods, properties, and events, and hide the internal details such as state and variables to other objects. This makes it easier to update or replace objects, providing that their interfaces
are compatible, without affecting other objects and code.
- Polymorphism. This allows you to override the behavior of a base type that supports operations in your application.
- Decoupling. This allows objects to be decoupled from the consumer by defining an abstract interface that the object implements and the consumer know about. This allows you to provide alternative implementations without affecting consumers of the
The main benefits of the object-oriented architectural style are:
- Understandable. Object-oriented design maps the application more closely to the real-world objects, making it more understandable.
- Reusable. Object-oriented design provides for reusability through polymorphism and abstraction.
- Testable. Object-oriented design provides for improved testability through encapsulation.
- Extensible. Encapsulation, polymorphism, and abstraction ensure that change in the representation of data does not affect the interfaces that it exposes.
Common uses of the object-oriented style include:
- Defining objects that represent real-world artifacts within a business domain, such as a customer or an order.
- Defining an object model that supports complex scientific or financial operations.
Service-Oriented Architecture (SOA)
Service-oriented architecture enables application functionality to be provided and consumed as a set of services. Services use a standards-based form of interface that can be invoked, published, and discovered. SOA services are focused on providing a schema
and message-based interaction with an application. SOA services provide application-scoped interfaces and not component or object-based interfaces. In other words, a SOA service should not be treated as a component-based service provider.
The SOA style has the following identifying characteristics:
- Interaction with a service is loosely-coupled.
- It can involve business processes packaged into interoperable services.
- Clients and other services can access local services running on the same tier.
- Clients and other services access remote services over a connecting network.
- It can use a range of protocols and data formats to communicate information.
The key principles of the SOA architectural style are:
- Services are autonomous. Each SOA service is maintained, developed, deployed, and versioned independently.
- Services are distributable. SOA services can be located anywhere on a network, locally or remotely, as long as the network supports the required communication protocols.
- Services are loosely-coupled. Each SOA service is independent of others, and can be replaced or updated without breaking applications that use it as long as the interface is still compatible.
- Services share schema and contract, not class. SOA services share contracts and schemas when they communicate, not internal classes.
- Compatibility is based on policy. Policy in this case means definition of features such as transport, protocol, and security.
The main benefits of the SOA architectural style are:
- Domain alignment. Reuse of common services with standard interfaces increases business and technology opportunities and reduces cost.
- Abstraction. Services are autonomous and accessed through a formal contract, which provides loose coupling and abstraction.
- Discoverability. Services can expose descriptions that allow other applications and services to locate them and automatically determine the interface.
Common examples of service-oriented application include:
- Sharing of medical data (Harvard Medical School)
- Reservation system (Starwood Hotels and Resorts)
- Workflow system (State Children’s Health Insurance Program)
For more information about architectural styles, see the following articles: