SOA- Analysis

SOA delivery lifecycle phases

SOA delivery lifecycle phases (1)

Service oriented analysis : It is in this initial stage that we determine the potential scope of our SOA. Service layers are mapped out, and individual services are modeled as service candidates that comprise a preliminary SOA. To now what it is we want to !uild. Service oriented design : To determine how it should !e constructed. Service"oriented design is a heavily standards"driven phase that incorporates industry conventions and service"orientation principles into the service design process. This phase, therefore, confronts service designers with ey decisions that esta!lish the hard logic !oundaries encapsulated !y services. The service layers designed during this stage can include the orchestration layer, which results in a formal !usiness process definition.

SOA delivery lifecycle phases (2)

Service development : $onstruction phase. %ere development platform"specific issues come into play, regardless of service type. Specifically, the choice of programming language and development environment will determine the physical form services and orchestrated !usiness processes ta e, in accordance with their designs. &'ample SOA (latforms : .)&T, *2&& Service testing : +iven their generic nature and potential to !e reused and composed in unforeseea!le situations, services are re,uired to undergo rigorous testing prior to deployment into a production environment.

SOA delivery lifecycle phases (3)

Service deployment : Implementation stage. Installing and configuring distri!uted components, service interfaces, and any associated middleware products onto production servers. Service deployment is specific to the technology platform for which services are developed. Service administration : %ow will service usage !e monitored. /hat form of version control will !e used to manage service description documents. %ow will messages !e traced and managed. %ow will performance !ottlenec s !e detected.

Service Oriented Architecture (SOA)

Analy sis

SOA Analysis

The overall goals of performing a service"oriented analysis are as follows: 2efine a initial set of service operation candidates. +roup service operation candidates into logical conte'ts. These conte'ts represent service candidates. 2efine initial service !oundaries so that they do not overlap with any e'isting or planned services. Identify encapsulated logic with reuse potential. &nsure that the conte't of encapsulated logic is appropriate for its intended use. 2efine any nown initial composition models.

SOA Analysis
The service"oriented analysis phase of an SOA delivery pro4ect re,uires that critical decisions !e made that affect the shape and form of individual services as well as the overall service layers. Objectives of service-oriented analysis /hat services need to !e !uilt. /hat logic should !e encapsulated !y each service.

SOA Analysis

Step 1: Define business automation re uirements

7usiness re,uirements are documented. +iven that the scope of our analysis centers around the creation of services in support of a service"oriented solution, only re,uirements related to the scope of that solution should !e considered. 7usiness re,uirements should !e sufficiently mature so that a high"level automation process can !e defined. This !usiness process documentation will !e used as the starting point of the service modeling process descri!ed in Step #. 8odeling.

Step 2: !dentify e"istin# automation systems

An understanding of affected legacy environments is still useful when modeling a smaller amount of services. %elp identify application service candidates during the service modeling procedure in step #.

Step 3: $odel candidate services

A service"oriented analysis introduces the concept of service modeling a process !y which service operation candidates are identified and then grouped into a logical conte't. These groups eventually ta e shape as service candidates that are then further assem!led into a tentative composite model representing the com!ined logic of the planned service"oriented application.

%enefits of business-centric SOA

1.

7usiness services !uild agility into !usiness models. 7usiness services orchestration. prepare a process for

2.

#.

7usiness services ena!le reuse. Only !usiness services can reali:e the service" oriented enterprise.

-.

1& %usiness services build a#ility into business models

Investing in a separate !usiness service layer !uilds agility into an SOA !y a!stracting !usiness and application logic domains, allowing them to evolve independently, and adapting to each other;s changes. As !usiness"driven as SOAs are, there are often real world restrictions <infrastructure, security constraints, !udget constraints= that re,uire the technology side to push !ac . This can shift the !urden of adaptation over to the !usiness process models. This type of agility re,uirement can !e met !y the !usiness service layer, as it allows !usiness services to ad4ust to re,uirement changes originating from an organi:ation;s technical environments. In other words, applying service layer a!straction to !oth !usiness and technology ends esta!lishes the potential for an enterprise to achieve a form of two"way agility.

lo#ic domain are accommodated by the application lo#ic domain and vice versa

2& %usiness services prepare a process for orchestration

Orchestration !rings with it concepts that, when implemented, lie at the core of SOA. Therefore, modeling current processes so that they eventually can !e more easily migrated to an orchestration"driven environment is recommended.

3& %usiness services enable reuse

7usiness services promote reuse of !oth !usiness process and application logic through careful encapsulation and a!straction. The creation of a !usiness service layer promotes reuse in !oth !usiness and application services, as follows: 7y modeling !usiness logic as distinct services with e'plicit !oundaries, !usiness process"level reuse can !e achieved. Atomic su!"process logic or even entire processes can !e reused as part of other process logic or as part of a compound process <which translates into a service composition in its own right=. 7y ta ing the time to properly align !usiness models with !usiness service representation, the resulting !usiness service layer ends up freeing the entire application service layer from assuming tas or activity"specific processing functions. This allows application services to !e positioned as and to evolve into pure, reusa!le utility services that facilitate !usiness services across solution !oundaries.

can reali)e the serviceoriented enterprise

7usiness services are ey to fulfilling an enterprise"wide standardi:ation of service"orientation. Applying !usiness services forces an organi:ation to view and reinterpret !usiness nowledge in a service"oriented manner. Though the !usiness services layer may accurately represent a corporate !usiness model upon implementation, it will !ecome outdated once new and revised !usiness re,uirements emerge. As long as it is ept in relative alignment with the current state of !usiness models, it will continue to serve as a valua!le view of the enterprise !ecause it does not e'ist in a!stract !ut in an implemented and operational form.

Deriving business services

&very !usiness model is uni,ue. Therefore, up" front analysis cannot !e avoided to properly derive !usiness services that !est represent an organi:ation as a cohesive !usiness entity. Sources from which business services can be derived

The inner wor ings of any organi:ation, regardless of structure or si:e, can !e decomposed into a collection of !usiness services. This is !ecause a !usiness service simply represents a logical unit of wor , and pretty much anything any organi:ation does consists of units of wor .

Deriving business services

some e'amples of common !usiness analysis approaches used !y many organi:ations Business Process Management (BPM) models Entity models

Management (BPM) models

7usiness services can !e derived from process wor flow logic. 2eriving a !usiness service from a !usiness process re,uires a thorough nowledge of the underlying wor flow logic. This is !ecause defining the scope of the !usiness logic to !e represented is a 4udgment call that can have significant implications when the !usiness service is implemented as part of solution environments> hence, the !etter the 4udgment, the !etter the ,uality of the service.

Management (BPM) models

