Future_of_Blockchain_Technology_Styled.pptx

Kongunadu College of Engineering and
Technology
Department of Computer Science and Engineering
20IT703PE-SERVICE ORIENTED
ARCHITECTURE
By,
Mr.K.Karthick , AP / CSE

UNIT I
SERVICE ORIENTED
ARCHITECTURE (SOA) BASICS

 Characteristics of SOA.
 Benefits and Pitfalls of SOA.
 Roots of SOA: Comparing SOA to client server and
distributed internet architectures.
 Anatomy of SOA.
 How components in an SOA interrelate.
 Principles of service orientation.
 Service Layers.

Service Oriented Architecture (SOA)
What is SOA
Service-oriented architecture (SOA) is a method of software
development that uses software components called services to create
business applications.
Each service provides a business capability, and services can also
communicate with each other across platforms and languages.
 Developers use SOA to reuse services in different systems or
combine several independent services to perform complex tasks.

Service
What is Service
A service is a well-defined, self-contained function that represents a
unit of functionality.
A service can exchange information from another service. It is not
dependent on the state of another service.
It uses a loosely coupled, message-based communication model to
communicate with applications and other services.
Example of Service
– Weather Services can be used to get the weather information.
– Any application on the network can use the service of the
Weather Service to get the weather information.

Service Connection
 Service consumer sends service request to the service provider
 Service provider sends the service response to the service
consumer.
 Service connection is understandable to both
– Service consumer and service provider
Service request
Service response
Service consumer Service provider

Service-Oriented Terminologies

Service-Oriented Terminologies
 Services - The services are the logical entities defined by one or more
published interfaces.
 Service provider - It is a software entity that implements a service
specification.
 Service consumer - It can be called as a requestor or client that calls
a service provider. A service consumer can be another service or an
end-user application.
 Service locator - It is a service provider that acts as a registry. It is
responsible for examining service provider interfaces and service
locations.
 Service broker - It is a service provider that pass service requests to
one or more additional service providers.

Characteristics of Contemporary SOA
 Contemporary SOA is at the core of the service-oriented computing platform.
 Contemporary SOA increases quality of service.
 Contemporary SOA is fundamentally autonomous.
 Contemporary SOA is based on open standards.
 Contemporary SOA supports vendor diversity.
 Contemporary SOA fosters intrinsic interoperability.
 Contemporary SOA promotes discovery.
 Contemporary SOA promotes federation.
 Contemporary SOA promotes architectural composability.
 Contemporary SOA fosters inherent reusability.
 Contemporary SOA emphasizes extensibility.
 Contemporary SOA supports a service-oriented business modeling paradigm.
 Contemporary SOA implements layers of abstraction.
 Contemporary SOA promotes loose coupling throughout the enterprise.
 Contemporary SOA promotes organizational agility.
 Contemporary SOA is a building block.
 Contemporary SOA is an evolution.
 Contemporary SOA is still maturing.
 Contemporary SOA is an achievable ideal.

Contemporary SOA Is …
• At the core of the service-oriented platform
– The term SOA has come to have several meanings
Including a new computing platform as well as an architectural
approach
– Contemporary SOA is building upon and extending the primitive SOA model
– A starting point for contemporary SOA definition
Contemporary SOA represents an architecture that
promotes
service-orientation through the use of Web services

• Traditional architectural qualities such as "secure," "transactional," "reliable”
– Have been grouped into "Contemporary SOA increases quality of service" characteristic.
• Increases quality of service but there is more yet to be done in this area
– Tasks need to be carried out in a secure manner, protecting the message content
– Tasks to need to be carried out reliably
So that message delivery or notification of failed delivery is guaranteed
– Performance needs to be enhanced for SOAP and XML processing
– Transaction processing enhancement for task failure

• Fundamentally autonomous
– Individual services need to be as independent and self-contained as possible
– This is realized through message-level autonomy
– Messages are “intelligence-heavy” and control the way they are processed by
recipients
– Application that are comprised of autonomous services can be viewed a
composite, self-reliant services

• Based on open standards,
– Messages travel b/w services via a set of protocols is globally standardized and
accepted
– Message format is standardized, too.
– SOAP, WSDL, XML, & XML Schema allow messages to be fully self-contained
– For services to communicate, they only need to know of each other’s service
description.
– This supports loose-coupling
– This limits the role of proprietary technology
Standard open technologies are used within and outside of solution boundaries

