Stratergies(4th Unit)

7/30/2019 Stratergies(4th Unit)

1/57

CT30A8901

Chapter 10

SOA Delivery Strategies Prof. Jari Porras

Communications Software Laboratory


2/57

Contents

10.1 SOA Delivery lifecycle phases10.2 The top-down strategy10.3 The bottom-up strategy

10.4 The agile strategy


3/57

SOA Delivery Lifecycle Phases

The lifecycle of an SOA project is the total time ittakes for each step to be completed for an SOAsolution to be implemented

This includes everything from:

Proposal Hardware/Software development Implementation Operation


4/57

Basic phases of the SOA delivery lifecycle

Development projects that are service-oriented arevery similar to other custom development projectsfor distributed applications.

Web services are designed, developed, anddeployed along with standard components and theusual support of front- and back-end technologies


5/57

Copyright PearsonEducation, Inc.

Figure 10.1: Common phases of an SOA delivery lifecycle.


6/57

Common phases of SOA delivery lifecycle

The first two phases are pre-fixed withservice-oriented and not service becausethese phases require unique analysis and

design processes that are distinctly service-oriented Service phases are primarily concerned with

the delivery of services that implement

results of service-oriented analysis anddesign efforts.


7/57

Service-oriented Analysis

Initial stage used to determine the potential scope of SOA

Service layers are planned and individual servicesare modeled as service candidates that comprise aninitial SOA


8/57

Service-oriented Design

After a goal of the new SOA is designated Service layers are mapped out Service-oriented design is a heavily standards-

driven phase Incorporates industry conventions and service-

oriented principles into the service design process


9/57

Service Development

Actual construction phase Platform-specific issues come into play, regardless

of the service type Choice of programming language and development

environment will determine the physical for servicesand organized business processes, according todesign


10/57

Service Testing

Given the generic nature and potential to be reusedand composed in unforeseeable situations

Services are required to undergo rigorous testingprior to deployment into a production environment


11/57

Sampling of key issues facing service testers

What types of service requestors could potentiallyaccess a service?

Can all service policy assertions be successfullymet?

How easily can services be composed? How easily can the service descriptions be

discovered? What data typing-related issues might arise?


12/57

Service Deployment

The implementation stage involves installing andconfiguring distributed components, serviceinterfaces, and any associated middleware productson production servers.


13/57

Issues that arise during deployment phase

How will services be distributed? What security settings and accounts are required? How should services used by multiple solutions be

positioned and deployed? Is the infrastructure adequate to fulfill the processing

requirements of all services?


14/57

Service Administration

After services are deployed, applicationmanagement issues come to the forefront.

These are similar in nature to the administrationconcerns for distributed , component-based

applications, They also might apply to services as a whole(asopposed to services belonging to a specificapplication environment)


15/57

SOA Delivery Strategies

In order to function properly the differentstages must be organized into a process thatdo the following: Accommodate preferences with regards to which

types of service layers we want to deliver Coordinate the delivery of application, business

and process services Support a transition toward a standardized SOA

while helping fulfill immediate, project-specificrequirements


16/57


Success of SOA within an enterprise isgenerally dependent on the extent to which itis standardized when it is phased into

business and application domains The success of a project delivering aservice-oriented solution generally is ameasured by the extent to which the solution

fulfills expected requirements within a givenbudget and timeline


17/57


To address this issue a strategy must be devised. The strategy must be based on an organizations

priorities to establish the correct balance betweenthe delivery of long-term migration goals with thefulfillment of short-term requirements


18/57


Three common strategies have emerged, eachaddressing this problem in a different manner Top-down Bottom-up Agile (or meet-in-the-middle)

These paths differ in priorities and practicalconsiderations.


19/57

The Top-Down Strategy

This strategy is very much an analysis firstapproach that requires not only business process tobecome service-oriented, but also promotes thecreation (or realignment) of an organizations overallbusiness model

This process is therefore closely tied to or derivedfrom an organizations existing business logic. Top-down strategy supports the creation of all three

of the service layers It is common for this approach to result in the creation

of numerous reusable business application services


20/57

Common top-down strategy process steps


21/57

Step 1: Define enterprise business models

The format of enterprise business modelstends to vary across different organizations,each of which will have models that areunique to its business domains

Common types of enterprise business modeldocuments include a formal ontology, anenterprise entity model, an enterprise-widelogical data model, a standardized data

representation architecture, and other formsof models generally associated withenterprise information architecture


22/57


Some of these models provide business-centricperspectives of an organization that prove extremelyvaluable sources for deriving business services.Business entity models especially tie directly into the

subsequent definition of entity-centric businessservices


23/57


Although listed as a single step in a high-level process, the requirements to properlydefine enterprise business models can easily

