ComputerScienceExpert
$18/per page/
PROBLEM DESCRIPTION
A city has decided to create a green zone. The green zone is an area in the center of the city in which there is restricted access by motor vehicles. Vehicles (such as cars and trucks) are only allowed to enter the green zone if they have a green zone permit. The permit number is encoded on a bar code sticker, which is displayed on the windshield of the vehicle. When the vehicle enters the green zone, a remote laser scanner reads the barcode permit number and transmits it to the Green Zone Monitoring System. When the car leaves the zone, its bar code is also scanned and sent to the system.
Chapter : Architecture Patterns © Len Bass, Paul Clements, Rick Kazman,
distributed under Creative Commons
Attribution License Types of Architecture Styles
Categories Architecture Styles Data Centered Blackboard and Repository Interaction Oriented MVC and PAC Communication Oriented Peer-Peer and Publish-Subscriber Deployment Oriented Layered – Client / server, 3 Tier and
Distributed Client-Server Client-Server architecture
The application is modeled as a set of services that are
provided by servers and a set of clients that use these
services.
Clients know of servers but servers need not know of
clients.
Clients and servers are logical processes.
Examples: email exchange, web access, database access Client-server architectures: Types
There are basically two types of client-server architectures Two tier architectures Three tier architectures Types of Two Tier Model - Thin and fat clients
Thin-client model (also called Slim-Client)
In a thin-client model, all of the application
processing and data management is carried out on
the server. The client is simply responsible for running
the presentation software. Fat-client model (Thick-Client)
In this model, the server is only responsible for data
management. The software on the client implements
the application logic and the interactions with the
system user. Thin and fat clients
Pres entation
Thin-client
model Data management
Application proces s ing Client Pres entation
Application proces s ing
Fat-client
model Client S erver S erver
Data management Three tier architecture
3-tier architectures attempt to overcome some of the
limitations of the 2-tier architecture by separating
presentation, processing, and data into 3 separate and distinct
entities. Tier Architecture
Pros
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. Availability.
Applications can exploit the modular architecture of enabling systems using easily
scalable components, which increases availability. Cons
Tightly coupled to language
Lack extensibility
Lack transparency Broker Architectural Style
• The broker architecture is a middleware architecture
used in distributed computing to coordinate and
facilitate communication between registered servers
and clients.
• Bushmann et al. developed the broker architectural
pattern to design a distributed system into
components that interact by remote service
invocations.
• “The Broker architectural pattern can be used to
structure distributed software systems with decoupled
components that interact by remote service
invocations.
• A broker component is responsible for coordinating
communication, such as forwarding requests, as well
as for transmitting results and exceptions.” Broker Architecture
based on client/server concepts but Transparently distribute the software system to different
nodes
Server make their service available to client by registering and publishing
their interface to brokers
Clients request the services of server from broker by lookup Client can make of a service without knowing where the location
of a server. • A broker component is responsible for coordinating
communications –
• brokering the service requests,
• locating a proper server,
• forwarding and dispatching requests, and
• sending responses or exceptions back to clients.
• Actually, a broker can be either an invocation-oriented
service, to which clients send invocation requests for
brokering, or a document or message- oriented broker to
which clients send a message (such as an XML
document). • A broker acts as a policeman in a busy
intersection who controls and interacts
with the client components and server
components.
• The connection between clients and
servers is maintained by the broker.
• CORBA (Common Object Request
Broker Architecture) is a good
implementation example of the broker
architecture. • With the broker pattern, a distributed client can
access distributed services simply by calling a remote
method of a remote object just as if it were a local
method call.
• This concept is similar to Remote Procedure Call
(RPC) in Unix distributed structured programming
and Remote Method Invocation (RMI) in Java
distributed object-oriented programming.
• The distributed clients only need to obtain a reference
to the appropriate object, instead of writing detailed
code for protocol-oriented communication. Figure 10.3 Broker model
Service 1 2
1
request Broker 1 3 Service 2 5
response 4
Service 3 Broker 2 Implementation of Broker Architecture
Decompose the broker architecture into subcomponents:
• Broker: co-ordinates communications – passes on
requests and returns replies.
• The broker keeps all servers registration
information including their functionality and
services as well as location information.
• The broker provides APIs for clients to request,
servers to respond, registering or unregistering
server components, transferring messages, and
locating servers. • Stub (client-side proxy): It mediates between client
and broker and provides additional transparency
between them.
• To the client, a remote object appears like a local one.
• The proxy hides the inter-process communication at
protocol level and performs marshalling of parameter
values and unmarshaling of results from the server.
• The stub is generated at the static compilation time
and deployed to the client side to be used as a proxy
for the client. • Skeleton (server-side proxy): It is also statically
generated by the service interface compilation and
then deployed to the server side.
• It receives the requests, unpacks the requests,
unmarshals the method arguments, and calls the
appropriate service.
• When it receives the result back from the server it
also marshals the result before sending it back to the
client. • Bridges: These optional components are used to hide
implementation
details
when
two
brokers
interoperate.
• It
encapsulates
underlying
network
detail
implementation and mediates different brokers such
as DCOM, .NET Remote and Java CORBA brokers.
• They can take requests and parameters in one format
and translate them to another format.
• A bridge can connect two different networks based on
different communication protocols. • Network: The connections between the components
are the network with designated protocol standards
such as TCP/IP OIIP or SOAP.
• The request carries data in a format of message
document or method invocation. Broker Architecture Benefits:
Location Transparency: broker makes the distribution transparent to
the developer
Interoperability: via broker the communication between server and
client is independent changeability: server services can be changed without affecting
the client application
Scalability: new client and server services can be integrated Limitations
Reliability: lower support to fault tolerance. The failure of the broker
affects entire system
Testing : Testing and debugging broker becomes a challenge Types of Architecture Styles
Categories Architecture Styles Data Centered Blackboard and Repository Interaction Oriented MVC and PAC Communication Oriented Peer-Peer and Publish-Subscriber Deployment Oriented Layered – Client / server, 3 Tier and
Distributed Publish-Subscribe model Subscribers register to receive specific
messages
Publishers maintain a subscription list and
broadcast messages to subscribers Publish-Subscribe model
Pros
– Changeability: Since publishers are loosely coupled to subscribers.
– Scalability: Easy to plug-in new subscribers/publishers without
affecting the rest of the system
– Performance: through parallel communication to subscribers
Cons
– Reliability: Does not guarantee delivery of messages
– Testing: Difficult to test and debug the system since it is hard to
predict and verify responses and the order of responses.
• no control over the order of computations of subscribers Service-Oriented Architecture (SOA)
• A Service Oriented Architecture (SOA) starts with a
businesses process.
• In this context, a service is a business functionality
that is well-defined, self-contained, independent from
other services, and published and available to be used
via a standard programming interface.
• Software manages business processes through a SOA
with well-defined and standard interfaces that can
build, enhance, and expand their existing
infrastructure more flexible. • SOA services can be extensively reused within a
given domain or product line, and even among legacy
systems.
• Loose coupling of service–orientation provide great
flexibility for enterprises to make use of all available
service recourses regardless of
platform and
technology restrictions.
• The connections between services are conducted by
common and universal message oriented protocols
such as the SOAP Web service protocol, which can
deliver requests and responses between services
loosely.
• A connection can be established statically or
dynamically. •
•
•
• Advantages of SOA:
Loosely-coupled connection: Loose-coupling is the
key attribute of SOA.
Each service component is independent from other
services due to the stateless service feature.
The implementation of a service will not affect the
application of the service as long as the exposed
interface is not changed.
It makes SOA software much easier to evolve and
update. • Interoperability: Technically any client or any service
can access other services regardless of their
platform, technology, vendors, or language
implementations.
• Reusability: Any service can be reused by any other
service,. Because clients of a service only need to
know its public interfaces, service composition and
integration become much easier.
• SOA based business application development comes
much more efficient in term of time and cost. • Scalability: Loosely coupled services make
themselves easy to scale.
• The coarse-grained, document-oriented, and
asynchronous service features enhance the
scalability attribute. Implementation of SOA Architecture © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License • To implement SOA, enterprises need a service
architecture, Figure Shows several services
• consumers can invoke services by sending
messages.
• These messages are typically transformed and
routed by a service bus to an appropriate service
implementation.
• This service architecture can provide a business
rules engine that allows business rules to be
incorporated in a service or across services.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License • The service architecture also provides a service
management infrastructure that manages
services and activities like auditing, billing, and
logging.
• In addition, the architecture offers enterprises the
flexibility of having agile business processes,
better addresses the regulatory requirements like
Sarbanes Oxley (SOX), and changes individual
services without affecting other services.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Development Architecture Component Component Relation between Object, Component & Service Component Oriented Architecture Component Vs Object Oriented Architecture
Component
Encapsulates State
and functionality
Unit of Composition
Well defined
interfaces with
dependencies
Can be deployed in
nodes and utilized Object
Encapsulates State and
functionality
Unit of Instantiation
May not always provide
interfaces
During runtime they
move between
components Component Vs Service Oriented Architecture
Component
Component providers
charge on perdeployment basis
Component can be
distributed
Component should be
deployed and used
Compatibility is a
problem Service
Service provider charge on
per-call basis
Service can be made
available and
Services are published and
advertised
Interoperable through
standard protocols Object Oriented Vs Component Vs Service Map-Reduce Pattern
• Context: Businesses have a pressing need to quickly analyze enormous volumes of data
they generate or access, at petabyte scale.
• Problem: For many applications with ultra-large data sets, involves sorting the data and
then analyzing the grouped data efficiently in a distributed and parallel environment.
• Solution: The map-reduce pattern requires three parts:
– A specialized infrastructure takes care of allocating software to the hardware nodes in a massively parallel computing environment and handles sorting the data as needed.
– A programmer specified component called the map which filters the data to retrieve
those items to be combined. – A programmer specified component called reduce which combines the results of the
map Map-Reduce Example
The system maintains a database of pre-paid green zone permits, from which the owner of the vehicle is billed for each trip and for the duration of the trip. There is a maximum charge for each day. The amount billed varies by time of day: peak-time, off-peak and night, and vehicle category, such as car, SUV, truck, taxi, bus, etc… The amount is deducted from the pre-paid green zone account at the end of each green zone trip. A person that resides in the Green Zone and has a vehicle registered in the same address needs to apply for a resident permit, which allows unrestricted access into and out of the Green Zone.
If the car does not have a green zone permit, then a video camera takes a picture of the vehicle license plate. From an external vehicle license database, the address of the vehicle owner is determined and a fine is sent to the driver.
The system includes an automated vehicle license recognition capability, which decodes vehicle license photographs taken by the vehicle camera. The system is also accessed by Green Zone operators who may view information about green zone permits and accounts, green zone trips, monitoring points, and vehicle fines.
The order of the sensors at the green zone entry and exit points is vehicle location sensor (which detects the presence of the vehicle), vehicle laser scanner, and vehicle camera. you may assume that each of these sensors is asynchronous.
You may assume that there is a microcomputer at each entry point and each exit point, to which are connected the vehicle location sensor, vehicle laser scanner, and vehicle camera. You may also assume that there is one centralized server, which stores all the system information in a database.
· 1. For the above described system specification, identify the architectural styles that are likely to be the appropriate. Tabulate the reason for selecting and rejecting various architecture styles.
· 2. Finally, sketch out the overall architecture that would meet the specified requirements.
Attachments: