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 serviceorientation. 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 serviceoriented 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-themiddle 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 serviceoriented 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

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.
10

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

11

Figure The revised set of RailCo service candidates

Step 6: Identify candidate service compositions

Figure A sample composition representing the Invoice Submission Process.

12

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

13

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.

14

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:

15

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:

16

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

17

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.

18