Software Architecture and Project Management module III : PATTERN OF ENTERPRISE

Software Architecture andSoftware Architecture and
Project ManagementProject Management
1
Module 3: Patterns
By
SREEJA RAJESH
Department of Computer Science & Engineering
Jyothi Engineering College, Kerala

MODULE III (Contents)MODULE III (Contents)
Object Management Patterns Adaptation Patterns,
Communication Patterns, Architectural Patterns,
 Structural Patterns,
Patterns for Distribution,
Patterns for Interactive Systems Adaptable Systems,
 Frameworks and Patterns,
Analysis Patterns Patterns for Concurrent and Networked Objects,
Patterns for Resource Management,
Pattern Languages,
Patterns for Distributed Computing.

3
Communication PatternsCommunication Patterns
Communication patterns are modes of
communication that we use frequently in
certain situations or with certain people.
Some patterns may be prevalent, that is,
appearing in most communications regardless of
the situation, while many are situation-specific,
that is, used with certain people (friends,
spouse, children, boss) or in certain situations
(at work, in conflict, in fear).

4
Communication patterns can include all of the
following and much more:
 Apologising frequently
 Self-criticism
Criticism of others
Complaining
Self-justification
Blaming (eg. If she hadn't forgotten the book, I
wouldn't be angry.)
Peace-making (eg. It's alright. It didn't matter
anyway. She didn't mean it.)
COMMUNICATION PATTERNSCOMMUNICATION PATTERNS

5
 Praising (sincere or false)
 Avoiding
 Judging/labelling (usually begins with "You're…"
or "Why are you so …?" or "If only you
weren't so…")
 Lecturing
 Listening
 Questioning (really asking to learn, or
interrogating)
 Insulting or otherwise trying to intimidate or
belittle

6
 Supporting (eg. You can do it. Of course
you're a kind man.)
 Self-disclosing (explaining one's own thoughts,
motives, feelings, needs etc)
 Self-concealing (hiding one's true thoughts,
feelings, needs, motives etc.)
 Gossiping (talking about others)
 Expressing emotion by yelling, crying, throwing
things, banging doors etc.

7
1. Forward-Receiver
2. Client-Dispatcher Server

8
FORWARD-RECEIVERFORWARD-RECEIVER
 The Forwarder-Receiver design pattern provides transparent
inter-process communication for software systems with a
peer-to-peer interaction model. It introduces forwarders and
receivers to decouple peers from the underlying
communication mechanism.
 Distributed peers collaborate to solve a particular problem. A
peer may act as a client, requesting services, as a server,
providing services, or both.
 The details of the underlying inter-process communication
mechanism for sending or receiving messages (such as TCP/IP,
sockets or message queues) are hidden from the peers by
encapsulating all system-specific functionality into separate
components. Examples of such functionality are the mapping of
names to physical locations, the establishment of
communication channels, or the marshaling and unmarshaling
of messages.

9
CLIENT-DISPATCHER SERVERCLIENT-DISPATCHER SERVER
 The Client-Dispatcher-Server design pattern introduces an
intermediate layer between clients and servers, the dispatcher
component. It provides location transparency by means of a name
service, and hides the details of the establishment of the
communication connection between clients and servers.
 An example of this pattern would be an information retrieval
system where the information providers are both on a local network
and distributed over the world. To access an individual information
provider it is necessary to specify its location and the service to be
executed. When an information provider receives a request from a
client application it runs the appropriate service and returns the
requested information to the client.

STRUCTURAL PATTERNSSTRUCTURAL PATTERNS
Structural patterns are concerned with
how classes and objects are composed to
form larger structures.
There are seven patterns that make up
the structural group, each with the role
of building flexibility, longevity, and
security into computer software.
10

SEVEN STRUCTURAL PATTERNSSEVEN STRUCTURAL PATTERNS
1. Decorator
2. Proxy
3. Bridge
4. Composite
5. Flyweight
6. Adapter
7. Facade
11

PURPOSES OF STRUCTURAL PATTERNSPURPOSES OF STRUCTURAL PATTERNS
Add new functionality dynamically to
existing objects, or remove it (Decorator).
 Control access to an object (Proxy).
 Create expensive objects on demand
(Proxy).
 Enable development of the interface and
implementation of a component to proceed
independently (Bridge).
 Match otherwise incompatible interfaces
(Adapter).
12

PURPOSES OF STRUCTURALPURPOSES OF STRUCTURAL
PATTERNSPATTERNS
 Reduce the cost of working with large
numbers of very small objects (Flyweight).
 Reorganize a system with many subsystems
into identifiable layers with single entry
points (Façade).
 Select or switch implementations at
runtime (Bridge).
 Simplify the interface to a complex
subsystem (Façade).
 Treat single objects and composite objects
in the same way (Composite).
13

1. DECORATOR PATTERN1. DECORATOR PATTERN
The role of the Decorator pattern is to
provide a way of attaching new state and
behavior to an object dynamically.
The object does not know it is being
“decorated,” which makes this a useful
pattern for evolving systems.
14

DECORATOR PATTERNSDECORATOR PATTERNS
15

DECORATOR PATTERN UML DIAGRAMDECORATOR PATTERN UML DIAGRAM
Component : An original class of objects
that can have operations added or modified
(there may be more than one such class)
Operation: An operation in IComponent
objects that can be replaced (there may be
several operations)
16

Icomponent: The interface that identifies
the classes of objects that can be decorated
(Component is one of these)
Decorator: A class that conforms to the
IComponent interface and adds state and/or
behavior (there may be more than one such
class)
17

The center of the UML diagram is the Decorator class. It includes
two types of relationships with the IComponent interface:
1. Is-a
2. Has-a
 The is-a relationship is shown by a dotted arrow from the
Decorator to IComponent, indicating that Decorator realizes
the IComponent interface.
 The fact that Decorator inherits from IComponent means that
Decorator objects can be used wherever IComponent objects
are expected. The Component class is also in an is-a
relationshipwith IComponent, and therefore the client can use
Component and Decorator objects interchangeably—the heart
of the Decorator pattern.
18

2. Has-a
 The has-a relationship is shown by an open
diamond on the Decorator, linked to
IComponent.
 This indicates that the Decorator instantiates
one or more IComponent objects and that
decorated objects can outlive the originals.
 The Decorator uses the component attribute (of
type IComponent) to invoke any replacement
Operation it might wish to override. This is the
way the Decorator pattern achieves its
objective.
 The addedBehavior operation and the
addedState attribute in the Decorator class are
other optional ways of extending what is in the19

USE OF DECORATOR PATTERNUSE OF DECORATOR PATTERN
Use the Decorator pattern when…
You have:
 An existing component class that may be unavailable for
subclassing.
You want to:
 Attach additional state or behavior to an object dynamically.
 Make changes to some objects in a class without affecting others.
 Avoid subclassing because too many classes could result.
But consider using instead:
 The Adapter pattern, which sets up an interface between
different classes.
 The Composite pattern, which aggregates an object without also
inheriting its interface.
 The Proxy pattern, which specifically controls access to objects.
 The Strategy pattern, which changes the original object rather
than wrapping it.
20

USE OF DECORATOR PATTERNUSE OF DECORATOR PATTERN
Use the Decorator pattern when…
You have:
 An existing component class that may be
unavailable for subclassing.
You want to:
 Attach additional state or behavior to an
object dynamically.
 Make changes to some objects in a class
without affecting others.
 Avoid subclassing because too many classes
could result.
21

2. PROXY PATTERN2. PROXY PATTERN
The Proxy pattern supports objects that
control the creation of and access to other
objects.
The proxy is often a small (public) object
that stands in for a more complex (private)
object that is activated once certain
circumstances are clear.
22

23
 Provide a surrogate or placeholder for
another object to control access to it.
 A proxy, in its most general form, is a class
functioning as an interface to something else.
The proxy could interface to anything: a
network connection, a large object in
memory, a file, or some other resource that
is expensive or impossible to duplicate.

24
 The Proxy design pattern makes the clients
of a component communicate with a
representative rather than to the
component itself. Introducing such a
placeholder can serve many purposes,
including enhanced efficiency, easier access
and protection from unauthorised access.

25
The generic Proxy pattern can have such
variants as:
1. Remote Proxy - where clients of remote
components should be shielded from
network addresses and inter-process
communication protocols.
2. Protection Proxy - where components
must be protected from unauthorized
access.

26
3. Cache Proxy - where multiple local clients
can share results from remote components.
4. Synchronization Proxy - where multiple
simultaneous access to a component must
be synchronized.
5. Counting Proxy - where accidental
deletion of components must be prevented,
or usage statistics collected.

27
6. Virtual Proxy - where the processing or
loading of a component might be costly,
while partial information about the
component might be sufficient.
7. Firewall Proxy - where local clients
should be protected from the outside world.

PROXY PATTERNPROXY PATTERN
A major phenomenon in the world today
is the rise in popularity of community
networking systems, the most prominent
of which is Facebook.
 A session from Facebook is shown in
the figure
29

PROXY PATTERNSPROXY PATTERNS
30

Proxy pattern illustration—a page in a socialProxy pattern illustration—a page in a social
networking systemnetworking system
 A feature of such systems is that many people who sign up do so
only to view what others are up to and do not actively
participate or add content. It might therefore be a good policy
to start every newcomer with a plain page and not grant users
any actual storage space or access to any facilities until they start
adding friends and messages.
 Another feature of these systems is that you have to first
register with the system and then log on at each session. Once
logged on, you have access to your friends’ pages.
 All the actions you can perform (poke, write on walls, send gifts,
etc.) originate at your browser and are sent across the network
to the nearest Facebook server.
 The objects are the Facebook pages; the proxies are the
mechanisms that allow registration and login.
31

PROXY PATTERN UML DIAGRAMPROXY PATTERN UML DIAGRAM
32

ISubject
 A common interface for subjects and proxies that enables them to be
used interchangeably
Subject
 The class that a proxy represents
Proxy
 A class that creates, controls, enhances, and authenticates access to a
Subject
Request
 An operation on the Subject that is routed via a proxy
 The central class, Proxy, implements the ISubject interface. The Client can
use ISubject to abstract away from proxies.
 Each Proxy object maintains a reference to a Subject, which is where the
action really takes place. The Proxy performs frontend work. Its value
can be enhanced by making the Subject a private class so that the Client
cannot get to the Subject except via the Proxy.
33
PROXY PATTERN UML DIAGRAMPROXY PATTERN UML DIAGRAM

USE OF PROXY PATTERNUSE OF PROXY PATTERN
Use the Proxy pattern when…
You have objects that:
 Are expensive to create.
 Need access control.
 Access remote sites.
Need to perform some action whenever they are
accessed.
You want to:
 Create objects only when their operations are requested.
 Perform checks or housekeeping on objects whenever
accessed.
 Have a local object that will refer to a remote object.
 Implement access rights on objects as their operations
are requested.
34

3. BRIDGE PATTERN3. BRIDGE PATTERN
The Bridge pattern decouples an abstraction
from its implementation, enabling them to
vary independently.
The Bridge pattern is useful when a new
version of software is brought out that will
replace an existing version, but the older
version must still run for its existing client
base.
The client code will not have to change, as it
is conforming to a given abstraction, but the
client will need to indicate which version it
wants to use. 35

BRIDGE PATTERN UMLBRIDGE PATTERN UML
DIAGRAMDIAGRAM
36

BRIDGE PATTERN UML DIAGRAMBRIDGE PATTERN UML DIAGRAM
Abstraction
 The interface that the client sees
Operation
 A method that is called by the client
Bridge
 An interface defining those parts of the Abstraction that might
vary
ImplementationA and ImplementationB
 Implementations of the Bridge interface
OperationImp
 A method in the Bridge that is called from the Operation in the
Abstraction
With the Decorator pattern, there can be several implementations
for the one abstraction. Legacy implementations do not have to
implement the Bridge if they are still going to be instantiated in
the old way; they need to do so only if they must be used
interchangeably with the new implementations. 37

BRIDGE PATTERN ILLUSTRATION:BRIDGE PATTERN ILLUSTRATION: fivefive
versions of the .NET Framework loadedversions of the .NET Framework loaded
38

BRIDGE PATTERN ILLUSTRATION:BRIDGE PATTERN ILLUSTRATION: environmentenvironment
Path variable set to Version 3.5Path variable set to Version 3.5
39

USE OF BRIDGE PATTERNUSE OF BRIDGE PATTERN
Use the Bridge pattern when…
You can:
 Identify that there are operations that do not
always need to be implemented in the same
way.
You want to:
 Completely hide implementations from clients.
 Avoid binding an implementation to an
abstraction directly.
 Change an implementation without even
recompiling an abstraction. 40

4. COMPOSITE PATTERN4. COMPOSITE PATTERN
The Composite pattern arranges structured
hierarchies so that single components and
groups of components can be treated in the
same way.
Typical operations on the components
include add, remove, display, find, and group.
41

COMPOSITE PATTERNCOMPOSITE PATTERN
Computer applications that specialize in
grouping data.
 Consider a music playlist in iTunes or a
digital photo album in Flickr or iPhoto as
shown in Figure .
Items are put in a large list, which is then
given structure separately 42

Composite pattern illustration—iPhotoComposite pattern illustration—iPhoto
43

Looking at the screenshot from iPhoto, we
can see that there are different ways of
viewing the photos that have been
imported: chronologically or by named
event.
Creating an album forms a composite
object but does not entail actually copying
the photos. 44

The important point about the Composite
pattern is that the operations carried out
on photos and albums of photos should
have the same names and effects, even
though the implementations are different.
For example, the user should be able to
display a photo or an album (that contains
photos).
Similarly, deletions of a single photo or an
album should behave in the same way. 45

COMPOSITE PATTERN UML DIAGRAMCOMPOSITE PATTERN UML DIAGRAM
46

COMPOSITE PATTERN UMLCOMPOSITE PATTERN UML
DIAGRAMDIAGRAM
IComponent
 Defines the operations for objects in the composition, and any default behavior
that will be applicable across objects of both types
Operation
 Performs an operation on IComponent-conforming objects
Component
 Implements the operations as applicable to single objects that cannot be further
decomposed
Composite
 Implements the operations as applicable to composite objects, using (or
accessing) a list of components kept locally and probably using the equivalent
Component operations
The client deals only with the IComponent interface, which simplifies its task.
47

5. FLYWEIGHT PATTERN5. FLYWEIGHT PATTERN
The Flyweight pattern promotes an efficient way to
share common information present in small objects
that occur in a system in large numbers. It thus helps
reduce storage requirements when many values are
duplicated.
 Each “flyweight” object is divided into two pieces: the
state-dependent (extrinsic) part, and the state-
independent (intrinsic) part.
Intrinsic state is stored (shared) in the Flyweight
object.
Extrinsic state is stored or computed by client
objects, and passed to the Flyweight when its
operations are invoked 48

49
 The Flyweight uses sharing to support large numbers
of objects efficiently.
For Example: The public switched telephone network
is an example of a Flyweight. There are several
resources such as dial tone generators, ringing
generators, and digit receivers that must be shared
between all subscribers. A subscriber is unaware of
how many resources are in the pool when he or she
lifts the handset to make a call. All that matters to
subscribers is that a dial tone is provided, digits are
received, and the call is completed
FLYWEIGHT PATTERNFLYWEIGHT PATTERN

FLYWEIGHT PATTERN DESIGNFLYWEIGHT PATTERN DESIGN
Flyweight pattern relies on being able to divide up
the application’s state into three types.
1. The intrinsicState resides in the Flyweight objects.
The Flyweight class implements an IFlyweight
interface, which specifies the operations upon which
the rest of the system relies.
2. The Client maintains the unSharedState as well as a
dictionary of all the Flyweights, which it gets from a
FlyweightFactory whose job it is to ensure that only
one of each value is created.
3. Finally, the extrinsicState does not appear in the
system as such; it is meant to be computed at runtime
for each instrinsicState instance, as required.
50

FLYWEIGHTFLYWEIGHT pattern illustration—Photo Grouppattern illustration—Photo Group
51

FLYWEIGHT PATTERN UML DIAGRAMFLYWEIGHT PATTERN UML DIAGRAM
52

FLYWEIGHT PATTERN UMLFLYWEIGHT PATTERN UML
DIAGRAMDIAGRAM
Client
Computes and maintains the unshared state
of the objects
IFlyweight
Defines an interface through which
Flyweights can receive and act on intrinsic
State
FlyweightFactory
Creates and manages unique Flyweight
objects
Flyweight
Stores intrinsic state that is shareable among
all objects
53

FLYWEIGHT PATTERN UMLFLYWEIGHT PATTERN UML
DIAGRAMDIAGRAMThere are other design options. For example, in
UML diagram , Flyweight is shown as computing
the extrinsicState.
However, the Client could do the computation
and
pass the extrinsicState to the Flyweight as a
parameter to the Operation.
Also, we envisage the unSharedState as a
Dictionary of values related to the Flyweights;
however, the unSharedState could have a more
complex structure, warranting its own class.
In this case, it would stand alongside the
Flyweight class and implement the IFlyweight
interface. 54

USE OF FLYWEIGHTUSE OF FLYWEIGHT
PATTERNPATTERN
Use the Flyweight pattern when…
There are:
 Many objects to deal with in memory
 Different kinds of state, which can be
handled differently to achieve space savings
 Groups of objects that share state
 Ways of computing some of the state at
runtime
You want to:
Implement a system despite severe memory
constraints
55

56
6. ADAPTER6. ADAPTER
 Convert the interface of a class into another interface clients expect.
 Adapter lets classes work together that couldn't otherwise because of
incompatible interfaces.
 The adapter translates calls to its interface into calls to the original
interface, and the amount of code necessary to do this is typically small.
 The adapter is also responsible for transforming data into appropriate
forms. For instance, if multiple boolean values are stored as a single
integer (i.e. flags) but your client requires a 'true'/'false', the adapter
would be responsible for extracting the appropriate values from the
integer value. Another example is transforming the format of dates (e.g.
YYYYMMDD to MM/DD/YYYY or DD/MM/YYYY).

57
1. Object Adapter pattern
In this type of adapter pattern, the adapter contains
an instance of the class it wraps. In this situation, the
adapter makes calls to the instance of the wrapped
object.
2. Class Adapter pattern
This type of adapter uses multiple polymorphic
interfaces to achieve its goal. The adapter is created
by implementing or inheriting both the interface that
is expected and the interface that is pre-existing
Two Types of AdapterTwo Types of Adapter
PatternPattern

58
The role of the Facade pattern is to provide
different high-level views of subsystems whose
details are hidden from users.
In general, the operations that might be
desirable from a user’s perspective could be
made up of different selections of parts of the
subsystems.
7. FACADE PATTERN7. FACADE PATTERN

59
Hiding detail is a key programming concept.
What makes the Façade pattern different from,
say, the Decorator or Adapter patterns is that the
interface it builds up can be entirely new. It is not
coupled to existing requirements, nor must it
conform to existing interfaces.
There can also be several façades built uparound
an existing set of subsystems.
See the UML diagram in Figure 4-5; it considers
the subsystems to be
grouped together, so they can interact in agreed
ways to form the top-level operations.
FACADE PATTERNFACADE PATTERN

FACADE PATTERN UML DIAGRAMFACADE PATTERN UML DIAGRAM
60

61
See the UML diagram, it considers the subsystems to be
grouped together, so they can interact in agreed ways to
form the top-level operations.
 The roles are:
Namespace 1 : A library of subsystems
Subsystem : A class offering detailed operations
Façade : A class offering a few high-level operations
as
selections from the subsystems
Namespace 2 : Where the client resides
Client : Calls the high-level operations in the Facade
in Namespace 1
As shown in the UML diagram, the client’s code does not
make reference to the classes of the names of the
FACADE PATTERN UML DIAGRAM

62
Facades can be useful in different circumstances.
For Example: There are many instances where a
computer system is built up out of a set of largely
independent subsystems.
One well-known case is a compiler: it consists of
clearly identifiable subsystems called a lexical
analyzer, a syntax analyzer, semantic analyzers, a
code generator, and several optimizers.
In modern compilers, each subsystem has many
subtasks. The different tasks and subtasks are
called in a sequence, but sometimes they are not
all needed.
USE OFFACADE PATTERNFACADE PATTERN

63
Use the Facade pattern when…
A system has several identifiable subsystems
and:
 The abstractions and implementations of a
subsystem are tightly coupled.
The system evolves and gets more complex,
but early adopters might want to retain their
simple views.
 You want to provide alternative novice,
intermediate, and “power user” interfaces.
 There is a need for an entry point to each
level of layered software.
USE OFFACADE PATTERNFACADE PATTERN

64
Opaque : Subsystem operations can only be
called through the Facade.
Transparent : Subsystem operations can be
called directly as well as through the Facade.
Singleton : Only one instance of the Facade is
meaningful.
CHOOSE THE FACADE YOUCHOOSE THE FACADE YOU
NEED…..NEED…..

65
A bridge, separates an interface and its
implementation so that they can vary
independently, whereas an adapter changes the
interface of an existing object.
The Adapter pattern is more useful for one-off
changes, whereas the Bridge pattern anticipates
that change might happen continuously.
 A decorator enhances an object without
changing its interface and should be transparent
to the application. An adapter is not
transparent, as it is the named implementation
of the interface the client sees.
PATTERN COMPARISONPATTERN COMPARISON

66
The Proxy pattern does not change any
interfaces; it defines substitute objects for
other objects.
From a certain point of view, the Facade
pattern is also adapting requests: it transforms
high-level requests into a sequence of lower-
level requests. The Facade’s intent is to hide
complexity, and the Facade subsystems are not
intended to be accessible by the client.
PATTERN COMPARISONPATTERN COMPARISON

67
1. Model-View-Controller (MVC)
2. Presentation–abstraction–control
(PAC)
PATTERN FOR INTERACTIVEPATTERN FOR INTERACTIVE
SYSTEMSSYSTEMS

68
MVC is a type of computer user interface that
separates the representation of information from the
user's interaction with it.
 The Model-View-Controller (MVC) architectural
pattern divides an interactive application into three
components. It was originally developed to map the
traditional input, processing and output roles into the
GUI realm:
Input --> Processing --> Output
Controller --> Model --> View

PATTERN FOR INTERACTIVE SYSTEMSPATTERN FOR INTERACTIVE SYSTEMS
MODEL-VIEW-CONTROLLER(MVC)MODEL-VIEW-CONTROLLER(MVC)

69
Model contains the core functionality and data. It is
independent of specific output representations or
input behaviour.
View displays information to the user. A view obtains
data from the model. There can be multiple views of
the model.
Controller handles user input.
Views and controllers together provide the user
interface.
The central idea behind MVC is code reusability and
separation of concerns.

70

71
The purpose of the MVC pattern is to separate the
model from the view so that changes to the view can
be implemented, or even additional views created,
without having to refactor the model. Note that the
model may or may not reference a persistent data
store (database).
Note that although this pattern only shows three
components it is possible to divide any one of them
into smaller sub-components.

72
PAC is a software architectural pattern.
It is an interaction-oriented software architecture, in
that it separates an interactive system into three
types of components responsible for specific aspects
of the application's functionality.
1. Abstraction component retrieves and processes the
data,
2. Presentation component formats the visual and
audio presentation of data,
3. Control component handles things such as the flow
of control and communication between the other
two components .
PRESENTATION-ABSTRACTION-CONTROL(PAC)PRESENTATION-ABSTRACTION-CONTROL(PAC)

73
 In the context of the Presentation-Abstraction-
Control pattern, an agent is an information processing
component that includes:
– Event receivers and transmitters.
– Data structures to maintain state.
– A processor that handles incoming events, updates
its own state, and may produce new events.
 Agents can be as small as a single object, but also as
complex as a complete software system.
PAC AGENTSPAC AGENTS

74
In contrast to MVC, PAC is used as a hierarchical
structure of agents, each consisting of a triad of
presentation, abstraction and control parts.
The agents (or triads) communicate with each other
only through the control part of each triad. It also
differs from MVC in that within each triad, it
completely insulates the presentation (view in MVC)
and the abstraction (model in MVC), this provides the
option to separately multithread the model and view
which can give the user experience of very short
program start times, as the user interface
(presentation) can be shown before the abstraction
has fully initialized.
PRESENTATION-ABSTRACTION-CONTROL(PAC)PRESENTATION-ABSTRACTION-CONTROL(PAC)

75
Consider a simple information system for political
elections with proportional representation.
This offers a spreadsheet for entering data and
several kinds of tables and charts for presenting
current standings. Users interact with the software
through a graphical interface.
Different versions, however, adapt the user interface
to specific needs. For example, one version supports
additional views of the data, such as the assignment of
parliament seats to political parties.
PAC EXAMPLEPAC EXAMPLE

76
PAC EXAMPLEPAC EXAMPLE

77
1. Separation of concerns.
 Different semantic concepts in the application
domain are represented by separate agents.
 Each agent maintains its own state and data,
coordinated with, but independent of other PAC
agents.
 Individual PAC agents also provide their own user
interface. This allows the development of a
dedicated data model and user interface for each
semantic concept or task within the application,
independently of other semantic concepts or tasks.
PAC BENEFITSPAC BENEFITS

78
2. Support for change and extension.
 Changes within the presentation or abstraction
components of a PAC agent do not affect other
agents in the system.
 New agents are easily integrated into an existing
PAC
architecture without major changes to existing PAC
agents.

79
3. Support for multitasking.
PAC agents can be distributed easily to different
threads, processes, or machines. Extending a PAC
agent with appropriate inter-process communication
functionality only affects its control component.
Multitasking also facilitates multi-user applications.
For example, in our information system a newscaster
can present the latest projection while data entry
personnel update the data base with new election
data.

80
1. Increased system complexity.
 The implementation of every semantic
concept within an application as its own PAC
agent may result in a complex system
structure.
If the level of granularity is too fine, the system
could drown in a sea of agents. Agents must
also be coordinated and controlled, which
requires additional coordination agents.
PAC LIABILITIESPAC LIABILITIES

81
2. Complex control component.
The quality of the control component
implementations is therefore crucial to an
effective collaboration between agents, and
therefore for the overall quality of the system
architecture.
3. Efficiency.
The overhead in the communication between
PAC agents may
impact system efficiency especially if agents are
distributed.

82
4. Applicability.
The smaller the atomic semantic concepts of
an application are, and the more similar their
user interfaces, the less applicable this pattern
is.

83
BROKER
The Broker architectural pattern can be used
to structure distributed software systems with
decoupled components that interact by
remote service invocations
The Broker component is responsible for
coordinating communication, such as
forwarding requests, as well as transmitting
results and exceptions
PATTERN FOR DISTRIBUTIONPATTERN FOR DISTRIBUTION

84
Introduce a broker component to achieve
better decoupling of clients and servers
Servers register themselves with the broker,
and make their services available to clients
through method interfaces
Clients access the functionality of servers by
sending requests via the broker
BROKERBROKER

85
The broker will locate the appropriate server,
forward the request to the server and transmit
results and exceptions back to the client
Using the Broker pattern, an application can
access distributed services simply by sending
message calls to the appropriate object, instead
of focusing on low-level inter-process
communication
BROKERBROKER

86
Broker thus supports integration of
distribution as well as object technology
(Or you could say it extends the traditional
object model from single application to
distributed applications)
BROKERBROKER

87
There are six types of components in Broker
architectural pattern:
1.Clients,
2.Servers,
3.Brokers,
4.Bridges,
5.Client-side proxies
6.Server-side proxies
BROKER ARCHITECTURAL PATTERNBROKER ARCHITECTURAL PATTERN

88
are applications that access the services of at
least one server
Implements user functionality
Sends requests to servers through a client-side
proxy
To call remote services, clients forward
requests to the broker
Clients then will receive responses or
exceptions from the broker
Remember clients and servers are logically
terms. So, a client can be a server and vice
1.CLIENT1.CLIENT

89
Clients are the requesters and do not need to
know about the location of the servers
As a developer, you can consider clients are
application and servers are libraries
1. CLIENT1. CLIENT

90
Implements services
Registers itself with the local broker
Sends responses and exceptions back to the
client through a server-side proxy
2. SERVER2. SERVER

91
implements objects that expose their
functionality through interfaces that consist of
operations and attributes
These interfaces are either through Interface
Definition Language (IDL), through a binary
standard, or some kind of APIs.
Interfaces are grouped by semantically-related
functionality. So, we could have
Servers offering common services to many
application domains
Servers implementing specific functionality for
2. SERVER2. SERVER

92
 A broker is a messenger that is responsible
for the transmission of requests from clients to
servers
It also takes care the transmission of
responses and exceptions back to the client
A broker will store control information for
locating the receivers (servers) of the requests
Broker also offer interface for clients and
servers
3. BROKER3. BROKER

93
Registers (Unregister) servers
Offers APIs (or some kind of common
interface)
Transfer messages
Error recovery
Interoperates with other brokers through
bridges
Locates servers
3. BROKER3. BROKER

94
They are usually in the form of APIs with
control operations such as registering servers
and invoking server methods
Broker keeps track of all the servers
information it maintains locally. If a request
comes in and it is for a server that is on the
tracking list. It passs the request along directly
If the server is currently inactive, the broker
activates it (spawn a job, folk a process, create
a thread, use a prestart job, etc)
3. BROKER3. BROKER

95
Then response are passed back to the client
through the broker
If the request is for a server hosted by another
broker, the local broker finds a route to the
remote broker and forwards the request using
this route (So, a common way of
communication among brokers is needed)
Sometimes, name services (DNS, LDAP, NT
directory ?, RMI ?, etc) or marshaling support
will be integrated into the broker
3. BROKER3. BROKER

96
Bridges are used to bridge communication
among brokers
They are optional to hide the implementation
detail
They are most useful when the system run
across heterogeneous network (so bridge will
take care of, say IPX network talks to IP
network as well as SNA network)
4. BRIDGES4. BRIDGES

97
Encapsulates network-specifc functionality
Mediates between the local broker and the
bridge of a remote broker
4. BRIDGES4. BRIDGES

98
Encapsulates system-specific functionality
Mediates between the client and the broker
5. CLIENT-SIDE PROXIES5. CLIENT-SIDE PROXIES

99
Client-side proxies represent a layer between
clients and the broker
This additional layer provides transparency,
which a remote object appears to the client as
a local one
It hides the implementation detail such as:
-Inter-process communication mechanism
used for message transfer between clients and
brokers

100
-The creation and deletion of memory blocks
(remember, we are dealing with multiple
different languages to build a system, not just
Java)
-The marshaling of parameters and results
In most cases, client-side proxies translate the
object model specified as part of the Broker
architectural pattern to the object model of
the programming language used to implement
the client

101
Calls services within the server
Encapsulates system-specific functionality
Mediates between the server and the broker
6. SERVER-SIDE PROXIES6. SERVER-SIDE PROXIES

102
They receive requests, unpack messages,
unmarshaling parameters and call the
appropriate service (in a server)
(Most web server has "built-in" client and
server proxy to communicate with client and
internet router, so there is nothing to
implement in that case)
(In RPC, client-side and server-side proxies
are kind of parallel to stubs)
6. SERVER-SIDE PROXIES6. SERVER-SIDE PROXIES

103
1. Direct communication
2. Indirect communication
Two types of BrokersTwo types of Brokers

104
Assume client and server understand the same
protocol
Broker will assist in the initial hand shake of
the client and server
Then all the messages, exceptions and
responses are transferred between client-side
proxies and server-side proxies without using
the broker as an intermediate layer
Direct communication:

105
Assume client and server understand the same
protocol
Broker will assist in the inital hand share of the
client and server
Then all the messages, exceptions and
responses are tranferred between client-side
proxies and server-side proxies without using
the broker as an intermediate layer
(Usually a mix approach is used, Java applet
can use socket directly but not all the other
components)
Direct communication:

106
Jim Arlow, Ila Neustadt , "Enterprise Patterns and
MDA".
Martin Fowler, David Rice, Mathew Foemmel, Edward
Hieatt, Robert Mee, Randy Stafford, “Patterns of
Enterprise Application Architecture”
Paul Clements,Felix Bachmann,Len Bass, David
Garlan, James Ivers, Reed Little, Paulo Merson,
Robert Nord, Judith Stafford, “Documenting
Software Architectures Views and
Beyond”,Second Edition
REFERENCE:

Software Architecture and Project Management module III : PATTERN OF ENTERPRISE

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Software Architecture and Project Management module III : PATTERN OF ENTERPRISE

Ähnlich wie Software Architecture and Project Management module III : PATTERN OF ENTERPRISE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software Architecture and Project Management module III : PATTERN OF ENTERPRISE