• Supports vendor diversity
– Communications framework bridges the heterogeneity within and between corporations
– Any development environment that supports web services can be used to create
a non-proprietary service interface layer
– Integration technologies encapsulate legacy logic through service adapters
Disparate technology platforms do not prevent service-oriented solutions
from interoperating

• Promotes discovery
– Universal Description Discovery & Integration (UDDI) provided for service
registries
– Few early SOA systems used UDDI
Registries enable a mechanism
for the discovery of services
Intrinsically interoperable services
enable unforeseen integration
opportunities

• Promotes federation
– Establish SOA in an enterprise doesn’t require replacement of what you have
– SOA helps establish unity across non-federated environments
– Legacy logic is exposed via a common, open, & standardized communication
n/w
Services enable standardized federation of disparate legacy systems

• Promotes architectural composability
– Supports the automation of flexible, adaptable business process by composing
loosely coupled services
– Web service framework is evolving with the release of numerous WS-*
specifications that can be composed
– WS-* specification leverage SOAP messaging

Different solutions can be composed of different extensions and can continue
to interoperate as long as they support the common extensions required

• Fosters inherent reusability
– Service-oriented design principles encourage reuse of software
– Services can be composed into larger services which in turn can be reused
– Services are agnostic in regard to business processes and automation solutions
Inherent reuse accommodates
unforeseen reuse opportunities

• Emphasizes extensibility
– When encapsulating functionality through a service description, you are
encouraged to think beyond a point-to-point solution
– With appropriate granularity, the scope of a service can be extended without
breaking an established interface
Extensible services can expand
functionality with minimal impact

SOA Definition
Contemporary SOA represents an
open, extensible, federated, composable architecture
that promotes service orientation
and is comprised of
autonomous, QoS-capable, vendor diverse,
interoperable, discoverable,
and potentially reusable services,
implemented as Web services

• Supports a service-oriented business modeling paradigm
– Business processes are modeled with services and cut vertically through
business logic
– BPM models, entity models and other forms of business intelligence can be
accurately represented through coordinated composition of business-centric
services
A collection (layer) of services
encapsulating business process logic

• Implements layers of abstraction
– SOAs introduce layers of abstraction by positioning services as the sole access
points to a variety of resources and processing logic
Application logic created with proprietary technology can be
abstracted through a dedicated service layer.

Through the implementation of service layers that abstract business and
application logic, the loose coupling paradigm can be applied to the
enterprise as a whole.

• Promotes organizational agility
– High dependency between parts of an enterprise means that changing software
is more complicated and expensive
– Leveraging service business representation, service abstraction, and loose
coupling promotes agility

A loosely coupled relationship between business and application technology
allows each end to more efficiently respond to changes in the other.

• Is a building block
– Services are composed into larger services
– Multiple SOA applications can be pulled into service-oriented integration
technologies to help build a Service-Oriented Enterprise (SOE)

Appending the SOA Definition
SOA can establish
an abstraction of business logic and technology,
resulting in a loose coupling
between these domains.
These changes foster service-orientation
in support of a service-oriented enterprise

• Is an evolution
– SOA is a distinct architecture from its predecessors
– Different from client-server technology in that it is influenced by concepts in
service-orientation and Web services
– Promotes reuse, encapsulation, componentization, and distribution of
application logic like previous technologies
• Is still maturing
– Standards organization and vendors are continuing to develop new SOA
technologies

• Is an achievable ideal
– Moving an enterprise toward SOA is a difficult and enormous task
– Many organizations begin with a single application and then begin leveraging
services into other applications
– Changing to SOA requires cultural changes in an organization

Finalized SOA Definitions
SOA is an evolution of past platforms,
preserving successful characteristics of
traditional architectures, and bringing with it
distinct principles that foster service-orientation
in support of a service-oriented enterprise
SOA is ideally standardized throughout an
enterprise, but achieving this state requires a
planned transition and the support of a still
evolving technology set

Defining SOA
• A definition that can be applied to both primitive and contemporary SOA
SOA is a form of technology architecture that adheres to the principles of
service-orientation. When realized through the Web services technology
platform, SOA establishes the potential to support and promote these principles
throughout the business process and automation domains of an enterprise.