Entity models
(rimary entities represent the main !usiness documents and transaction areas of an enterprise. ?or e'ample, Invoice, (urchase Order, $ustomer, and $laim are all milestone entities within different types of !usinesses. Organi:ations model entities according to proprietary rules and !usiness policies. This results in entities having relationships with each other.

Entity Models
&ntity"centric services mirror the entity model !y containing a set of generic operations that facilitate the different types of functions associated to the processing of the entity. $ommunication !etween different entity" centric services also can !e governed !y constraints relating to the inherent relationship !etween entities.

Types of derived business services

as!-centric business services Entity-centric business services

Task-centric business services

These are /e! services that have !een modeled to accommodate a specific !usiness process. Operations are grouped according to their relevance to the e'ecution of a tas in support of a process. Typical e'amples of tas "centric !usiness services are: @erifyInvoice +et%istoryAeport &ach of these services contains operations that relate to a particular tas within the conte't of a process. Tas "centric services usually result from modeling e'ercises that are focused on meeting immediate !usiness re,uirements. Typical sources include use"case models and 7(8 process definitions. /hile they re,uire less analysis effort to produce, these types of !usiness services have limited reusa!ility potential. 8odeling reusa!le tas "centric !usiness services often re,uires that multiple use"cases and !usiness process models first !e analy:ed to identify commonality, prior to the actual modeling of the services.

Entity-centric business services

&ntity"centric !usiness services generally are produced as part of a long"term or on"going analysis effort to align !usiness services with e'isting corporate !usiness models. Their inherent generic nature ma es them highly reusa!le !y numerous !usiness processes. &ven though entity" centric !usiness services often are !uilt as part of application development pro4ects centered around a particular !usiness process, they differ from tas "centric services in that they do not provide an interface specific to that process. Instead, the source of inspiration for these types of services is entity models.

Entity-centric business services

/hen compared to tas "centric services, entity"centric services significantly increase the agility with which service"oriented processes can !e remodeled. This is !ecause tas "centric services often are !uilt to help automate one !usiness process and can therefore get tied to that process. /hen the process logic changes, the conte't under which the services are used and composed may change as well. This may invalidate the original grouping of service operations and could result in the re,uirement for a redesign and redevelopment effort. &ntity"centric services do re,uire more up"front analysis, increasing !oth the cost of each service and the time re,uired to produce it. Additionally, they can !e so generic in nature that they are delivered with no concept of !usiness process logic. Their use may therefore !ecome dependent on parent !usiness controllers, such as process services or tas "centric controller services.

Business services and orchestration

The process service, an implementation of orchestration, also can !e classified as a form of !usiness service. It is very much B!usiness"centric,B as it resides at the top of the service layer hierarchy and is responsi!le for composing !usiness services according to the rules specified in the orchestration wor flow logic. Orchestration a!stracts wor flow logic, positioning it outside of service !oundaries. This increases agility !y allowing changes to !usiness rules to !e made without affecting !usiness or application services. This is a critical aspect of orchestration, as !usiness process logic is su!4ect to many factors that can result in change. These include human intervention, changes to corporate policies and !usiness rules, and unforeseea!le e'ception conditions.

Business services and orchestration

The use of orchestration esta!lishes the following structure in the services layer:
/or flow logic and process"specific !usiness rules are em!edded in a process definition. Orchestration composes !usiness services <and possi!ly application services= according to this definition. 7usiness services compose application services to e'ecute !usiness logic. Application services interact with underlying systems to process the re,uired functions.

Service $odelin#

The primary goal of the service"oriented analysis stage is to figure out what it is we need to later design and !uild in su!se,uent pro4ect phases. Service candidates and Service operation candidates are the end"result of a process called service modeling. (roduce a!stract candidates that may or may not !e reali:ed as part of the eventual concrete design.

Service modelin# (a stepby-step process)

Service $odelin#
Ste" # $ %ecom"ose Business Process 7rea the documented !usiness process into a series of granular process steps.

Step 1: Decompose Business Process

&ase Study The scope of Aail$o;s service"oriented analysis includes !oth of the !usiness processes Cet;s !egin !y decomposing the Invoice Su!mission (rocess into a series of granular steps: $reate electronic invoice. Issue electronic invoice. &'port electronic invoice to networ folder. (oll networ folder. Aetrieve electronic invoice. Transform electronic invoice to D8C document. $hec validity of invoice document. If invalid, end process. $hec if it is time to verify TCS metadata. If re,uired, perform metadata chec . If metadata chec fails, end process.

Step 1: Decompose Business Process

&ase Study The scope of Aail$o;s service"oriented analysis includes !oth of the !usiness processes Cet;s !egin !y decomposing the Invoice Su!mission (rocess into a series of granular steps: $reate electronic invoice. Issue electronic invoice. &'port electronic invoice to networ folder. (oll networ folder. Aetrieve electronic invoice. Transform electronic invoice to D8C document. $hec validity of invoice document. If invalid, end process. $hec if it is time to verify TCS metadata. If re,uired, perform metadata chec . If metadata chec fails, end process.

Step 1: Decompose Business Process

&ase Study )e't are the process steps of a decomposed Order ?ulfillment (rocess Aeceive (O document. @alidate (O document. If (O document is invalid, send re4ection notification and end process. Transform (O D8C document into native electronic (O format. Import electronic (O into accounting system. Send (O to accounting cler ;s wor ,ueue.

Service $odelin#
Ste" ' $ (dentify O"eration &andidates ?iltering out some steps within a !usiness process that as not !elonging to the potential logic that should !e encapsulated !y a service candidate. &'amples include:

8anual process steps that cannot or should not !e automated. (rocess steps performed !y e'isting legacy logic for which service candidate encapsulation is not an option. 7y filtering out these parts we are left with the processing steps most relevant to our service modeling process.

tep ! " #dentify $peration %andidates

(nvoice Submission Process$

$reate electronic invoice. <A manual step performed !y the accounting cler .= Issue electronic invoice. <A manual step performed !y the accounting cler .= &'port electronic invoice to networ folder. <$urrently a custom developed e'tension of the legacy system. $ould !e made part of a generic service candidate.= (oll networ folder. <$urrently performed !y a custom developed component. $ould !e made part of a service candidate.= Aetrieve electronic invoice. <Same as previous.= Transform electronic invoice to D8C document. <Same as previous.= $hec validity of invoice document. If invalid, end process. <Is currently !eing performed as part of the Invoice Su!mission Service;s parsing routine. )o foreseea!le need to change this.= $hec if it is time to verify TCS metadata. <Is currently !eing performed as part of the Invoice Su!mission Service;s parsing routine. Coo s li e a potentially reusa!le operation candidate. $ould !e moved to a separate service candidate.= If re,uired, perform metadata chec . If metadata chec fails, end process. <Same as previous.=

tep ! " #dentify $peration %andidates

Order )ulfillment Process$ Aeceive (O document. <Is currently !eing performed !y the Order ?ulfillment Service. )o foreseea!le need to change this.= @alidate (O document. <Same as previous.= If (O document is invalid, send re4ection notification and end process. <Same as previous.= Transform (O D8C document into native electronic (O format. <$urrently performed !y a custom developed component. $ould !e made part of a service candidate.= Import electronic (O into accounting system. <$urrently a custom developed e'tension of the legacy system. $ould !e made part of a generic service candidate.= Send (O to accounting cler ;s wor ,ueue. <Same as previous.=

Service $odelin#
Ste" * $ +bstract Orchestration ,ogic Identify the parts of the processing logic that this layer would potentially a!stract. (otential types of logic suita!le for this layer include: !usiness rules, conditional logic, e'ception logic, se,uence logic.

tep & " 'bstract $rchestration (ogic

&ase Study As stated previously, Aail$o has decided not to invest in !uilding a separate orchestration service layer. %owever, we still can speculate as to what parts of the process step logic would normally !e a!stracted if this layer were to e'ist. 7ased on our two process descriptions, the wor flow logic represented !y a separate process service candidate would include <!ut not !e limited to= the following: If the invoice document is valid, proceed with the metadata chec step. If the invoice document is invalid, end process. If the interval period for performing a metadata chec has completed, proceed to the perform metadata chec step. If the interval period has not completed, s ip the perform metadata chec step. If the (O document is valid, proceed with the transform (O document step. If the (O document is invalid, end process. )ote that the orchestration wor flow logic also would include the se,uence in which the individual processing steps are e'ecuted.

Service $odelin#
Ste" - $ &reate business service candidates Aeview the processing steps and identifying logical conte'ts <service candidates= to group the steps. The conte'ts you end up with will depend on the types of !usiness services you have chosen to !uild. &'ample :

Tas "centric !usiness services : conte't specific to the process &ntity"centric !usiness services : group processing steps according to their relation to previously defined entities E facilitate future reuse.

tep ) " %reate business service candidates

+oing through the Aail$o steps we listed from !oth processes, here is how they could !e grouped:

Service $odelin#
Ste" . $ /efine and a""ly "rinci"les of service-orientation To ma e our service candidates truly worthy of an SOA, we must ta e a closer loo at the underlying logic of each proposed service operation candidate. This step gives us a chance to ma e ad4ustments and apply ey service"orientation principles. ?ocus in this step is to ensure that each service operation candidate identified is potentially reusa!le and as autonomous as possi!le.

principles of serviceorientation

In reviewing the operation candidates within our service candidates, we ma e a series of ad4ustments, as follows. /ithin the Cegacy System Service, the BSend (O to accounting cler ;s wor ,ueueB action can !e performed only upon the receipt of a document. This operation candidate is therefore directly dependent on the BImport electronic (O into accounting systemB step. /e therefore decide to com!ine these two steps into one. ?urther the B&'port electronic invoice to networ folderB action is performed automatically !y a macro added to the legacy accounting system. It is therefore not re,uired as part of our service candidate. This leaves us with a single operation candidate that we would li e to ma e more reusa!le !y allowing it to handle different types of documents. he revised ,egacy System Service list contains the following ste"s$ &'port document to networ folder. Import and forward document to wor ,ueue.

principles of serviceorientation

Fpon reviewing the Invoice (rocessing Service, a num!er of refinement opportunities arise. /e determine that the B(oll networ folder for invoiceB action can !e made more generic !y turning it into an operation candidate that simply polls a given folder for different types of documents. /e also decide that this action should !e made part of a service candidate capa!le of notifying su!scri!ers of the arrival of new documents. )e't, we decide to com!ine the BAetrieve electronic invoice,B BTransform electronic invoice to D8C document,B and B$hec validity of invoice documentB operation candidates into a single service operation candidate called BAetrieve and transform invoice document.B /e don;t mention the validation aspect of this action !ecause the D8C document automatically is assigned a corresponding schema. The validation of the document is therefore an intrinsic part of the transformation process. The result of our analysis is a new conte't <a new service candidate=, esta!lished to represent generic notification actions, as follows: Polling 0otification Service$ (oll folder for new documents. If documents arrive for which there are su!scri!ers, issue notifications. The revised Invoice (rocessing Service list is left with 4ust one step: Aetrieve and transform invoice document.

principles of serviceorientation

/e move on to discover commonality !etween the BTransform (O D8C document into native electronic (O formatB action and the BAetrieve and transform invoice documentB action from our Invoice (rocessing Service list. 7oth operation candidates transform accounting documents. /e therefore decide to create a new service candidate that provides generic transformation. The result is a new grouping category: ransform +ccounting %ocuments Service$ Transform D8C documents to native format. Transform native documents to D8C. he revised PO Processing Service list is left with just one ste"$ @alidate (O document and send re4ection notification, if re,uired. he revised Metadata &hec!ing Service list contains the following ste"s$ $hec if it is time to verify TCS metadata. If re,uired, perform metadata chec . If metadata chec fails, issue notification

principles of serviceorientation

Service $odelin#

Ste" 1$ (dentify candidate service com"ositions Identify a set of the most common scenarios that can ta e place within the !oundaries of the !usiness process. ?or each scenario, follow the re,uired processing steps as they e'ist now. This e'ercise 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 !etween orchestration and !usiness service layers. It identifies potential service compositions. It highlights any missing wor flow logic or processing steps.

candidate service compositions

+ sam"le com"osition re"resenting the (nvoice Submission Process2

candidate service compositions

+ sam"le com"osition re"resenting the Order )ulfillment Process2

Service $odelin#
Ste" 3$ /evise business service o"eration grou"ing 7ased on the results of the composition e'ercise in Step 1, revisit the grouping of your !usiness process steps and revise the organi:ation of service operation candidates as necessary. It is not unusual to consolidate or create new groups <service candidates= at this point.

Service $odelin#

Ste" 4$ +naly5e a""lication "rocessing re6uirements 7y the end of Step 1, you will have created a !usiness"centric view of your services layer. This view could very well consist of !oth application and !usiness service candidates, !ut the focus so far has !een on representing !usiness process logic. This ne't series of steps is optional and more suited for comple' !usiness processes and larger service"oriented environments. To accomplish this, each processing step identified so far is re,uired to undergo a mini"analysis. Specifically, what you need to determine is: /hat underlying application logic needs to !e e'ecuted to process the action descri!ed !y the operation candidate. /hether the re,uired application logic already e'ists or whether it needs to !e newly developed. /hether the re,uired application logic spans application !oundaries. In other words, is more than one system re,uired to complete this action. )ote that the information we gathered during Step 2 of the parent service" oriented analysis process will !e referenced at this point.

Service $odelin#

Ste" 7$ (dentify a""lication service o"eration candidates 7rea down each application logic processing re,uirement into a series of steps. 7e e'plicit a!out how you la!el these steps so that they reference the function they are performing. Ideally, you would not reference the !usiness process step for which this function is !eing identified. Ste" #8$ &reate a""lication service candidates +roup these processing steps according to a predefined conte't. /ith application service candidates, the primary conte't is a logical relationship !etween operation candidates. This relationship can !e !ased on any num!er of factors, including: association with a specific legacy system association with one or more solution components logical grouping according to type of function

Service $odelin#

Ste" ##$ /evise candidate service com"ositions Aevisit the original scenarios you identified in Step 0 and run through them again. Only, this time, incorporate the new application service candidates as well. This will result in the mapping of ela!orate activities that !ring to life e'panded service compositions. 7e sure to eep trac of how !usiness service candidates map to underlying application service candidates during this e'ercise. Ste" #'$ /evise a""lication service o"eration grou"ing +oing 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 li ely point out any omissions in application"level processing steps, resulting in the addition of new service operation candidates and perhaps even new service candidates.