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.
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.
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.
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
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.
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 #.
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.
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.
-.
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
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.
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.
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.
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 .
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.
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.
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.
&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.
/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.
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.
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 $odelin#
Ste" # $ %ecom"ose Business Process 7rea the documented !usiness process into a series of granular process steps.
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.
$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.=
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.
&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.
+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.
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.