Misconceptions about SOA
• An application that uses Web services is service-oriented
• SOA is just a marketing term used to rebrand distributed computing with
Web services
• SOA simplifies distributed computing
• An application with Web services that uses WS-* extensions is service-
oriented
• If you understand Web services you won’t have a problem building SOA
• Once you go SOA, everything becomes interoperable

Benefits of SOA
• Improved integration and intrinsic interoperability
• Inherent reuse
• Streamlined architectures and solutions
• Leveraging of legacy investment
• Establishing standardized XML data representation
• Focused investment on communication infrastructure
• Best of breed alternatives
• Organizational agility

Improved integration (and intrinsic interoperability)
• SOA can result in the creation of solutions
– That consist of interoperable services.
• Utilizing solutions based on interoperable services is part of SO integration (SOI)
– And results in a service-oriented integration architecture.
• Net result is interoperability
– It turns a cross-application integration project into less of a custom development
effort, and more of a modeling exercise.
• Bottom line:
– Cost and effort of cross-application integration is significantly lowered
when applications being integrated are SOA-compliant.

Inherent reuse
• SO promotes the design of services that are inherently reusable.
• Designing services to support reuse
– Increased opportunities for leveraging (influence) existing automation logic.
• Bottom line:
– Building services to be reusable, results in increased development effort
and requires the use of design standards.
– Leveraging reuse within services lowers the cost and effort of building service-
oriented solutions.

Streamlined architectures and solutions
• Concept of composition is another fundamental part of SOA.
– It is not, limited to assembly of service collections into aggregate services.
• The WS-* platform is based on the principle of composability.
• This aspects can lead to highly optimized automation environments
• Bottom line:
– Requires adherence (devotion) to design standards
– Benefits of streamlined solutions and architectures include the potential for
reduced processing overhead and reduced skill-set requirements

Leveraging the legacy investment
• Industry-wide acceptance of Web services technology
– Enables legacy (inheritance) environments to participate in SOI architectures.
• This allows IT departments to work toward a state of federation,
– Previously isolated environments now can interoperate without requiring
the development of expensive integration channels.
• Bottom line:
– Cost and effort of integrating legacy and contemporary solutions is lowered.
– Need for legacy systems to be replaced is potentially lessened.

Establishing standardized XML data representation
• SOA is built upon and driven by XML.
– This leads to the opportunity to fully leverage the XML data representation
platform.
• A standardized data representation format
– Reduce the complexity of all affected application environments.
• Bottom line:
– Cost and effort of application development is reduced after a proliferation of
standardized XML data representation is achieved.

Focused investment on communications
infrastructure
• Because Web services establish a common communications framework,
– SOA can centralize inter-application and intra-application communication
as part of standard IT infrastructure.
• This allows organizations to evolve enterprise-wide infrastructure
– By investing in a single technology set responsible for communication.
• Bottom line:
– Cost of scaling communications infrastructure is reduced, as only one
communications technology is required to support the federated part of the
enterprise.

"Best-of-breed" alternatives
• Major criticisms against IT departments are related to
– Restrictions imposed by a given technology platform on its ability to fulfill the
automation requirements of an organization's business areas.
• This can be
– Due to expense and effort required to realize the requested automation, or
– May be the result of limitations inherent within the technology itself.
• Either way, IT departments are frequently required
– To push back and limit or even reject requests to alter or expand upon existing
automation solutions.

"Best-of-breed" alternatives
• A key feature of service-oriented enterprise environments is
– Support of "best-of-breed" technology.
• Because SOA establishes a vendor-neutral communications framework,
– It frees IT departments from being chained to a single proprietary development
and/or middleware platform.
• For any given piece of automation, you now have a choice as to how you
want to build the service that implements it.
• Bottom line:
– Potential scope of business requirement fulfillment increases, as does the quality
of business automation.

Organizational agility
• Accommodating change becomes the norm in distributed solution design,
– So qualities such as reuse and interoperability become commonplace.
• Predictability of these qualities within the enterprise
– Leads to a reliable level of organizational agility.
• Building automation solutions and supporting infrastructure
– With the anticipation of change seems to make a great deal of sense.

