Service-oriented architecture (SOA) is a method of software development that uses software components called services to create business applications.

Processes in SOA
Click to edit Master subtitle style

 SOA brings new dimensions to the design, management, and technical support of
business processes.
 The fundamental concepts of business processes have not changed, but SOA brings a
discipline for composition, security, accountability, and sharing of capabilities.
 SOA brings the fundamental design principle that a process begins and ends within its
associated service unit so it is under the control of the service unit manager.
 Capabilities delegated to other service units are engaged by requests to the other service
units, invoking their internal processes.
Introduction

 SOA defines an architecture for processes, processes define how services are performed and interact.
 A service unit is not implemented with a single process but is a bundle of processes that provide access
to its capability in different ways, provide information to service users, and internally manage its
capabilities.
 Processes support the exchange of messages between service units that is required for loose coupling
and different modes of interaction.
 Finally, services sharing creates the need for control of access to processes.
Introduction

 a service unit functions is driven by its business processes.
 business processes, where appropriate, engage other services by initiating the business processes of the
other service units.
 Consequently, the integration of service units is typically a relationship between business processes.
 not all business processes are implemented with a BPMS—some may be manual and some may be
embedded in applications.
Process-Driven Services

Processes Within Service Units.
1. Service Unit A accepts two kinds
of service requests (M and N)
(two arrows entering from the
top).
2. Process M has an activity that
invokes an application, an
activity that invokes another
service, and an activity that
invokes a shared subprocess.
3. The activity that invokes
another service has a role filled
by that service (designated by
the small, pentagon element).

4. The shared subprocess is used by
different processes within Service
Unit A but is not shared outside
Service Unit A, so it is not a service
offered by Service Unit A.
5. It is not selected from
alternatives, so it is not filling a role
that would be selected based on a
role capability specification.

6. Process N shares the subprocess
with process M.
7. It also has an activity that
contains an embedded subprocess
and another activity performed by a
person.

8. The embedded subprocess is
essentially a bounded set of
activities within Process N that
supports treating those activities as
a unit for such actions as
termination and compensation
(reversing the effects when a failure
occurs).
9. The person fills a role (again
designated by the small pentagon
element).

 a service unit provides a capability that may be offered in different ways; that is, requests may invoke
different services.
 Different services initiate different processes within the service unit.
 a service unit is not a single business process but rather a bundle of processes that provide access to a
shared capability.
 process reflects the primary purpose of the service, but if the requested process is long running or the
same capability is used in different ways.
 The request requirements are more likely to change during a long-running process.
 For any requested service, the service user may want to change or cancel the request, or the user may
want to obtain information on the request status.
 A service unit may offer the ability to obtain a price quote or forecast of delivery date prior to sending
a request for its primary service.
 Complex processes are likely to involve specialized subprocesses within the service unit.
Multiple Services of a Service Unit

 Services such as change, cancel, or status check, however, are dependent on a pending request.
 The initial request establishes a context and an identifier for reference to that context, such as an
order number.
 Subsequent requests related to that original request contain the context identifier and are expected
to perform appropriate actions in the identified context.
 The process maintains data regarding that context until the request is either completed or otherwise
terminated.
 Afterward, historical data may be accessed using the same identifier.

 A service may accept different forms of request for different categories of customers or
different product lines.
 Though this may increase the complexity of the service, it can improve the service's usability for
service users.
 Different forms of request may also be used to enable a transition when technology or changing
business requirements call for modification to the service interface.
 A new form of service request can be made available to transitioned service users while the old
form of service request continues to be available for those service users who have not yet
implemented the change.
 Internally to the service unit, it might be necessary to define different business processes for
each of the input forms, but those may invoke shared internal business processes to drive the
internal activities.

 is commonly used to describe a store-and-forward, messaging linkage for integration where the
relationship is defined by the messages exchanged.
 Service units generally interact through loose coupling to enable autonomy of participants.
 For a service unit to most effectively manage its resources and processes, it should not be driven
immediately and directly by the processes of its users nor controlled by the processes of the services it
uses.
 And from the service user's viewpoint, there may be delay between the receipt of a request and action
taken on the request.
 Therefore, the service user should consider proceeding with related work rather than stopping to wait for
the requested service to be completed.
 Loose coupling also enables a service user to abandon a request if there is not a timely response,
although this assumes that actions can be taken to compensate for activities already completed.
Loose Coupling

 Loose coupling also enables continuous improvement of a service.
 The expectations of service users should create minimal constraints on how the service is performed.
 The service provider should be able to design its internal processes with an understanding of the
