UNIT-2: CSE Dept. MVGR College of Engineering 10/26/2021

UNIT-2
CSE Dept. MVGR College of Engineering 10/26/2021 1

CONTENTS
 Enterprise wide SOA
 Enterprise Applications

CONTENTS
 Considerations for Enterprise wide SOA
 Strawman Architecture
 Enterprise SOA Layers
 Application Development Process
 SOA methodology for enterprise

CONSIDERATIONS FOR SOA
 What is an Enterprise?
 Organization with one or more divisions that delivers
value to its stakeholders (Rawmaterial, Environmental,
Technical, Safety,Delivery)
A Large enterprise
 Several divisions
 Provides products or services
 Forward and Backward linkages to external agencies
 SOA suits well for enterprise level applications

 What does it include?
 Interdependent resources (people and technology)
must coordinate and share
CSE Dept. MVGR College of Engineering
information 4
10/26/2021
CONSIDERATIONS FOR SOA
The following dimensions of service model also need
to be taken into account
 Reusability
 Services are reusable coarse grained elements in the
services model.
 Agility
 Business processes in an orchestrable manner.
 Integration
 Service providers and service consumers are loosely
coupled.
 Communicate between
CSE Dept. MVGR College of Engineering them
10/26/2021 using a published
6 contract.
STRAWMAN ARCHITECTURE
 Initial Architecture that serves as a starting point for
developing the target architecture
 Refined over number of iterations to become the target

architecture
 Independent of Technology
 Generic view of services
 Reuse, Integration, Agility require

 Coarse-grained services
 Loose coupling
 orchestration
Out Line
 Different Types of Services (A, B, C, D)
 Integration based on ESB
 Infrastructure that enables Security and

Service governance

Business Process Layer
Business Process Process Orchestration
workflows Engine
Business Process Services

Data
Sources Data
Services Client
TION LAY
layer Services Enterprise
layer
G RA ER
INTE Layer Presentation
Layer
M Infrastructure
Relational
a Layer
Databases p
p Data Client
i Servi Service Web
ce
n Governance Security Delivery
g
&
Spread
Sheets T
r Data
Servi Client
a ce
n Service
sf Mobile
o Delivery
r Activity Activity Activity
Ware
houses m Service Service Service
Data
a Servi
ti ce Activity Services Layer Client
o Service
External n
Data
Sources Business Business Business
Application Application Application
Business Application Layer

 Services at Enterprise Level

Business Services or Activity Services
Business Process Services
Client Services
Data Services

SERVICES AT ENTERPRISE LEVEL
 Activity Services or Business Services (‘A Type Service’)
 Encapsulate functionality exposed as services in various business

applications
 Implement steps or activities of a business process
 are Reusable business services

 Can be orchestrated to implement business process services
Ex: “Inventory Service,” “Customer Management Service,” and

“Shipping Service” in its repository of business services.
 Business Process Services
Orchestrate set of services to implement business
processes
Control the flow and interaction
Externalization and orchestration
‘B’ type services

 Client Services
 Provide presentation content
 Act as Service consumers
 ‘C’ type services
 Data Services
 Access to data in various sources
 ‘D’ type services
 Two types –
1) data stored across the enterprise
2) interaction with data sources outside the enterprise

INTEGRATION LAYER
 Enterprise Service Bus (ESB)
 Enables smooth communication between services
 Abstracts the mediation and interaction elements
needed to communicate
 Commercial Products in the market

 IBM WebSphere Message Broker Integration Bus.
 Microsoft BizTalk Server.
 Oracle Enterprise Service Bus
 TIBCO ActiveMatrix BusinessWorks
 Open Source Products

 Apache Camel
 Fuse ESB from Red Hat
 JBoss ESB
 Open ESB
INFRASTRUCTURE LAYER
 Infrastructure Layer
 Service Security
 To secure services
 Authentication (credentials of component invoking a service)
 Authorization (based on privileges)
 Service Governance
 To govern service
 Monitoring services, service invocations
 Imposing Security Policies