• A standardized technical environment comprised of
– Loosely coupled, composable, and interoperable and potentially reusable services
• Such environment establishes a more adaptive automation environment
– That empowers IT departments to more easily adjust to change.
• Bottom line:
– Cost and effort to respond and adapt to business or technology-related change is
reduced

 Agility is a quality inherent in just about any aspect of the enterprise.
 A simple algorithm, a software component, a solution, a platform,
 a process all of these parts contain a measure of agility related to
how they are constructed, positioned, and leveraged.
 How building blocks can be realized (understand) and maintained
within existing financial and cultural constraints ultimately determines
the agility of the organization as a whole.

 A standardized technical environment comprised of loosely coupled,
composable, and interoperable and potentially reusable services
establishes a more adaptive automation environment that empowers IT
departments to more easily adjust to change.
 The bottom line: The cost and effort to respond and adapt to business or
technology-related change is reduced

Pitfalls of adopting SOA
• Building SOAs like traditional distributed architectures
• Proliferation of RPC-style service descriptions (increased volumes of fine-
grained message exchanges)
• Inhibiting the adoption of features provide by WS-* specifications
• Improper partitioning of functional boundaries within services
• Creation of non-composable services
• Entrenchment of synchronous communications
• Creation of non-standardized services

Pitfalls of adopting SOA
• Not standardizing SOA in the enterprise
• Not creating a transition plan
• Not starting with an XML foundation architecture
• Not understanding SOA performance requirements
• Not understanding Web services security
• Not keeping in touch with product platforms and standards development

Roots of SOA: Comparing
SOA to client-
server and distributed
internet architectures

Roots of SOA
• With the rise of multi-tier applications,
– The variations with which applications could be delivered began to increase.
• A definition of a baseline application becomes important.
– Definition is abstract in nature,
– But explain the technology, boundaries, rules, limitations, and design ch.s that
apply to all solutions.
• This was the birth of the application architecture.

Application architecture
• Application architecture is a blueprint to a team of construction workers
– It reflects immediate solution requirements, as well as long-term, strategic IT goals
• Different company have different levels of application architecture .
• Some keep it high-level,
– Providing abstract physical & logical representations of the technical blueprint.
• Others include more detail, such as
– Common data models, Communication flow diagrams, Application-wide security
requirements, and Aspects of infrastructure.
• Multiple application architectures may exist within an organization
– And kept in alignment by an enterprise architecture

Enterprise architecture
• Enterprise architectures provide
– A high-level views of all forms of heterogeneity that exist within an enterprise
• This document
– Contain a long-term vision of how an organization will evolve its technologies
• Relationship b/w an urban plan & blueprint of a building are comparable to
that of enterprise and application architecture specifications
• Changes to enterprise architectures directly affect application architectures

Service Oriented Architecture (SOA)
• An SOA can refer to
– An application architecture or
– The approach used to standardize technical architecture across the enterprise
• It spans both enterprise and application architecture domains
• Benefits of SOA are realized when applied across multiple solution environments
• Because SOA is a composable architecture,
– A company may have multiple SOAs
• Web services platform offers a form of implementation for SOA.

Comparing SOA with
Client-Server
-

Client Server
• A software requests or receives information from another can be referred to
as "client-server.“
• Mainframes provided the
first “client-server”
computing with
synchronous and
asynchronous
communication

Client-Server Characteristics
• Bulk of application logic resides
with the client
• Business rules were maintained on
the DB
• This abstracted a set of business
logic from the client and simplified
data access programming
• Overall, the client ran the show
Two-tier Client-Server

SOA Characteristics
• Presentation layer can be any s/w capable of exchanging SOAP messages
• SOA principles
– Dictate partitioning logic into autonomous units
• Ultimate goal is
– To promote reuse & loose coupling across application boundaries

Client-Server Application Processing
• 80% - workstation, 20% server
• Even so, the database is often the bottleneck
• Two-tier solutions usually mean each client has a database connection
– Connections are often synchronous and persistent
• 80% processing on client may mean client programs run exclusively

SOA Processing
• Processing with SOA is highly distributed
– With SOA there is no fixed processing ratio
• Each service has explicit functional boundaries and resource requirements
• SOA allows many options for deploying services
• Supports synchronous & asynchronous communication
– B/w service and requestors
• Enterprise solutions consist of multiple servers
– With sets of Web services and supporting middleware

