-
1. (a) Identify and describe the Problems solved by layering
services and
draw the three primary service layers. Service - Orientation and
Contemporary SOA:
Contemporary SOA is a complex and sophisticated architectural
platform that offers
significant potential to solve many historic and current IT
problems. In part, it achieves this
potential by leveraging existing paradigms and technologies that
support its overall vision.
However, the majority of what it has to offer only can be
harnessed thorough analysis and
targeted design. The primary external influences that shape and
affect contemporary SOA are
first- and second-generation Web services specifications and the
principles of service-
orientation.
Many of the characteristics that define contemporary SOA are, in
fact, provided by these external influences.
Those characteristics not directly supplied by these influences
must be realized through dedicated modeling and design effort.
These unique characteristics represent some of SOA's most
important features and its broadest benefit potential.
The service interface layer is located between the business
process and application layers. This is where service connectivity
resides and is therefore the area of our
enterprise wherein the characteristics of SOA are most
prevalent.
To implement the characteristics we just identified in an
effective manner, some larger issues need to be addressed.
It consists of Problems solved by layering services
Specifically, we need to 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?
Through abstraction implemented via distinct service layers, key
contemporary SOA characteristics can be realized most notably
increased organizational agility.
The three common layers of SOA are the application service
layer, the business service layer, and the orchestration service
layer.
a. Problems solved by layering services: it consists of
What logic should be represented by services: o Enterprise logic
can be divided into two primary domains: business logic and
application logic.
How should services relate to existing application logic: o Much
of this depends on whether existing legacy application logic needs
to be
exposed via services or whether new logic is being developed in
support of
services.
iii. How can services best represent business logic: o Business
logic is defined within an organization's business models and
business processes.
How can services be built and positioned to promote agility: o
The key to building an agile SOA is in minimizing the dependencies
each
service has within its own processing logic.
-
Abstraction is the key: Though we addressed each of the
preceding questions
individually, the one common element to all of the answers also
happens to be the last of
our four outstanding SOA characteristics: layers of
abstraction.
The three layers of abstraction we identified for SOA are: 1.
The application service layer 2. The business service layer 3. The
orchestration service layer
Fig: The three primary service layers.
1 (b) Discuss application service layer with diagram The
application service layer establishes the ground level foundation
that exists to
express technology-specific functionality.
Services that reside within this layer can be referred to simply
as application services. The purpose is to provide reusable
functions related to processing data within new or
legacy application environments.
The application service layer consists of application services
that represent technology-specific logic.
Typical incarnations of application services are the utility and
wrapper models. 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.
Sits within the Service Interface Layer, and integrates with the
Application Layer below
Solution (Meaning business process) agnostic, are more generic
and usually reusable across multiple biz processes
-
It Can also be used to integrate other application services It
is Mixture of custom and COTS products It Hybrids may cross the
line between business and application logic. Application services
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.
Application services Examples
Utility service Wrapper service.
An application service can also compose other, smaller-grained
application services (such as
proxy services) into a unit of coarse-grained application logic.
Aggregating application services is frequently done to accommodate
integration requirements. Application services that exist solely
to
enable integration between systems often are referred to as
application integration services or simply
integration services. Integration services often are implemented
as controllers.
Fig: The application service layer.
-
2. Discuss the agile strategy with the help of process
diagram.
The agile strategy
The challenge remains to find an acceptable balance between
incorporating service-
oriented design principles into business analysis environments
without having to wait before
integrating Web services technologies into technical
environments. For many organizations it
is therefore useful to view these two approaches as extremes and
to find a suitable middle
ground.
This is possible by defining a new process that allows for the
business-level analysis
to occur concurrently with service design and development. Also
known as the meet-in-the-
middle approach, the agile strategy is more complex than the
previous two simply because it
needs to fulfill two opposing sets of requirements.
Process
The process steps shown in below figure demonstrate an example
of how an agile
strategy can be used to reach the respective goals of the
top-down and bottom-up approaches.
Figure: A sample agile strategy process
-
Step 1: Begin the top-down analysis, focusing first on key parts
of the ontology and
related business entities
The standard top-down analysis begins but with a narrower focus.
The parts of the business
models directly related to the business logic being automated
receive immediate priority.
Step 2: When the top-down analysis has sufficiently progressed,
perform service-
oriented analysis
While Step 1 is still in progress, this step initiates a
service-oriented analysis phase.
Depending on the magnitude of analysis required to complete Step
1, it is advisable to give
that step a good head start. The further along it progresses,
the more service designs will
benefit.
After the top-down analysis has sufficiently progressed, model
business services to best
represent the business model with whatever analysis results are
available. This is a key
decision point in this process. It may require an educated
judgment call to determine whether
the on-going top-down analysis is sufficiently mature to proceed
with the creation of business
service models. This consideration must then be weighed against
the importance and urgency
of pending project requirements.
Step 3: Perform service-oriented design
The chosen service layers are defined, and individual services
are designed as part of a
service-oriented design process.
Steps 4, 5, and 6: Develop, test, and deploy the services
Develop the services and submit them to the standard testing and
deployment procedures.
Step 7: As the top-down analysis continues to progress, revisit
business services
Perform periodic reviews of all business services to compare
their design against the current
state of the business models. Make a note of discrepancies and
schedule a redesign for those
services most out of alignment. This typically will require an
extension to an existing service
for it to better provide the full range of required
capabilities. When redesigned, a service will
need to again undergo standard development, testing, and
deployment steps.
To preserve the integrity of services produced by this approach,
the concept of immutable
service contracts needs to be strictly enforced. After a
contract is published, it cannot be
altered. Unless revisions to services result in extensions that
impose no restrictions on an
existing contract (such as the addition of new operations to a
WSDL definition), Step 7 of
this process likely will result in the need to publish new
contract versions and the requirement
for a version management system.
Pros and cons
This strategy takes the best of both worlds and combines it into
an approach for realizing
SOA that meets immediate requirements without jeopardizing the
integrity of an
organization's business model and the service-oriented qualities
of the architecture.
-
While it fulfills both short and long-term needs, the net result
of employing this strategy is
increased effort associated with the delivery of every service.
The fact that services may need
to be revisited, redesigned, redeveloped, and redeployed will
add up proportionally to the
amount of services subjected to this retasking step.
Additionally, this approach imposes maintenance tasks that are
required to ensure that
existing services are actually kept in alignment with revised
business models. Even with a
maintenance process in place, services still run the risk of
misalignment with a constantly
changing business model.
3. What are the objectives of service oriented analysis? Give
process model
for service oriented analysis
Answer: Service-Oriented Analysis:
Service-oriented analysis establishes a formal analysis process
completed jointly by
business analysts and technology architects. The
service-oriented analysis phase of an SOA
delivery project requires that critical decisions be made that
affect the shape and form of
individual services as well as the overall service layers.
Service modeling is the process of identifying candidate service
operations and grouping them in candidate services.
The process of determining how business automation requirements
can be represented through service-orientation is the domain of the
service-oriented analysis.
It consists of a. Objectives of service-oriented analysis
b. The service-oriented analysis process
a. Objectives of service-oriented analysis: The objectives of
SOA are Define a preliminary set of service operation candidates.
Group service operation candidates into logical contexts. Define
preliminary service boundaries so that they do not overlap with
any
existing or planned services.
Identify encapsulated logic with reuse potential. Ensure that
the context of encapsulated logic is appropriate for its
intended
use.
Define any known preliminary composition models. b. The
service-oriented analysis process:
Every organization has developed its own approach to analyzing
business
automation problems and solutions, and years of effort and
documentation will have
already been invested into well-established processes and
modeling deliverables.
Other questions that should be answered prior to proceeding with
the service-oriented analysis include:
1. What outstanding work is needed to establish the required
business model(s) and ontology?
2. What modeling tools will be used to carry out the analysis?
3. Will the analysis be part of an SOA transition plan?
-
Fig: A high-level service-oriented analysis process.
Step 1: Define business automation requirements
Through whatever means business requirements are normally
collected, their
documentation is required for this analysis process to begin.
Given that the scope of our
analysis centers around the creation of services in support of a
service-oriented solution, only
requirements related to the scope of that solution should be
considered.
Business requirements should be sufficiently mature so that a
high-level automation
process can be defined. This business process documentation will
be used as the starting
point of the service modeling process described in Step 3.
Step 2: Identify existing automation systems
Existing application logic that is already, to whatever extent,
automating any of the
requirements identified in Step 1 needs to be identified. While
a service-oriented analysis will
not determine how exactly Web services will encapsulate or
replace legacy application logic,
it does assist us in scoping the potential systems affected.
The details of how Web services relate to existing systems are
ironed out in the
service-oriented design phase. For now, this information will be
used to help identify
application service candidates during the service modeling
process described in Step 3.
Note that this step is more geared to supporting the modeling
efforts of larger scaled
service-oriented solutions. An understanding of affected legacy
environments is still useful
when modeling a smaller amount of services, but a large amount
of research effort would not
be required in this case.
-
Step 3: Model candidate services
A service-oriented analysis introduces the concept of service
modelinga process by
which service operation candidates are identified and then
grouped into a logical context.
These groups eventually take shape as service candidates that
are then further assembled into
a tentative composite model representing the combined logic of
the planned service-oriented
application.
4. Explain the process of model candidate services with
necessary diagram.
Answer: Service-Oriented Analysis using Service Modeling:
Service-Oriented Analysis providing a
detailed service modeling process that steps us through the
individual tasks required to
produce service and operation candidates.
A service modeling process is essentially an exercise in
organizing the information we
gathered in Steps 1 and 2 of the parent service-oriented
analysis process.
Modeling services is fundamentally a process of gathering and
organizing business model information.
Business process logic can be decomposed into a series of
granular steps that represent candidate service operations.
Candidate service operations are grouped into logical contexts
that represent candidate services.
It consists of
a)"Services" versus "Service Candidates
b) Process description
a)"Services" versus "Service Candidates: The important modeling
term is candidate, the
primary goal of the service-oriented analysis stage is to figure
out what it is we need to later
design and build in subsequent project phases.
b) Process description: Process description consists of 12 steps
that comprise a proposed
service modeling process. Consider a Case Study: The scope of
RailCo's service-oriented
analysis.
Step 1: Decompose the business process
The scope of RailCo's service-oriented analysis includes both of
the business processes we
described in the Business Process Management (BPM) models. Let's
begin by decomposing
the Invoice Submission Process into a series of granular
steps:
Create electronic invoice.
Issue electronic invoice.
Export electronic invoice to network folder.
Poll network folder.
Retrieve electronic invoice.
Transform electronic invoice to XML document.
Check validity of invoice document. If invalid, end process.
Check if it is time to verify TLS metadata.
If required, perform metadata check. If metadata check fails,
end process.
-
Step 1: Decompose the business process
Figure : The RailCo Order Fulfillment Process
-
10
Step 2: Identify business service operation candidates
After reviewing each of the previously identified processing
steps, we remove those
that we either cannot or do not want to make part of our
service-oriented solution. Here,
again, are the steps of our two processes. Those that are no
longer part of our solution
environment have been crossed out. Each step is further
supplemented with a brief note that
explains either why we have decided to remove it from our list
or what we have planned for
it.Invoice Submission Process:
Retrieve electronic invoice. (Same as previous.)
Transform electronic invoice to XML document. (Same as
previous.)
Check validity of invoice document. If invalid, end process. (Is
currently being
performed as part of the Invoice Submission Service's parsing
routine. No foreseeable
need to change this.)
Check if it is time to verify TLS metadata. (Is currently being
performed as part of the
Invoice Submission Service's parsing routine. Looks like a
potentially reusable
operation candidate. Could be moved to a separate service
candidate.)
If required, perform metadata check. If metadata check fails,
end process. (Same as
previous.)
And here are the process steps of the decomposed Order
Fulfillment Process:
Receive PO document. (Is currently being performed by the Order
Fulfillment
Service. No foreseeable need to change this.)
Validate PO document. (Same as previous.)
If PO document is invalid, send rejection notification and end
process. (Same as
previous.)
Transform PO XML document into native electronic PO format.
(Currently
performed by a custom developed component. Could be made part of
a service
candidate.)
Import electronic PO into accounting system. (Currently a custom
developed
extension of the legacy system. Could be made part of a generic
service candidate.)
Send PO to accounting clerk's work queue. (Same as
previous.)
The result of this review is that only two processing steps were
removed from the Invoice
Submission Process and none from the Order Fulfillment
Process.
Step 3: Abstract orchestration logic
As stated previously, RailCo has decided not to invest in
building a separate orchestration
service layer. However, we still can speculate as to what parts
of the process step logic would
normally be abstracted if this layer were to exist.
Based on our two process descriptions, the workflow logic
represented by a separate process
service candidate would include (but not be limited to) the
following:
If the invoice document is valid, proceed with the metadata
check step.
If the invoice document is invalid, end process.
If the interval period for performing a metadata check has
completed, proceed to the
perform metadata check step.
-
11
If the interval period has not completed, skip the perform
metadata check step.
If the PO document is valid, proceed with the transform PO
document step.
If the PO document is invalid, end process.
Step 4: Create business service candidates
Figure: Our first round of service candidates.
Going through the RailCo step listed from both processes, above
figure says how they
could be grouped. As also shown in above Figure operation
candidates are grouped according
to contexts that represent service candidates.
Step 5: Refine and apply principles of service-orientation
In reviewing the operation candidates within service candidates,
we make a series of
adjustments, as shown in below figure. In this step we performed
some major revisions to
original business process logic. The result is the creation of
additional service candidates that
succeed in abstracting logic in support of key
service-orientation principles
-
12
Figure The revised set of RailCo service candidates
Step 6: Identify candidate service compositions
Figure A sample composition representing the Invoice Submission
Process.
-
13
Figure: A sample composition representing the Order Fulfillment
Process
In Step 4 we identified a series of service candidates that form
preliminary business
and application service layers.Each of these service candidates
represents generic, reusable,
and business-agnostic logic. In other words, these can all be
classified as application service
candidates. Collectively they establish a preliminary
application service layer.
But what about our business service candidates? Well, the PO
Processing Service
candidate still had one action associated with it, but our
Invoice Processing Service operation
candidates disappeared after we abstracted all of the associated
process actions into separate
application service candidates.
The fact that we've reduced the processing requirements of these
two service
candidates does not mean that we don't have a need for them.
Remember that the primary role
of task-centric business services is to act as controllers,
composing application services to
carry out the required business logic. Both the PO Processing
and Invoice Processing Service
candidates establish a preliminary parent business service layer
and contain all of the process
logic required to compose the underlying application service
candidates
Step 7 & 8: Revise business service operation grouping and
Analyze application
processing requirements
Our business process is by no means complex, and we already have
identified all of
the application service candidates that represent our
preliminary application logic. Therefore,
the remaining steps are not required for our RailCo case
study.
Step 9: Identify application service operation candidates,
Step 10: Create application service candidates, Step 11: Revise
candidate service
compositions, Step 12: Revise application service operation
grouping
Our heavily revised and now "service-oriented" business process
has resulted in the
creation of two distinct preliminary service layers, each with
its own set of well defined
service candidates. Our service-oriented analysis has provided
us with extremely useful
results that we carry over to the upcoming service-oriented
design process.
The modeling exercise has tentatively addressed the goals RailCo
originally set for its
SOA. RailCo wanted to create an environment consisting of
services with processing logic
that is no longer specific to one customer. This would allow
RailCo to pursue new clients
without having to develop new services for each one.
The extent to which application logic has been abstracted
resulted in a purely reusable
application services layer. These planned application services
can facilitate a variety of
requests from business services, including the processing of
invoice and purchase order
documents from other customers. However, because they are
business-agnostic, they can be
reused by additional types of business services as well.
RailCo has therefore taken the first step to producing an
inventory of reusable
services that can be leveraged by a variety of future solutions.
This is demonstrated by the
-
14
fact that we began with separate processes that shared no common
logic and ended up with a
set of abstracted service operation candidates that can be
shared by these and other processes.
5. Give a sample of service modeling process. How guidelines
will help
service modeling?
Answer:
Service modeling (a step-by-step process)
A service modeling process is essentially an exercise in
organizing the information we
gathered in Steps 1 and 2 of the parent service-oriented
analysis process. The process
described in this section is best considered a starting point
from which we can design our own
to fit within your organization's existing business analysis
platforms and procedures
Modeling services is fundamentally a process of gathering and
organizing business model information.
Business process logic can be decomposed into a series of
granular steps that represent candidate service operations.
Candidate service operations are grouped into logical contexts
that represent candidate services.
It consists of
a)"Services" versus "Service Candidates b) Process description
a)"Services" versus "Service Candidates: The important modeling
term is
candidate, the primary goal of the service-oriented analysis
stage is to figure out what
it is we need to later design and build in subsequent project
phases.
b) Process description: Process description consists of 12 steps
that comprise a proposed service modeling process.
-
15
Figure: A sample service modeling process.
Step 1: Decompose the business process
Take the documented business process and break it down into a
series of granular
process steps
Step 2: Identify business service operation candidates
Some steps within a business process can be easily identified as
not belonging to the
potential logic that should be encapsulated by a service
candidate. By filtering out these parts
we are left with the processing steps most relevant to our
service modeling process.
Examples include:
Manual process steps that cannot or should not be automated.
Process steps performed by existing legacy logic for which
service candidate
encapsulation is not an option.
Step 3: Abstract orchestration logic
To build an orchestration layer as part of SOA, then we should
identify the parts of
the processing logic that this layer would potentially
abstract.
Potential types of logic suitable for this layer include:
-
16
business rules
conditional logic
exception logic
sequence logic
Step 4: Create business service candidates
Review the processing steps that remain and determine one or
more logical contexts
with which these steps can be grouped. Each context represents a
service candidate. The
contexts end up with will depend on the types of business
services that has chosen to build. It
is important that not to concern with how many steps belong to
each group. The primary
purpose of this exercise is to establish the required set of
contexts.
Step 5: Refine and apply principles of service-orientation
This step gives us a chance to make adjustments and apply key
service-orientation
principles. The following four key principles as those not
intrinsically provided through the
use of Web services:
reusability
autonomy
statelessness
discoverability
Step 6: Identify candidate service compositions
Identify a set of the most common scenarios that can take place
within the boundaries
of the business process. For each scenario, follow the required
processing steps as they exist
now. This exercise accomplishes the following:
It gives you a good idea as to how appropriate the grouping of
your process steps is.
It demonstrates the potential relationship between orchestration
and business service
layers.
It identifies potential service compositions.
It highlights any missing workflow logic or processing
steps.
Step 7: Revise business service operation grouping
Based on the results of the composition exercise in Step 6,
revisit the grouping of your
business process steps and revise the organization of service
operation candidates as
necessary. It is not unusual to consolidate or create new groups
(service candidates) at this
point.
Step 8: Analyze application processing requirements
. This view could very well consist of both application and
business service
candidates, but the focus so far has been on representing
business process logic.
Specifically, what we need to determine is:
-
17
What underlying application logic needs to be executed to
process the action
described by the operation candidate.
Whether the required application logic already exists or whether
it needs to be newly
developed.
Whether the required application logic spans application
boundaries. In other words,
is more than one system required to complete this action?
Step 9: Identify application service operation candidates
Break down each application logic processing requirement into a
series of steps. Be
explicit about how you label these steps so that they reference
the function they are
performing. Ideally, you would not reference the business
process step for which this
function is being identified.
Step 10: Create application service candidates
Group these processing steps according to a predefined context.
With application service
candidates, the primary context is a logical relationship
between operation candidates. This
relationship can be based on any number of factors,
including:
Association with a specific legacy system
Association with one or more solution components
Logical grouping according to type of function
Step 11: Revise candidate service compositions
Revisit the original scenarios you identified in Step 5 and run
through them again.
Only, this time, incorporate the new application service
candidates as well. This will result in
the mapping of elaborate activities that bring to life expanded
service compositions. Be sure
to keep track of how business service candidates map to
underlying application service
candidates during this exercise.
Step 12: Revise application service operation grouping
Going through the motions of mapping the activity scenarios from
Step 11 usually
will result in changes to the grouping and definition of
application service operation
candidates. It will also likely point out any omissions in
application-level processing steps,
resulting in the addition of new service operation candidates
and perhaps even new service
candidates.
Service Modeling Guidelines:
The key part of modeling quality service candidates, Business
and application service
candidates provide different types of reuse potential.
A key requirement to effectively modeling business services is a
sound knowledge of an organization's collective business process
logic.
Service candidate boundaries need to be explicit not only at the
time a service is modeled, but also later, when additional services
emerge.
It consists of
-
18
a. Take into account potential cross-process reusability of
logic being encapsulated.
b. Consider potential intra-process reusability of logic being
encapsulated. c. Factor in process-related dependencies d. Model
for cross-application reuse e. Speculate on further decomposition
requirements f. Identify logical units of work with explicit
boundaries g. Prevent logic boundary creep h. Emulate process
services when not using orchestration i. Target a balanced model j.
Classify service modeling logic k. Allocate appropriate modeling
resources l. Create and publish business service modeling
standards.