Summary
 Different Types of Services (A, B, C, D)
 Integration based on ESB
 Infrastructure that enables Security and Service

governance

ENTERPRISE SOA LAYERS
 Services grouped into layers based on the

abstraction level
 Service Layer
 The activity services, data services and client
services can orchestrated as part of the business
process
 Application Layer
 Business applications (including legacy) and the data stores
 Enterprise Presentation Layer

 Content of aggregated view delivered to the users
ENTERPRISE SOA LAYERS
 Business Process Layer
 Business process is externally defined using Business Process
Execution Language (BPEL)
 Services exposed by the Service layer are individual steps
of the business process

 Process Orchestration Engine that executes steps of the
business process
 Integration Layer
 Provides ESB capability
 Infrastructure Layer
 Security
 Governance
Service monitoring
Service management
SOA LAYERS
Infrastructure Integration
Layer Layer Business Process Layer Enterprise Presentation Layer
Business Process Process

Workflows Orchestration Services Web Mobile
Engine Delivery Delivery
Governance
ESB
Security
Activity
Services Services
Layer Data Services Client Services
Application Layer
Business Business
Spread Ware
Application Application Relational External Data
sheets houses
Databases Sources

APPLICATION DEVELOPMENT PROCESS
 Software engineering process
 Sequence of steps needed to develop or
maintain software
 Process Model
 What is to be done in developing s/w
 Methodology
 Deals with How part
 Include principles, practices and procedures of s/w
development
OOAD PROCESS
Object-oriented paradigm principles
 Abstraction
 Encapsulation
 Inheritance
 Interface
 Polymorphism

OOAD PROCESS