SOA Processing
• Messages are loaded with intelligence to support message-level context
management
• Smart messaging promotes stateless and autonomous services

Client-Server Application Technology
• Client-server applications promoted the use of 4GL programming languages
– Like VB and PowerBuilder, RDBMSs
• Traditional 3GL languages, such as C++, were also still used
• On the back-end, major database vendors provided RDBMSs
– Such as Oracle, Informix, IBM, Sybase, and Microsoft

SOA Technology
• SOA technology set has
– Expanded to include Web technologies (HTML, CSS, HTTP, etc)
• In addition, SOA requires the use of
1. XML data representation architecture,
2. A SOAP messaging framework, and
3. A service architecture (comprised of the ever-expanding Web services platform)

Security
• Client-Server Application Security
– Centralized at the Server level
– Databases manage user accounts and groups
– Also controlled within the client executable
• Security for SOA is much more complex
– Security complexity is directly related to degree of security measures required
– Multiple technologies are required, many in WS-Security framework

Client-Server Application Administration
• Significant maintenance costs associated with client-server
– Each client housed application code
– Each update required redistribution
• Client stations were subject to environment-specific problems
• Increased server-side demands on databases

SOA Administration
• SOA solutions are not immune to client-side maintenance challenges
• Distributed back-end supports scalability,
– But new admin demands are introduced
• Management of server resources and service interfaces
– May require new admin tools and even a private registry
• Commitment to services and their maintenance
– May require cultural change in an organization

SOA vs Client Server
• A software requests or receives information from another can be referred to
as "client-server.“
• Mainframes provided the first “client-server” computing with synchronous
and asynchronous communication
• CICS – conversational and nonconversational mode
• 1980s – two-tier client server with fat clients, GUI, database. Dominated the
90s

Comparing SOA with
Distributed
Architectures

Application Logic of Distributed Architecture
• Distributed Internet application put all the application logic on server side
– Even client-side scripts are downloaded from the server
• Entire solution is centralized
• Emphasis is on:
1. How application logic is partitioned
2. Where partitioned units reside
3. How units of logic should interact

Application Logic of Distributed Systems
• This systems create components that reside on one or more application servers
– Components on the same server communicate via proprietary APIs.
– RPC protocols are used across servers via proxy stubs
• Actual references to other physical components can be embedded in programming code
(tight coupling)
Components rely on proxy stubs for remote communication

Application Logic of SOA
• From a physical perspective, SOA is very similar to distributed Internet architecture.
• Provider logic resides on the server end where it is broken down into separate units.
• Differences lie in principles used to determine the 3 primary design considerations

• SOAs also rely on components
• SOA uses the services to encapsulate components
• Services expose a specific sets of functionality
• Purpose of wrapping functionality within a service is
– To expose that functionality via an open, standardized interface, irrespective of
technology providing the solution
• Use of Web services establishes a loosely coupled environment
– This introduces continual opportunities for reuse and extensibility

• Services exchange information via SOAP messages
– SOAP supports RPC-style and document-style messages
– Most applications rely on document-style
• Messages are structured to be self-sufficient
• Messages contain meta information, processing instructions, policy rules
• SOA promotes reuse and cross-application interoperability on a deep level

Application Processing
• Distributed Internet architecture
– Promotes the use of proprietary communication protocols (DCOM, CORBA) for
remote data exchange
• SOA relies on message-based communication
– This involves serialization, transmission, de-serialization of SOAP messages
containing XML payloads
• RPC communication is faster than SOAP
– And SOAP processing overhead is a significant design issue

Application Processing
• SOA messaging framework
– Support a wide range of message exchange patterns.
• Though synchronous communication is fully supported
– Asynchronous patterns are encouraged to optimize processing by minimizing
communication
• Support for stateless services is supported by context management options
(WS-Coordination, WS-BPEL)

Technology
• Distributed Internet architecture now includes XML data representation
• XML and Web services
– Optional for distributed Internet architecture but not for SOA

Security
• When application logic crosses physical boundaries,
– Security becomes more difficult
• Traditional security architectures incorporate
– Delegation and impersonation as well as encryption
• SOAs depart from this model
– By relying heavily on WS-Security to provide security logic on messaging level
• SOAP messages carry headers where security logic can be stored