types of requests it will receive to support optimization, but it should not need to know how its users
are performing their processes.
 The service provider should be able to continuously improve its processes without requiring changes
by its users.
 It should also design its services to support future users addressing new business needs.
Loose Coupling

The following list describes aspects of a relationship that affect the degree of coupling:
Serialization
• refers to a relationship where the service must be completed before the user activity can
proceed.
• may create a risk that the result of the service adversely affects the additional work done
by the user, thus causing rework and possible defects.
Collaboration
• occurs when the user and provider continue to interact during the performance of the
service activity.
• Changes to either the service requester or the service provider are constrained by the
degree of coupling in this interaction.
Shared work
product
• If the service user and service provider concurrently work on the same work product
• there is a risk that there could be conflicting changes or competing access requirements
that could delay progress.
• Certainly the processes of each are constrained by the need for cooperation and
coordination.
Loose Coupling

Shared
Resources
• include equipment, people, or other facilities that must be scheduled or require
coordinated use.
• more difficult to ensure performance if a service unit does not control all its resources
• sharing can reduce costs through better utilization of the shared resource.
• Sharing is less likely to occur between a service user and service provider than is sharing
between peer services that have similar capabilities or multiple executions of the same
process.
• Requirements for liaison or progress review may involve sharing personnel and
schedules for certain activities.
The following list describes aspects of a relationship that affect the degree of coupling:
Loose Coupling

 The most straightforward transfer of value occurs when a service requester provides the required
work product and materials with a request and the resulting work product is returned with the result.
 Then the value chain dependency corresponds to the request-response transfer.
 service units often receive materials from sources other than a service requester—thus another
dependency, and the resulting value or work product is often delivered to a recipient other than the
service requester (a different destination than the service response)—to satisfy another dependency.
 These transfers of value may take a variety of forms from a business process perspective. They are
essentially exchanges with other service units.
Transfer of Value

 The transfers could be implemented as request-response exchanges with the other services units. For
example, a warranty repair service may receive a product with a request for repair and then after it is
repaired give it to a shipping service to send it back to the customer.
 The response to the original request would confirm that the product was returned to the customer.
 To make the repair, the warranty repair service may diagnose a problem and then request replacement
parts from other sources, potentially from a spare parts inventory activity or from an outside source.
Transfer of Value

• Sharing services increases security risks.
• Services may be engaged by many more people from across the enterprise and possibly from business
partners.
• Systems of many different organizations may submit requests, and a service unit may submit requests to
services in many different organizations.
• Some of these other organizations may be external to the enterprise, and it is possible that service units
that are internal today could be outsourced tomorrow.
Security

• Some services are used through a simple request-and-response interchange.
• The service user requests information and the information is returned, and there is no need to specify
the interaction further.
• many transactions, particularly in an e-business context, are more complex and take the form of a
collaboration.
• Often the exchange involves negotiation and possibly the participation of multiple organizations such as
for financing and transportation after a sale.
A choreography is an essential part of a business-to-business agreement between service users and
service providers.
Choreography

• more complex exchanges, it is important that participants in the exchange agree on the
sequence of exchange and possible alternative responses.
• A specification of the agreed-on sequence of exchanges is called a choreography.
 The choreography is a description of the interactive behavior of the participants.
 The interaction is a product of the internal operations of both parties.
 The choreography is not executed like a typical business process but instead defines an agreement
between the parties
Sequence of Exchange

Order Placement Choreography.
• The choreography has a start and end the
same as other processes.
• The rounded boxes designate interactions,
that is, a message exchange as opposed to
work being done.
• The solid arrows between interactions
define the sequence of exchanges.
• A dashed line indicates the
communication of a message from one
participant to another.
• Gateway (diamond-shaped) element in
the choreography indicates alternative
paths.
Sequence of Exchange

Order Taker Process.
Within the Order Taker's internal process:
1. Order Placer is a role,
2. Order Taker is the service provider,
3. Order Placer is service user.
The Order Taker's process is aligned to the
choreography, but its internal process is actually
more complex involving two decisions and
fulfillment and billing activities.
Complementary Internal Process

 Rules are an important form of expressing knowledge and control.
 Business rules enable businesspeople to express requirements
 Effective specification and management of business rules can ensure consistency in operating
practices and compliance with regulatory requirements.
 The ability to change and quickly deploy business rules can have a significant impact on enterprise
agility.
 Some rules may be incorporated in automated business processes or computer applications,
 some rules must be applied to the behavior of humans.
 to manage and implement rules in automated processes and applications
 to ensure consistent application and improve control and flexibility.
Business Rules

