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.