Administration
• Maintaining component-base applications involves:
1. Keeping track of individual components
2. Tracing local and remote communication problems
3. Monitoring server resource demands
4. Standard database administrative tasks
• Distributed Internet Architecture
– Introduces the Web server and its physical environment
• SOA requires additional runtime administration:
– Problems with messaging frameworks
– Additional administration of a private or public registry of services

SOA vs Traditional Distributed Internet
Architecture
• Multiple client-server architectures have appeared
• Client-server DB connections have been replaced with Remote Procedure
Call connections (RPC) using CORBA or DCOM
• Middleware application servers and transaction monitors require significant
attention
• Multi-tiered client-server environments began incorporating internet
technology in 90s.

Anatomy of SOA-
HOW
COMPONENTS
IN AN SOA
INTERRELATED

Includes
1. Logic components of the Web services framework
2. Logic components of automation logic
3. Components of an SOA
4. How components in an SOA inter-relate

Logic components of Web services framework
• Web services contain one or more operations.
A Web service sporting two operations

• Each operation governs the process of a specific function
– The web service is capable of performing.
An operation processing
outgoing and incoming SOAP messages

• Web services form an activity
– They can collectively automate a task
A basic communications scenario b/w Web services

Activity has been changed
because it uses a different context
when modeling service-oriented business processes.

Messages = units of communication
Operations = units of work
Services = units of processing logic
Processes = units of automation logic
A primitive view of how SOA modularizes automation logic into units.

A primitive view of how units of communication enable
interaction b/w units of logic

Components of an SOA
• Message
– Represents the data required to complete some or all parts of a unit of work.
• Operation
– Represents the logic required to process messages in order to complete a unit
of work.
The scope of an operation within a process

Components of an SOA
• Service
– Represents a logically grouped set of operations capable of performing related units of
work.
• Process
– Contains the business rules that determine which service operations are used to complete
a unit of automation.
– A process represents a large piece of work that requires the completion of smaller units of
work.
Operations belonging to different services representing
various parts of process logic

How components in an SOA inter-relate
• An operation sends and receives messages to perform work.
• •An operation is therefore mostly defined by the message it processes.
• •A service groups is a collection of related operations.
• •A service is therefore mostly define by the operations that comprise it.
• A process instance can compose service.
• •A process instance is not necessarily defined by its service because it may
only require a subset of the functionality offered by the services.
• •A process instance invokes a unique series of operations to complete its
automation.
• •Every process instance is therefore partially defined by the service
operation it uses.

How the components of a SOA relate

How the components of a SOA define each other

Key Points
• The logical parts of an SOA can be mapped to corresponding components
in the basic Web services framework.
• By viewing a service-oriented solution as a unit of automation logic, we
establish that SOA consists of a sophisticated environment that supports a
highly modularized separation of logic into differently scoped units.
• SOA further establishes specific characteristics, behaviors, and
relationships among these components that provide a predictable
environment in support of service-orientation

principles of service-orientation

principles of service-orientation
 Services are reusable
 Services share a formal contract
 Services are loosely coupled
 Services abstract underlying logic
 Services are composable
 Services are autonomous
 Services are stateless
 Services are discoverable

Services are reusable
 Service Reusability is a design principle that is used to create services
(collection of related operations) that have the potential to be reused
across the enterprise resources.
Reusability includes:
• Inter-application interoperability
Composition
• Creation of cross-cutting or
utility services
• Logic is divided into
services with the intention of
promoting resuse.

Services Share a Formal Contract
 The service endpoint
 Each service operation
 Every input and output message
supported by each operation
 Rules and characteristics of the
service and its operations

Services are loosely coupled
 Loose coupling is a condition wherein a service acquires knowledge
of another service while still remaining independent of that service.
 It is achieved through the use of service contracts that allow
services to interact within predefined parameters.

Services abstract underlying logic
Service provides the following
Simple task to perform
Gateway to an entire automation
solution
Represent limitless amount of logic
 Act as a Containers for the
operations that abstract the logic

Services are composable
 Collections of services can be coordinated and assembled to form
composite service

Services are autonomous
 An autonomous service is a service whose ability to function is not
controlled
 Services have control
over the logic they
Encapsulate.