result in the need for one or more separateprocesses, each of which may require itsown project and working group.

On the other hand, if the required enterprise

business models already exist, then this stepmay simply consist of their identification


24/57

Step 2: Compose SOA

When a top-down strategy is employed, this step isoften considered part of the up-front analysis effortrequired prior to the deliver of services, and istherefore not associated with the service-oriented

design phase


25/57

Step 3: Define Enterprise Service Model

This step represents the creation of a specific typeof enterprise business model known as theenterprise service model

This specification provides a formal documentationof a planned service inventory where numerous(sometimes all) service candidates are definedahead of time, prior to entering deliver stages


26/57

Step 3: Define Enterprise Service Model

The enterprise service model implements theservice layers chosen in Step 3 and therebyestablishes a standardized, layered view of anenterprise-wide service portfolio.

Notice in the top-down strategy diagram, there is anoptional iterative relationship between this step andthe service-oriented analysis process. Arecommended strategy for creating an enterpriseservice model is to cycle through the service-oriented analysis process once for every known

business process, thereby defining and constantlyrefining service candidates (especially agnosticcandidates) prior to actual design and development


27/57

Step 4: Perform Service-Oriented Analysis

A service-oriented analysis phase is completed**

**Service-oriented analysis will be fully discussed inChapters 11 & 12


28/57

Step 5: Perform service-oriented design

The service layers are formally defined as part of aservice-oriented design process**

**Service-oriented design will be fully discussed inChapters 13 & 16


29/57

Step 6: Develop the Required Services

Services are developed according to their respectivedesign specifications and the service descriptionscreated is Step 4


30/57

Step 7: Test the Services and All Service Operations

The testing stage requires that all service operationsundergo necessary quality assurance checks. Thistypically exceeds the amount of testing required for the automation logic being implemented because

reusable services will likely need to be subjected totesting beyond the immediate scope of the solution


31/57

Step 8: Deploy the Services

The solution is finally deployed intoproduction An implementation considerationbeyond those we originally identified as part

of this step is the future reuse potential of theservice. To facilitate multiple service requestors,

highly reusable services may require extraprocessing power and may have specialsecurity and accessibility requirements thatwill need to be accommodated.


32/57

Top-Down Pros and Cons: Pros

Top-down approach to building SOA generallyresults in a high quality service architecture. Thedesign and parameters around each service arethoroughly analyzed, maximizing reusabilitypotential and opportunities for streamlinedcompositions.

All of this lays the groundwork for a standardizedand federated enterprise where services maintain astate of adaptability, while continuing to unifyexisting heterogeneity.


33/57

Top-Down Pros and Cons: Cons

The obstacles to following a top-downapproach usually are associated with timeand money.

Organizations are required to investsignificantly in up-front analysis projects thatcan take a great deal of time (proportional tothe size of the organization and theimmediate solution), without showing anyimmediate results.


34/57


Figure 10.3: Common bottom-up strategy process steps.


35/57

Bottom-Up Strategy Process

A typical bottom-up approach follows a processsimilar to the one explained in the previous diagram

This process assumes that the businessrequirements have already been collected and

defined.


36/57

Step 1: Model Application Services

This step results in the definition of application requirements that can be fulfilledthrough the use of Web services.

Typical requirements include the need toestablish point-to-point integration channelsbetween legacy systems or B2B solutions.

Other common requirements emerge out of the desire to replace traditional remote

communication technology with the SOAPmessaging communications framework.


37/57

Step 1: Model Application Services

For solutions that employ the bottom-up strategy todeliver highly service-centric solutions, applicationsservices also will be modeled to include specificbusiness logic and rules

In this case, it is likely that two application servicelayers will emerge, consisting of hybrid and utilityservices.

Those services classified as reusable may act asgeneric application endpoints for integrationpurposes, or they may be composed by parenthybrid services


38/57

Step 2: Design the Required Application Services

Some of the application services modeled in Step 1may be delivered by purchasing or leasing third-party wrapper services or perhaps through thecreation of auto-generated proxy services

These services may provide little opportunity for additional design. Custom application services, though, will need to

undergo a design process wherein existing designstandards are applied to ensure a level of consistency


39/57

Step 3: Develop the Required Application Services

Application services are developed according totheir respective service descriptions and applicabledesign specifications


40/57

Step 4: Test the Services

Services, their associated solution environment, andunderlying legacy logic are tested to ensure thatprocessing requirements can be met

Performances and stress testing measures often areused to set the processing parameters of legacysystems exposed via wrapper services

Security testing is also an important part of thisstage


41/57

Step 5: Deploy the Services

The solution and its application services aredeployed into production

Implementation considerations for applicationsservices frequently include performance andsecurity requirements