OOAD PROCESS
 Real world Objects abstracted as Classes
 Classes – fine grained, tightly coupled
 Requirements in terms of Use cases
 Use cases realized through analysis that produces classes

 Entityclasses
 Boundary classes
 Control classes
 Identify class hierarchy/inheritance
 Map classes to technology elements (design classes, framework
 Design classes implemented 10/26/2021

CSE Dept. MVGR College of Engineering
using a programming
23
language
OO VS SERVICE ORIENTED
Feature OO SO
Granularity type Fine grained Coarse grained
Granularity level class service
coupling Tight coupling Loose coupling
Inheritance produces Service provider and

strong association and consumer are loosely
tightly coupling coupled by using the
directory/naming
service
Runtime Assume object Can Discover the

housekeeping (GC in needed services
Java)
 Difficult to directly use OOAD for SOA
 OOAD powerful to address some parts of SOA
 Extend the OOAD to SOA to include

 Reuse
 Agility
 Integration
 Service Oriented Analysis and Design process (Fig. 4.4)

 Gather Business Objectives
 Business Process Model

 BusinessProcesses
 Workflows
 Business Process Model is a key artefact in SOAD

process

SERVICE MODELING FOR THE ENTERPRISE APPLICATION
 input to four sub-processes is the business process

model serves
 The sub-processes named by the first letter of the

names (Activity Services – A, Client Services – C etc.)
 Scope and functional requirements modelled as a set of

use cases.
 The activity services, business process services, client

services and data services are identified.

SERVICE MODELING FOR THE ENTERPRISE APPLICATION
 A service model is developed that represents the services

(based on notation such as UML 2 Profile for Software
Services).
 For composite applications, the business process services

to be defined and implemented (that use orchestration of
other services)
 For non-composite applications, business process

services are defined at enterprise level

SOA METHODOLOGY FOR ENTERPRISE
 The SOAD process focuses on what is involved in

developing a service-oriented application
 SOA methodology can be described by specifying how

the different processes need to be implemented
(Spiral, Waterfall, and iterative etc.)
 SOA methodology based on the iterative approach is

shown in Figure 4-5.

 SOA methodology includes six overlapping phases to
develop the SOA layers
 The initial phase results in a business process model

 Gather Business Objectives and Requirements
 Enterprise wise SOA Strategy definition
 Business Process Modeling
 SOA blueprint phase during which SOA architecture for

the enterprise is defined
 SOA architecture definition
 POC
 SOA Roadmap
 The service enablement phase
 involvesdevelopment of services layer
 Goes through multiple iterations
 The service integration phase

 TheESB and associated integration layer components are
implemented
 The service orchestration phase

 The process services are developed
 The activity, client and data services are orchestrated with a
process execution engine
 In the final

 The service oriented enterprise phase
 Enterprise
presentation layer developed
 Governance processes to
 Deployment of infrastructure components
 Security services
 Service governance

ENTERPRISE APPLICATIONS
CONTENTS
Architectural considerations
 Service -oriented model considerations
 Solution architecture for enterprise Applications
 Solution architecture for enterprise

ARCHITECTURAL CONSIDERATIONS
 The Architecture of an enterprise application
corresponds to the solution architecture
 Key Architectural considerations of enterprise

applications:
 Functional Requirements
 Non-functional Requirements

FUNCTIONAL REQUIREMENTS
 Important to address the architecturally significant
use cases in the architecture.
 A use case describes the interaction of users (called

actors) with the system.
 The functionality of systems can be expressed in

terms of use cases.
 Ensuring that architecturally significant use cases

are appropriately addressed is key to getting the
architecture right.
NON-FUNCTIONAL REQUIREMENTS
Performance:
 An application needs to meet the expected performance

levels for being successfully adopted by users of the
enterprise.
 Examples:
 OnlineApplications
 expected to meet specific response time for a specified
number of concurrent user interactions
 Batch Jobs (daily/monthly)

 the time taken to run the batch jobs
Scalability:
 The ability of the application to perform within

acceptable limits with changed workload in terms of
size of data, or volume of users, or both, is called
scalability.
 To meet an increased workload, architect must

ensure
 addition of hardware and software resources
 Ideally scaling can be done in a linear manner

Availability:
 The degree to which users of a system experience
degradation, or interruption in service, as a result of
failure of hardware or software components of the system
 Many enterprise applications are critical to the business

and hence need to be architected for high availability.
 Availability is measured relative to "100% operational" or

"never failing“
 One of the benchmarks of high availability is "Five 9s"

(99.999%) availability.
Reliability:
 Ability to withstand failures and recover gracefully

from unexpected events.
 Identifying and isolating single points of failure in the

architecture and spreading the risk across hardware
and software infrastructure.
 Expressed in terms of
 Mean Time Between Failures (MTBF)
 Mean Time To Restore (MTTR).

Security:
 Every action performed by the user has to be properly
authenticated and authorized in most enterprise
applications.
 the security model depends on

 the domain of the application (Banking, Medical, etc.)
 hierarchy defined for data items
 The security objectives of the application (e.g. Payment

details collection) need to be accounted.
 The security infrastructure need to be architected and

implemented.
CONTENTS
 Architectural considerations
Service -oriented model considerations
 Solution architecture for enterprise Applications

SERVICE -ORIENTED MODEL CONSIDERATIONS
Additional architectural considerations specific to SOA
are:
 Services exposed or consumed: Activity services,

business process, client services or data services that
enterprise application exposes or consumes need to be
identified.
 Granularity of services exposed: The granularity of

services exposed has to be at the right level for
effective integration and service orchestration.

 Integration model for services exposed or consumed:
Enterprise service bus(ESB) and other patterns for
integration are to be considered
 Business process model:

Business process model (BPM) of the enterprise and the
specific business processes implemented by the
enterprise application have to be taken into account
 Enterprise data model:

Data model for the application has to align with
enterprise data models that may be defined at the
organization level.
 Infrastructure:
Authentication and authorization patterns for service
security and solutions for design-time and run-time
governance (including technologies for service registry
and repository) are to be considered.

CONTENTS
 Architectural considerations
 Service -oriented model considerations
Solution architecture for enterprise

Applications

THREE RECOMMENDED LEVELS OF A SOLUTION
ARCHITECTURE
 Level 0 — High-level architecture
 Level 1 — Baseline architecture
 Level 2 — Detailed architecture

LEVEL 0 — HIGH-LEVEL ARCHITECTURE
 The objective of this level is to validate:
 understanding of the scope
 the high-level requirements provided by the business users
 Defined by the architect in consultation with business users,

sponsors, other stakeholders
 When done by an external consultant, business users and IT

department provide inputs
 Architect—
 Analyzes the inputs
 Uses the available reference architectures for the domain
 Uses best practices followed in developing such applications
 Architect develops high-level architecture with three
views —
 conceptual view
 Logical View
 physical view
 Architecture presented to business users, IT

department
 Validated for scope, functionality and suitability to

meet the business needs

CONCEPTUAL VIEW
The objective of this level is to :
 Abstracted business model

described in terms to familiar
to the users
 Example: Loan Management

System’s conceptual view

LOGICAL VIEW
 Shows the structuring of main functional
components of the application based on the
architectural patterns (such as layering) and their
relationships
 The technical details of how the functional

subsystems are implemented are not shown.
 A logical view of an LMS could look like the one shown

in Figure 5-4.

PHYSICAL VIEW
 provides details of the implementation components
(hardware and software) and their relationships
 The physical view of high level architecture may be

represented as in Figure 5-5.

 Conclusion —
 Conceptual view
 Logical View
 Physical view
 Helps to Validate high-level architecture
 Agreement between users, IT department, and

architect on the solution for the
 scope of enterprise application
 effort and cost estimate for development activities involved

LEVEL-1 BASELINE ARCHITECTURE
During the software development lifecycle (SDLC),
 requirements captured as use cases
 Domain-intensive enterprise applications (banking,

insurance etc.) require business process model related
inputs to be provided to the solution architect.
 The architect
 analyzes the architecturally significant use cases
 decides on suitable technology standards
 frameworks and guidelines and represents the architecture
using three views

 Functional view,
 Technical view and
 Implementation
CSE Dept. MVGR view.
College of Engineering 10/26/2021 64
LEVEL 1 — BASELINE ARCHITECTURE
The objective of this level is to :
 identify architecturally significant use cases from a
functional perspective
 provide a solution from a technical perspective based on

architectural decisions made
 Evaluate various options available for technology platforms,

frameworks, products and on analysis of the architecture
tradeoffs.
 This version of the architecture is represented with

 functional view
 technical view
 deployment view
FUNCTIONAL VIEW
 defines key functional elements that
 Deliver the application's functionality
 Their responsibilities
 Interfaces they expose
 Interactions between the functional elements
 The functional elements are mapped to the technical

elements in the technical view.
 Figure 5-7 provides an example of functional view for an LMS.

TECHNICAL VIEW
describes
 Technical elements of an enterprise application
their interfaces
 interaction and interdependence in order to satisfy

a specified set of requirements
 provides the basis for the design and development

stages of software development lifecycle(SDLC).

TECHNICAL VIEW
 The technical view of enterprise application (EA)
can then be described in terms of the technical
elements and their interactions.
 Many Enterprise Applications(EA’s) adopt a layered

approach with
 presentation layer
 business layer
 data access layer.

PRESENTATION LAYER
 Software platforms such as Java EE and .NET provide
significant infrastructure to address presentation layer
concerns.
 The key technical elements to consider for presentation

layer include:
 1. user interface(UI) elements
 2. user interface navigation elements
 The presentation capabilities required for the

functional elements in functional view need to be
mapped to the above technical elements.

BUSINESS LAYER
 The elements in functional view mapped to technical
elements in the technical view
 The key technical elements at business layer (of

technical view) that are mapped to functional
elements (of functional view) include:
 1. Static data maintenance
 2. Transactions
 3. Workflows
 4. Batch Processing
 5. Business Rules
 6. Reporting
 7. Integration

BUSINESS LAYER
Some questions that provide an indication of the suitability of
the technical elements are:
1. Is static data maintenance required?
2. Would there be any batch processes?
3. What kind of transactions will be needed to provide the
business functions?
4. Would there be a need for workflow and rules engine
components?
5. Would there be a necessity for messaging?
6. Would there be a need to interface with other enterprise
applications
The mapping of functional elements to the technical elements for the LMS is
shown in Figure 5-8.
DATA ACCESS LAYER
 Provides encapsulated access to the data stored in the
underlying databases and other data stores.
 Various sources of data and the enterprise data model

are considered in arriving at the application data model
and the elements for the data access layer.
 Key technical elements for the data access layer are:

 Object relational, mapping elements
 Data access mechanisms

TECHNICAL VIEW
 For example, Figure 5-9 flows the technical view of the
business layer for .NET platform.

IMPLEMENTATION VIEW
 Represents the elements from which the solution is built
 Describes how the solution will be developed, deployed,

validated, managed and funded
 It is created by mapping elements in the technical view

to physical infrastructure
 SoftwareProducts
 Hardware servers
 Environment (Network used)

LEVEL 1 — BASELINE ARCHITECTURE
Summary
 Input: architecturally significant use cases
 Output: provides a solution to the requirements from

functional, technical and implementation perspectives.
 The architecture is validated by the IT department
 It becomes a baseline for

 the next level of architecture
 the design process

LEVEL 2— DETAILED
 At the start of the design process, baseline architecture is
further elaborated
 Several views are added that can form the basis of the design
process.
 Provides detailed architectural views based on the methodology
employed
 For Object-Oriented Analysis and Design(OOAD) methodology,
("4+1" views)
 use case view,
 logical view,
 process view,
 development view
 and deployment view
 A tool (such as IBM Rational Software Architect or Borland
Together Control Center Edition) is also often employed to model
the architectural elements
DETAILED ARCHITECTURE
 The Level 0 (high-level architecture) and
Level 1 (baseline architecture)
can be implemented with different methodologies such as
 Object-Oriented Analysis and Design (OOAD)
 Structured Systems Analysis and Design (SSAD)
 The DETAILED ARCHITECTURE would be an input to analysis and

design processes in the following stages of the development
cycle
 The views for this level are aligned with the methodology
adopted.
 Similar to the design views and are build on the architecture

views CSE Dept. MVGR College of Engineering 10/26/2021 83
DETAILED ARCHITECTURE
 What is the difference?
The views for detailed architecture are still abstractions
not meant to be programmed by developers
vs
Design views are detailed enough and meant to be
constructed by the use of development tools
 For OOAD methodology, the "4+1" views
 Each of the views can be modelled using UML

USE CASE VIEW
 Use cases describe user interactions with the application
 Functionality of the system can be described in terms of use

cases
 The architecturally significant use cases, are the key to

determining the suitable architecture.
 Use case view models are represented by means of use case

diagrams
 pictoriallydepict users (actors) of the system
 Interactions with the application.
 This view of architecture corresponds to the "+1" of the "4+1" views

and validates the other four views
 Logical, process,
CSE Dept. MVGRdevelopment
College of Engineering and deployment views
10/26/2021 85
LOGICAL VIEW
 describes the object model of an application that
satisfies the functional requirements described by
use cases.
 The object model is created by

 analysisof use cases
 Collaborations among Objects (Classes)
 For the architecturally significant use cases

 classesare defined
 These classes are mapped to design classes during the design
phase
DEVELOPMENT VIEW
 The development view represents software module
organization involving
 packages
 components
 along with their interconnections
 The artefacts include

 components, build scripts, source files, executables, etc.
 This view, describes the artefacts required to

assemble and release the application

PROCESS VIEW
 Deals with non-functional requirements
 Performance
 Scalability
 Throughput
 captures the run-time structure of the application.
 It models how running processes address
 concurrency
 synchronization aspects of the architecture
 A process is a group of tasks that form an executable unit
 process view models interactions of tasks and processes
of an application.
 Layers can be identified in this view that can have an
impact on hardware needed as well as the cost and quality
of service of the application
DEPLOYMENT VIEW
 describes the physical architecture of the system on
which the application is deployed (the environment)
 includes
 Nodes
 network topology
 other physical infrastructure
 The focus of deployment view is on

 Distribution
 Communication
 Provisioning of application

SOLUTION ARCHITECTURE FOR ENTERPRISE
APPLICATIONS BASED ON SOA
 SOA is one of the architectural styles used to architect
enterprise applications
 SOAD can be followed
 The solutions architecture for the enterprise

applications that expose the activity and client services
can also be specified using the solution architecting
process discussed above.

 The service model considerations provided in Section
5.1, however, need to also be addressed in the solution
architecture. The impact of these considerations on the
solution architecting process is as follows:
 1. Level 0 — High-level architecture:
 In order that the architecture of enterprise application
aligns with the enterprise -wide SOA, business process
model would be created and would form an input to
high-level architecture definition activities. The
reference architecture and the best practices
considered by the architect are those of services model
for arriving at the conceptual, logical and physical
views.
 2.Level 1— Baseline architecture:
 The services exposed and consumed by an application
are identified and patterns for SOA considered for
defining the functional, technical and implementation
views of Baseline architecture. For example, the
Enterprise Service Bus is a key pattern for integration
of services and this pattern is included as part of an
integration layer defined for the application.
 3. Level 2— Detailed architecture:
 While the 4+1 views used for 00AD can also be used for
the detailed architecture, the logical view is extended
to reflect the services model. A UML 2 Profile for
software services is an example of representing the
services model (Johnston, 2005).
END

UNIT-2: CSE Dept. MVGR College of Engineering 10/26/2021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UNIT-2: CSE Dept. MVGR College of Engineering 10/26/2021

Uploaded by

Copyright:

Available Formats

UNIT-2

CSE Dept. MVGR College of Engineering 10/26/2021 1

CSE Dept. MVGR College of Engineering 10/26/2021 2

CSE Dept. MVGR College of Engineering 10/26/2021 3

 Provides products or services

 Forward and Backward linkages to external agencies

 SOA suits well for enterprise level applications

 Refined over number of iterations to become the target

 Generic view of services

 Reuse, Integration, Agility require

 Different Types of Services (A, B, C, D)

 Integration based on ESB

 Infrastructure that enables Security and

CSE Dept. MVGR College of Engineering 10/26/2021 8

Business Process Services

Business Application Layer

 Services at Enterprise Level

Business Process Services

CSE Dept. MVGR College of Engineering 10/26/2021 10

 Encapsulate functionality exposed as services in various business

 Implement steps or activities of a business process

 are Reusable business services

Ex: “Inventory Service,” “Customer Management Service,” and

Control the flow and interaction

Externalization and orchestration

‘B’ type services

1) data stored across the enterprise