• Rules can also support complex decision making where all possible results are not explicitly
programmed.
• rules can be used to configure a product without explicitly defining all possible configurations
• rules might be used to load a truck with packages of different sizes and shapes.
• rules can be used to enforce a spectrum of requirements, from configuring complex products to
discovering a design defect.
Business Rules goals

In general, a rule is a statement of truth of a relationship of two or more facts.
i.e. we might say:
• “A customer must have an account number,” or,
• “A valid purchase order must have the signature of a person with appropriate authority.” or,
• “If a customer does not have an account number, then one must be assigned.”
Types of Rules

• Government regulations are effectively rules that define the bounds of legal behavior.
• Most regulations are expressed in a natural language (e.g., English
• regulations are intentionally vague to accommodate special interests or political pressures or to allow
for a range of circumstances.
• Regulations must be interpreted in the context of a particular enterprise, and the approach to
application of the regulation may reflect consideration of risks of violation such as the likelihood of
accidents, oversights, or mistakes, as well as the potential consequences to the enterprise and
individual employees.
some regulations can be very specific i.e. (Corporate Average Fuel Economy -CAFE)
regulations.
Regulations

 Some regulations are quite abstract, expressing an objective rather than a clear restriction on operations.
 The Sarbanes-Oxley Act, for example, requires accountability and control.
 Executives must ensure accurate corporate reporting.
 This requires measures such as separation of duties, disclosure of conflicts of interest, restrictions on
spending authority, and independent review of operations.
 These measures are pervasive and must be addressed in the design of enterprise processes.
 Most regulations are not published (directly by automated systems).
 The Semantics of Business Vocabulary and Rules (SBVR) specification from the Object Management Group
provides a formal way to capture and express rules in a natural language-like form.
Regulations

Enterprise rules are those expressed by management to define constraints on the operation of the
enterprise.
ER is a declarative expression of intent independent of specific business operations.
i.e an enterprise rule might express that:
“any purchase of a personal computer or laptop computer must conform to an
approved hardware and software configuration.”
Enterprise Rules - ER

• The rule does not define an action to be taken but rather a constraint on business operations.
• In compliance , there are degrees of enforcement from a level of discretion, (authorized deviation).
• Enterprise rules are a mechanism for managing the enterprise.
• management directives such as strategic initiatives, high-level business processes, organization structure,
and allocation of resources are important aspects of enterprise management, but they have only indirect
effect on how the enterprise actually operates.
• Enterprise rules define management controls that can have direct effect on daily operations as well as
longer-term activities.

• SBVR defines a standard computer-based modeling environment for enterprise rules.
• computer-based representation of rules provides a basis for automation of deployment.
• Since the model can support multiple vocabularies, the same rules and the concepts referenced in the
rules might be expressed alternatively in English, German, French, or other natural languages or
vernacular.
• models support capture of the meanings of the concepts being modeled, independent of the language
used to express them.
• Application of this rule might be manual or automated.

Using SBVR, might express the personal computer purchasing rule suggested earlier in the following form:
 It is obligatory that the equipment configuration of each personal computer is an approved
configuration.
 Obligatory, as defined by the SBVR specification, indicates that the rule is expected to be true but may
have exceptions.
The key concepts are the personal computer, the equipment configuration characteristic of the personal
computer, and the approved configuration that identifies one or more specifications.
Though this rule might be enforced by the purchasing department, it should be applied wherever the
purchase of new personal computers is being considered.

Production rules define an action or result to be produced under specified circumstances.
if-then or condition-action rules:
(i.e. “if a customer automobile order includes the exterior appearance option, then add chrome trim and
decals to the bill of materials.”)
 Production rules might be used to plan a trip or load a truck with packages of different sizes and shapes.
 production rules implement enterprise rules in a particular context;
 production rules simply reflect the application of expertise, design requirements, or operating decisions
appropriate to the particular situation.
 it would be desirable that there be traceability between an enterprise rules repository and the associated
production rule to support change management and accountability
Production rules

 Production rules are generally applied by a rules engine
 A rules engine is a software product that applies rules to a problem.
 rules reside in the runtime environment and, on request, the data representing a problem to be evaluated
is loaded into the rules engine working storage.
 A Rete network is created to link the rules to the working storage for efficient processing.
 rules engine determines whether any of the rule conditions are met.
 If the conditions of more than one rule are met, the rules engine has logic to decide which rule to “fire”
(i.e., execute).
 When a rule fires, its action is performed.
 This action likely changes the data in working storage that defines the current situation; it may also cause
some external effect.
 When the data changes, the conditions of a different subset of the rules may be met, and the rules engine
again selects a rule to fire.
 Production rules might also be used for such computations as process planning, in-process inventory
computation, design of experiments, or forecasting.
Production rules

Production Rules Engine.
This general class of rules processing is
called forward chaining because the
action of each fired rule affects the
selection of the next rule and the
subsequent chain of actions.
The generally accepted mechanism for
evaluating, selecting, and firing rules is
the Rete algorithm
Production rules

 Diagnostic rules are used to search for an answer, such as to find a diagnosis that is consistent with a
set of symptoms.
 These solutions are generally developed with logic programming.
 Prolog is the best-known language for logic programming.
 The rule-processing mechanism is also called backward chaining because it starts with a result and
searches for an explanation.
Diagnostic Rules

The following are examples of potential business application areas for diagnostic rules:
 Diagnosis of failures or malfunctions in complex products or equipment
 Diagnosis of problems and causes of variance in complex manufacturing processes
 Analysis of designs for identification of product defects
 Analysis of causes of market trends
Diagnostic Rules

 rules engines that implement production rules (forward chaining).
 rules engines include backward-chaining capabilities where an evaluation of a condition requires
examination of other conditions on which it depends.
 in the automobile configuration example, instead of adding a heavy-duty alternator when air conditioning
and power windows are ordered, the analysis might add a heavy-duty alternator if the power consumption
is high, and power consumption might then be defined in terms of multiple other alternative factors.
 These rules engine facilities may not include backtracking, so they would not be able to search for
alternative solutions.
 The use of forward and backward chaining together may make the design and maintenance of the rules
more complex.
 Logic programming is important for implementing complex searches.
 The programmer can focus attention on defining the rules and does not need to deal with the mechanics
of backward chaining and backtracking.
 logic programming does require special skills and attention to the order in which statements are executed.
Diagnostic Rules

 Event rules define changes of state that are of interest.
 There are an infinite number of events that occur in the operation of an enterprise, so it is essential that
the multitude of enterprise events be filtered down to those events that require consideration.
 Rules can be used to accomplish that filtering.
 event rules should be considered at three levels:
 at the event source,
 at a point of distribution, and
 in a resulting action.
 recipients of event might be characterized as event-condition-action (ECA) rules.
 ECA rules are most often embedded in business processes or applications because they tend to stand
alone.
Event Rules

 Qualification rules define constraints on participation of people, services, or organizations in associated
activities.
 These are of interest for process role assignments, for personnel assignments to positions in an
organization structure, and for access authorization.
Qualification Rules

 Data integrity rules are incorporated in data models and the design of databases.
 These rules may also be called business rules by developers of data models and designers of databases.
 These rules reflect constraints that exist in the real world. For example, a person cannot have a birth date
in the future, and two people cannot have the same tax ID number.
 These rules do not change, and violation of these rules would indicate that the integrity of the associated
database has been compromised.
 Consequently, in addition to being implemented in databases, these rules should be applied as data
entry constraints and for validation of data received from other sources
Data Integrity Rules

The primary implications of SOA are a result of two characteristics:
(1) similar capabilities are consolidated and
(2) users of services may come from across the enterprise as well as the extended enterprise.
 Consolidation provides better focus for the application of rules, whereas an expanded user
community increases the need for well-defined controls.
 Application of the different categories of business rules in an SOA environment is discussed in the
following subsections.
Implications of SOA

Regulations should not be applied directly to the enterprise but should be translated into enterprise
rules appropriate to the particular enterprise.
SOA makes it easier to identify the service units and processes that must be held in compliance
traceability of rule deployment should be maintained so that the effects of
the rules can be assessed and changes to rules can be quickly and consistently
implemented.
Regulations and Enterprise Rules

• production or diagnostic rules are used to solve complex problems
• production or diagnostic rules are applied by a rules engine or specialized language (e.g., Prolog).
• production or diagnostic rules provide a specialized capability that must include the expertise to
maintain the rules.
• the specialized capability should belong in a consolidated service.
Production and Diagnostic Rules

 Rules implemented with rules engines are relatively easy to locate because they are already separated
from the processes.
 Rules that define decisions within processes are not so visible.
 the consolidation of capabilities within services should help identify the processes
 certain rules should be implemented to narrow the search and reduce the number of implementations
for changes of a single rule.

• Consolidation of capabilities provide greater opportunity for the codification of complex decisions.
• rules engine is used at a point in a process where a complex problem is to be solved.
• Consolidation yield economies of scale that would justify a rules engine solution.
For example, computation of billing for specialized services might be a time-consuming manual
process performed by individual, field service units, whereas consolidation of the billing function as a
shared service might justify the development of a rules-engine solution.

 SOA facilitates the identification of sources of internal events of interest because capabilities are more
likely consolidated and processes more consistent.
 At the same time, the current approach to publication of events requires that each event be explicitly
programmed.
 a process that is the source of an event must be designed to recognize the event of interest and publish a
notice.
 The result is that either there are many unnecessary event notices published in anticipation of interest or
there is a need to modify processes every time a new event notice is needed.
Event Rules

• Events occur when the state of the enterprise changes, just as enterprise rules apply when the state of the
enterprise changes.
• If there is a service responsible for master data management, then, like enterprise rules, event rules could
be evaluated when the master data are updated.
• This would allow a generalized capability to implement event triggers when there is at least one
subscriber and remove the triggers when there are no subscribers.
• The result would be a high degree of flexibility in the detection of relevant events, with no unnecessary
overhead for either evaluation of rules or creation of network traffic for events of no interest.
• rules that detect violations or errors, detection of the condition in a master data update may occur after
the fact and result in more difficult corrective action.
Event Rules

SOA involves three different applications of qualification rules:
1. People qualifications
2. service policies
3. access control rules.
Qualification Rules

• In business processes that engage people to perform tasks, there are rules in the form of attribute
requirements and constraints that determine who is qualified to fill a role.
• the qualifications are applied to a local group of people that are members of the department
responsible for the process.
• The rules may focus on the experience, training, or job functions of the people involved.
• The rules focus on the process context and subject matter, such as where there is value in having the
same person do a sequence of related tasks, or the same person cannot be assigned to multiple tasks
where there is a requirement for separation of duties.
• The form of expression depends on the BPMS product.
People Qualifications

• In SOA, people who are candidates for a process role may come from various parts of the
organization, as opposed to traditional processes, where they are within the same department.
• As a result there is a need for a consistent representation of people qualifications so that
qualification rules can be applied consistently, regardless of where the person is in the organization.
People Qualifications

• there is a need to determine which of the alternative services qualify.
• there could be requirements and capabilities expressed by both the requester and the provider.
• Each potential participant must determine whether the other potential participant qualifies to fill its
role.
Service Policies

• WS-Policy from OASIS is a standard language for expression of these requirements and capabilities policies.
• Policy expressions might specify an encryption algorithm to be used or the time allowed for a response.
• A service may specify alternative policies from which perspective service users may choose.
• Both service users and service providers may have policies regarding acceptable participants and exchanges.
• To collaborate, the participants must have a combination of policy alternatives that are complementary.
• The service users and service providers also must have a common vocabulary for expression of policies
Service Policies

• SOA increases the population and diversity of persons or processes accessing each service.
• role-based access control (RBAC) is required to enable managers to control access and grant authority,
without the need to get into extensive technical detail.
• Each employee may require authorization to access many operations and data in many systems to meet
their responsibilities.
• With RBAC, rules specify the access authority of roles.
• These rules are specified by the manager responsible for protecting the operations and data, and he or
she is able to focus on controlling what can be accessed if a user has been assigned to a particular role.
• The manager of an employee can then assign certain roles to an employee and the employee then has
the authority granted to these roles.
Access Control Rules

• SOA does not affect the implementation of database integrity rules except that each service should
apply the same rules to data received from other services, just as it would apply them to data entered
by a human.
• A service should be designed to be used in a variety of contexts and cannot assume that all data inputs
are reliable.
• a service may use other services that could be independently upgraded or replaced in the future,
resulting in incompatibility.
Data Integrity Rules

• There is a need to manage some rules at an enterprise level.
• Production rules, diagnostic rules, and qualification rules are generally applicable to specific activities
and can be managed at that level.
• enterprise rules, event rules, and data integrity rules may be applicable in different activities
throughout the enterprise.
• A rules repository provides a central source in which the relationships between rules can be analyzed,
the rules can be found to be incorporated in appropriate activities, and links can be maintained to
identify where the rules are being applied.
Rules Management

• Rules are of interest to a developer when the rule condition depends on an entity, relationships, or
attributes that can be changed by the process or application under development.
• process and application developers can retrieve relevant rules from the repository on that basis.
• The developer should then identify the process activity or the application component where the rule
is applied.
Rules Management

Service-oriented architecture (SOA) is a method of software development that uses software components called services to create business applications.

More Related Content

Similar to Service-oriented architecture (SOA) is a method of software development that uses software components called services to create business applications. (20)

More from ssuser0d0f881 (20)

Recently uploaded (20)

Service-oriented architecture (SOA) is a method of software development that uses software components called services to create business applications.