42/57

Bottom-Up Pros and Cons: Pros

The majority of organizations that currentlyare building Web services apply the bottom-up approach

The primary reason behind this is thatorganizations simply add Web services totheir existing application environments toleverage the Web services technology set

The architecture within which Web services

are added remains unchanged, and service-orientation principles are therefore rarelyconsidered


43/57

Bottom-Up Pros and Cons: Cons

As a result, the term that is used to refer tothis approach the bottom-up strategy issomewhat of a misnomer

The bottom-up strategy is really not astrategy at all

Nor is it a valid approach to achievingcontemporary SOA

This is a realization that will hit manyorganizations as they begin to take service-orientation, as an architectural model, moreseriously


44/57

Bottom-Up Pros and Cons: Cons

Although the bottom-up design allows for theefficient creation of Web services as required byapplications, implementing a proper SOA at a later point can result in a great deal of retro-fitting or eventhe introduction of new standardized service layerspositioned over the top of the non-standardizedservices produced by this approach


45/57



46/57

The Agile Strategy Process

The process steps shown in the previous figure, demonstratean example of how an agile strategy can be used to reach therespective goals of the top-down and bottom-up approaches

The challenge remains to find an acceptable balance betweenincorporating service oriented design principles into business

analysis environments without having to wait before integratingWeb services technologies into technical environment

For many organizations this is therefore useful to view thesetwo approaches as extremes and to find a suitable middleground


47/57

The Agile Strategy

This is possible by defining a new processthat allows for the business-level analysis tooccur concurrently with service design anddevelopment

Also known as the meet-in-the-middleapproach, the agile strategy is morecomplex than the previous two simplybecause it needs to fulfill two opposing setsof requirements


48/57

Step 1: Perform a Top-Down analysis

This step essentially encompasses Steps1,2, and 3 from the top-down strategydescribed earlier, except that areas of theenterprise for which service delivery is apriority are given immediate attention

After Step 2 has started, Step 1 continues asan on-going effort to further achieve theenterprise-wide analysis goals generallyassociated with the top-down approach


49/57

Step 2: When the top-down analysis has sufficientlyprogressed, perform service-oriented analysis

While Step 1 is still in progress, this step initiates aservice-oriented analysis phase

Depending on the magnitude of analysis required tocomplete Step 1, it is advisable to give that step a

head start. The further along it progresses, the more service

designs will benefit


50/57

Step 2: When the top-down analysis has sufficientlyprogressed, perform service-oriented analysis

After the top-down analysis has sufficientlyprogressed, model business services to bestrepresent 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-downanalysis is sufficiently mature to proceed withthe creation of business service models

This consideration must then be weighedagainst the importance and urgency of pendingproject requirements


51/57

Step 3: Perform service-oriented design

The chosen service layers are defined and individualservices are designed as part of a service-orienteddesign process

The extent to which the Compose SOA part of this

process is required depends on the extent to whichit was already addressed in Step 1


52/57

Step 4,5, and 6: Develop,Test, and Deploy TheServices

Develop the services and submit them to thestandard testing and deployment procedures


53/57

Step 7: As the Top-Down analysis continues toprogress, revisit business services

Perform periodic reviews of all businessservices to compare their design against thecurrent state of the business models

Make a note of discrepancies and schedule aredesign for those services most out of alignment

This Typically will require an extension to anexisting service for it to better provide the fullrange of required capabilities

When redesigned, a service will need toagain undergo standard development, testing,and deployment steps


54/57

Step 7: As the Top-Down analysis continues toprogress, revisit business services

To preserve the integrity of services produced by thisapproach, the concept of immutable servicecontracts needs to 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 contact(i.e.theaddition of new operations to a WSDL definition),Step 7 of this process likely will result in the need topublish new contract versions and the requirement for a version management system


55/57

The Agile Strategy Pros and Cons: Pros

This strategy takes the best of both worlds andcombines it into an approach for realizing SOA thatmeets immediate requirements without jeopardizingthe integrity of an organizations business model and

the service-oriented qualities of architecture.


56/57

The Agile Strategy Pros and Cons: Cons

While it fulfills both short and long-termneeds, the net result of employing thisstrategy is increased effort associated withthe delivery of every service

The fact that services may need to berevisited, redesigned, redeveloped, andredeployed will add up proportionally to theamount of services subjected to this re-tasking step


57/57

The Agile Strategy Pros and Cons: Side note

This approach imposes maintenance tasks that arerequired to ensure that existing services are actuallykept in alignment with revised business models

Even with a maintenance process in place, services

still run the risk of misalignment with a constantlychanging business model.

Stratergies(4th Unit)

Documents

Transcript of Stratergies(4th Unit)