2) interaction with data sources outside the enterprise

 Commercial Products in the market

 Open Source Products

 Authorization (based on privileges)

 Imposing Security Policies

CSE Dept. MVGR College of Engineering 10/26/2021 15

 Different Types of Services (A, B, C, D)

 Integration based on ESB

 Infrastructure that enables Security and Service

CSE Dept. MVGR College of Engineering 10/26/2021 16

 Services grouped into layers based on the

 Enterprise Presentation Layer

of the business process

Business Process Process

CSE Dept. MVGR College of Engineering 10/26/2021 19

CSE Dept. MVGR College of Engineering 10/26/2021 21

CSE Dept. MVGR College of Engineering 10/26/2021 22

 Use cases realized through analysis that produces classes

 Identify class hierarchy/inheritance

 Map classes to technology elements (design classes, framework

 Design classes implemented 10/26/2021

Granularity type Fine grained Coarse grained

Granularity level class service

coupling Tight coupling Loose coupling

Inheritance produces Service provider and

Runtime Assume object Can Discover the

 Difficult to directly use OOAD for SOA

 OOAD powerful to address some parts of SOA

 Extend the OOAD to SOA to include

 Service Oriented Analysis and Design process (Fig. 4.4)

CSE Dept. MVGR College of Engineering 10/26/2021 25

 Gather Business Objectives

 Business Process Model

 Business Process Model is a key artefact in SOAD

CSE Dept. MVGR College of Engineering 10/26/2021 26

 input to four sub-processes is the business process

 The service integration phase