Services are stateless
 Service minimize retaining information specific to an activity

Services are discoverable
 Discoverability-services are designed to be outwardly descriptive so
that they can be found and assessed via available discovery
mechanisms.

Service layer abstraction
• Service interface layer
– Located b/w the business process and application layers
– This is where service connectivity resides
• To implement the unsupported ch.s, answer the following questions
– What logic should be represented by services?
– How should services relate to existing application logic?
– How can services best represent business process logic?
– How can services be built and positioned to promote agility?
• Answered during the service-oriented analysis phase. In that phase,
– Services are carefully modeled in accordance with and in response to external
business and project drivers.

What logic should be represented by services?
• Enterprise logic can be divided into two primary domains:
– Business logic and application logic.
• Services can be modeled to represent either or both types of logic
• To achieve enterprise-wide loose coupling,
– Physically separate layers of services are required
• This allows the automated representation of business process logic
– To evolve independently from the technology-level application logic
(responsible for its execution).
• In other words,
– This establishes a loosely coupled relationship b/w business and application logic.

Business logic vs Application logic

Future_of_Blockchain_Technology_Styled.pptx

How should services relate to existing application logic?
• Business logic is defined
– Within an organization's business models and business processes
• When modeling services to represent business logic,
– Ensure that the service representation of this logic is in alignment with existing
business models
• Refer to services that have been modeled to represent business logic
– As belonging to the “business service layer”
• By adding a business service layer,
– Implement the 2nd
of our 4 SOA ch.s, which is support for SO business modeling

Three primary service layers
• 3 layers of
abstraction
are identified
for SOA

How can services be built and positioned to promote agility?
• key to building an agile SOA is in
– Minimizing the dependencies each service has within its own processing logic
• Introduce a parent controller layer on top of specialized service layers
– To establish a centralized location for business rules and composition logic
(related to the sequence in which services are executed)
• Orchestration service layer is designed specifically for this purpose.
• Addition of an orchestration service layer
– Significantly increases organizational agility

Application service layer
• This layer establishes the ground level foundation
– That exists to express technology-specific functionality
– The application service layer consists of application services that represent technology-
specific logic.
• Services that reside within this layer are referred as application services
• Purpose of application services is to provide reusable functions
– Related to processing data within new or legacy application environments.

• Application services commonly have the following characteristics
– they expose functionality within a specific processing context
– they draw upon available resources within a given platform
– they are solution-agnostic
– they are generic and reusable
– they can be used to achieve point-to-point integration with other application services
– they are often inconsistent in terms of the interface granularity they expose
– they may consist of a mixture of custom-developed services and third-party services that
have been purchased or leased
• Examples of service models implemented as application services include :
– utility service
– wrapper service

• Application services are responsible for representing technology and
application logic
• Application services are ideally reusable utility services
– Composed by business services,
– But also can exist as hybrid services that contain both business and application logic.

Business service layer
• Business service layer introduces a service concerned with representing
business logic, called the business service

Business service layer
• Business services
– Responsible for expressing business logic through service-orientation and
– Bring the representation of corporate business models into the Web services arena
• Business services are always an implementation of business service model
• This also implement other service models.
– Ex : A business service also can be classified as a controller service and a utility service.
• Business services will act as controllers
– To compose available application services to execute their business logic

 Task-centric business service
A service encapsulates business logic specific to a task or business
process.
• Limited reusability
 Entity-centric business service
A service encapsulates a specific business entity
• Highly reusability

Orchestration service layer
This layer introduces a
parent level of abstraction
that ease the need for
other services to manage
interaction details
required to ensure that
service operations are
executed in a specific
sequence

Orchestration service layer
• Orchestration service layer extends the reach of service-orientation
• The orchestration service layer consists of one or more process services
that compose business and application services according to business rules
and business logic embedded within process definitions
• When incorporated as part of a SOA,
– Orchestration assumes the role of the process
• Orchestration is valuable to us than a standard business process,
Since it allows us to directly link process logic to service interaction within our workflow
logic
– This combines business process modeling with service-oriented modeling and
design.

Future_of_Blockchain_Technology_Styled.pptx

More Related Content

Similar to Future_of_Blockchain_Technology_Styled.pptx (20)

Recently uploaded (20)

Future_of_Blockchain_Technology_Styled.pptx