WPS V6 Technical Overview V1-3-SMS

WebSphere Process Server 6.0 Technical Overview Version 1.
WebSphere Process Server Technical Introduction
Page 1 of 55
Table of Contents
1. Introduction............................................................................................................................... 3 2. Service Oriented Architecture ore............................................................................................ 5 Service o!ponent Architecture "S A#..........................................................................5 S A and $usiness Ob%ects "$Os#...................................................................................& S A $indings.................................................................................................................. ' (unti!e Infrastructure..................................................................................................... ' 3. Supporting Services................................................................................................................. 1) Transfor!ations............................................................................................................ 1) *. Service o!ponents................................................................................................................ 1+ $usiness Process ......................................................................................................... 1+ $usiness Process ,-a!ples.........................................................................................21 .u!an Tas/ 0anager .................................................................................................. 22 $usiness State 0achines..............................................................................................3) $usiness (ules.............................................................................................................. 3& 5. WebSphere Integration 1eveloper.......................................................................................... *) Standards...................................................................................................................... *) (oles............................................................................................................................. *) The Progra!!ing 0odel...............................................................................................*1 S A Ter!inolog2.......................................................................................................... *1 $uilding an Application.................................................................................................. *2 I!ple!enting o!ponents............................................................................................ *& 1ebugging3 Testing and 0onitoring...............................................................................52 Su!!ar2..................................................................................................................................... 55
Page 2 of 55
1.
Introd ction
Over the past fe4 2ears3 custo!ers3 anal2sts and partners loo/ed to I$0 to provide a co!plete process integration solution. 5i/e !an2 other co!panies in the industr23 I$0 offered separate products for traditional 4or/flo43 one for process integration using a 6ava7based progra!!ing !odel3 and another product supporting $P,5 "$usiness Process ,-ecution 5anguage#. With WebSphere for Process Integration and the WebSphere Process Server3 I$0 establishes product and thought leadership in process integration. This leadership is delivered through I$08s co!prehensive runti!e environ!ent for process integration and a develop!ent foundation allo4ing custo!ers to build SOA7based integration solutions ranging fro! si!ple application s2nchroni9ation to enterprise7level process integration solutions. WebSphere Process Server is a co!ponent based Service Oriented Architecture "SOA# integration platfor! built on a unifor! invocation progra!!ing !odel and a unifor! data representation !odel. WebSphere Process Server is a single product providing a collection of integration co!ponents built on an SOA foundation to solve the breadth of integration re:uire!ents for a 4ide variet2 of custo!ers. ;or custo!ers !odeling business processes based on hu!an activities3 WebSphere Process Server provides the .u!an Tas/ 0anager co!ponent. ;or custo!ers re:uiring full2 or partiall2 auto!ated business processes3 WebSphere Process Server8s $usiness Process and the $usiness State 0achine i!ple!entations offer an intuitive fra!e4or/ for deplo2ing these solutions. ;or custo!ers 4ho are s2nchroni9ing ob%ects bet4een e-isting applications3 WebSphere Process Server includes po4erful transfor!ation co!ponents including business ob%ect !apping and relationship !anage!ent capabilities. Additionall23 all of these co!ponents ta/e direct advantage of the advanced $usiness (ules functionalit2 supported 4ithin WebSphere Process Server. WebSphere Process Server8s integrated support for co!ponent7based SOA process solutions allo4s the abilit2 to choreograph these co!ponents to !eet the var2ing needs of all custo!ers.
Figure 1 WebSphere Process Server Runtime topology ;igure 1 sho4s the runti!e topolog2 of WebSphere Process Server. The base (unti!e Infrastructure is I$08s !ar/et leading WebSphere Application Server. The SOA ore provides the basis of the SOA7 based process solution. Service o!ponent Architecture and $usiness Ob%ects provide the unifor! invocation and data7representation progra!!ing !odel. Additionall23 the SOA ore includes the o!!on ,vent Infrastructure for generating events for the !onitoring and !anage!ent of WebSphere Process Server. Supporting Services provide the foundational business ob%ect and transfor!ation fra!e4or/ for the WebSphere Process Server. The Service o!ponents represent the functional
Page 3 of 55
co!ponents re:uired to build co!posite applications and represent the broadest range of integration co!ponents in an2 process integration solution 4hich are used to solve the full range of integration re:uire!ents... The co!bination of a po4erful foundation "WebSphere Application Server and the SOA ore# and Service o!ponents in WebSphere Process Server allo4s users to build sophisticated co!posite applications :uic/l2. The technolog2 incu!bent in the WebSphere Process Server is the result of I$08s rich heritage in process integration< WebSphere Process Server thought leadership is based on the collective custo!er and develop!ent e-perience derived fro! WebSphere $usiness Integration Server ;oundation3 WebSphere 0= Wor/flo4 and WebSphere Inter hange Server. This deep bac/ground in process integration results in the !ost co!prehensive process integration solution offered in the industr2. The rest of this paper e-plores the features of WebSphere Process Server. Section 2 discusses the Service Oriented Architecture and covers the i!portance of the Service o!ponent Architecture and $usiness Ob%ects Section 3 covers the details of the Supporting Services including Interface 0aps3 $usiness Ob%ect 0aps3 (elationship Support and the Selector ;ra!e4or/ Section * focused on the Service $usiness Processes .u!an Tas/ 0anager $usiness State 0achines $usiness (ules Section 5 discusses WebSphere Integration 1eveloper3 the pri!ar2 tool for developing WebSphere Process Server integration solutions o!ponents including>
Page * of 55
!.
Service Oriented "rchitect re Core

The Service Oriented Architecture "SOA# ore is the foundation in WebSphere Process Server "WPS#. The !ain co!ponents of the SOA runti!e are the Service o!ponent Architecture "S A#3 $usiness Ob%ects "$Os# and the o!!on ,vent Infrastructure " ,I#. S A is the unifor! progra!!ing and invocation !odel for business services that publish or operate on business data. $usiness Ob%ects "$Os# provide the unifor! progra!!ing !odel for business data. The o!!on ,vent Infrastructure " ,I# provides the foundation architecture for the !onitoring and !anage!ent of the WebSphere Process Server solution and shares this architectural co!ponent 4ith other technologies in the WebSphere process environ!ent including WebSphere Adapters and WebSphere Partner ?ate4a2.
SOA Core
Service o!ponent Architecture
$usiness Ob%ects
o!!on ,vent Infrastructure
Figure 2 SOA Core
Service Component Architecture (SCA)

One of the critical challenges facing custo!ers 4ho i!ple!ent 62,, applications is the perception that the 62,, !odel is !uch too co!ple- for developing business applications. 62,, developers toda2 !ust be a4are of a !ultitude of progra!!ing APIs and standards in order to build the !ost trivial of applications. "It should be noted that si!ilar issues are present in the 4orld of .@,T although this does not beco!e obvious until developers atte!pt distributed integration or heterogeneous access to non 0icrosoft applications.# The evolution of 62,, has3 in !an2 regards3 i!peded rapid develop!ent of integration solutions. As an e-a!ple3 62,, developers !ust understand the variet2 of 4a2s in 4hich data is represented including 61$ (o4 Sets3 60S 0essages and a range of other options. In addition to data representation co!ple-it23 62,, developers !ust deal 4ith a variet2 of invocation patterns including Session $ean develop!ent and access3 61$ access to databases3 and transactional se!antics via persistence !ethods. Additionall23 62,, progra!!ers are encapsulating co!ponents as services and using $P,5 to co!pose services into a cohesive application. In su!!ar23 these issues !andate staffing re:uire!ents for a cadre of Asuper7developersB. This co!ple-it2 in develop!ent also decreases ti!e to !ar/et for ne4 solutions and3 due to the co!ple-it2 of the develop!ent process3 can often result of code that is difficult to !aintain as re:uire!ents change. In this section3 4e describe the Server o!ponent Architecture "S A# 4hich is a progra!!ing !odel that si!plifies the process of developing co!posite business applications. The develop!ent process is si!plified b2 providing a co!!on data representation and co!!on co!ponent invocation !ethods to support !ore intuitive develop!ent. There are t4o pri!ar2 tenants that underlie S A> S A si!plifies the 62,, progra!!ing !odel and provides co!ponent abstraction S A is based on concepts present in e-isting 62,, technologies
One of the !ost i!portant aspects of the S A progra!!ing !odel is supports for a strong separation of application business logic fro! technical infrastructure code. Separation of application business logic fro! technical infrastructure code allo4s applications to be created 4ith fe4er IT specialists3 and provides for greater code portabilit2 and isolation fro! IT infrastructure change. S A e-poses business7level interfaces to application business7logic code. The data structures used as argu!ents to base S A services are !odeled in $usiness Ob%ects. The $usiness Ob%ect is a standard data7structure representation that hides the technical details of the technolog2 of the underl2ing S A i!ple!entation. I$0 provides a rich set of tools for generating base S A services and $usiness Ob%ect t2pes specific to
Page 5 of 55
the custo!er8s data and co!puting infrastructure 4ithout the need for progra!!ing. I$0 provides a rich set of tools for the 62,, progra!!ing !odel that allo4s technical IT specialists to create ne4 S A services or applications using the 62,, APIs directl2. Another i!portant characteristic of S A is that it provides a si!ple declarative !odel for e-porting services via various protocols3 including Web services. It also provides a si!ple declarative !odel for i!porting services that are i!ple!ented in other service technologies3 including Web services and ,IS services. S A provides a unifor! client progra!!ing !odel for accessing services 4hether the2 are i!ple!ented locall2 as S A co!ponents or i!ported services such as Web services and ,IS services3.
Figure 3 WebSphere Process Server Component Architecture and indings S A provides a high :ualit2 of service around these invocations. (ather than providing a lo4er7co!!on7 deno!inator solution3 S A supports s2nchronous and as2nchronous calls 4here appropriate over various protocols.
SCA and Business Objects (BOs)

Service7Oriented Architectures "SOA# provides both an architectural foundation and a designCdevelop!ent !ethodolog2 for process integration. T4o of the funda!ental characteristics of services are> Services are relatively coarse-grained processing units. Services are opti!i9ed for relativel2 infre:uent e-changes of relativel2 larger sets of data> the interface to services is defined in ter!s of relativel2 large A!essagesB3 Adocu!entsB or Aob%ect7graphsB according to 2our perspective. Services are not Aob%ectsB in the nor!al progra!!ing language sense. ;ro! an ob%ect7oriented progra!!er8s perspective3 ob%ects are passed to services and received fro! services> services are AprocessorsB that consu!e and produce sets of ob%ects. Services are loosely coupled. Services and their clients are loosel2 bound. The2 do not share assu!ptions about i!ple!entation technologies3 and both the AaddressB of a service and the technolog2 used to co!!unicate 4ith it !a2 be bound late to a client3 possibl2 even at run7ti!e. ;urther3 services !ini!i9e te!poral and organi9ational constraints during the develop!ent3 deplo2!ent and usage of the various services.
Page & of 55
0ost people associate SOA 4ith D05 and Internet co!!unications protocols3 but the basic service concept can also be directl2 applied in other environ!ents. In the WebSphere best7practices guidelines for 62,,3 I$0 and the rest of the industr2 reco!!ends an application architecture 4here stateless session $eans front7end ,ntit2 beans. These stateless Session $eans can be thought of as interface services. The entities the2 front7end are generall2 not visible to the clients E copies of the data in the entities are passed to clients3 and received fro! clients. $usiness Ob%ects "$Os# are based on the S1O "Service 1ata Ob%ect# standard 4ith e-tensions to support business integration. $Os describe the data in a unifor! !odel and leverage D05 and DS1 in their i!ple!entation. $Os carr2 additional infor!ation3 such as change histor2 and event histor23 but at the core3 the2 are D05 docu!ents described b2 an DS1. The S A and $O technologies provide a unifor! service7oriented vie4 over the top of the e-isting 62,, co!ponent !odel and APIs. This functionalit2 encourages best7practice i!ple!entations and si!plifies the progra!!er8s vie4 of the application !odules and the !iddle4are API. As a result3 the developer can focus on the business logic and data being built or used3 rather than the technolog2. The S A progra!!ing !odel abstracts the co!ple-ities of 6ava and 62,, "and other related technologies# and provides a core set of language concepts fa!iliar to people that develop business applications in other progra!!ing languages toda2. 1evelopers s4itching fro! classical application develop!ent environ!ents to the WebSphere process integration solution benefit fro! an enor!ousl2 reduced learning curve. As a result3 developers can be :uic/l2 productive 4ith this progra!!ing !odel. $esides helping the co!!unit2 of developers that s4itch fro! classical environ!ents3 this allo4s e-perienced 62,, developers to be !ore productive as 4ell
SCA Bindings
S A $indings are not directl2 e-posed to the developer3 but it is i!portant to recogni9e the technologies that can be e-posed as a S A services. In WPS3 the follo4ing co!ponents can be e-posed as S A services> Stateless ,6$ Session $eans 6ava lasses Adaptors WebSphere Process Server Service $usiness Processes .u!an Tas/s $usiness (ules $usiness State 0achines Transfor!ations
o!ponents
Runtime n!rastructure
The runti!e infrastructure is founded on the WebSphere Application Server. As such3 there are !an2 features available inherentl2 to WebSphere Process Server such as perfor!ance3 scalabilit23 high availabilit2 a!ong others. WebSphere Application Server is responsible for transaction !anage!ent3 securit2 and basic resource !anage!ent. Additionall23 there are several other I$0 products that leverage WebSphere Application Server and integrate 4ith WebSphere Process Server b2 design. WebSphere Portal provides access to the various ad!inistrative functions and allo4s portlets to have access to business processes and other S A services. The Process Portal i!ple!entation provides a WebSphere Portal solution for user interaction 4ith the .u!an Tas/ 0anager "in addition3 the .u!an Tas/ 0anager also provides a Web lient runti!e deplo2!ent option#. WebSphere eDtended 1eplo2!ent "WAS7D1# supports WebSphere Process Server in the future as 4ell. WAS7D1 brings ver2 high :ualities of service and scalabilit2 to the WPS product.
Page ' of 55
Additionall23 WPS 4ill be available on the 9COS platfor! in the near ter! to bring the highest :ualities of 9COS service to the product offering.
Common !vent "n#rastructure

o!!on ,vent Infrastructure " ,I# is a set of !odular co!ponents for larger solutions that re:uire si!ple event !anage!ent function3 such as event distribution3 event persistence3 event updates3 and event :ueries. ,I uses the event !odel defined in the I$0 Autono!ic o!!on $ase ,vent and Situation 1ata for its event !anage!ent functions. Over ti!e3 the broader adoption of this event !odel throughout I$0 products translates into stronger integration bet4een ,I and the rest of the I$0 portfolio. ,I provides a fra!e4or/ for event integration. The underl2ing event flo4 occurs 4hen a significant event happens in the IT s2ste! as sho4n belo4 in the ,vent Source. This event notification is captured b2 an event e!itter "either built into the runti!e e.g. WebSphere Process Server or a plug7in based event e!itter#. The event data is captured in an event ob%ect 4hich has a standardi9ed for!at called the o!!on $ase ,vent " $,#. All event ob%ects are passed to the event infrastructure to enable the trac/ing the progress of a business process3 support for audit trails3 oordinating 4or/ bet4een independent business processes3 and !onitoring for e-ceptions in a business process. The !onitoring function is the core of the $usiness Innovation and Opti!i9ation solution architecture as it uses ,I as the event infrastructure for WebSphere $usiness 0onitor.
Event Source Submi t Complete
Distribute Event Event Event Consumer Consumer Event Consumer Consumer Query
Store Event Data

Figure $ Common !vent "n#rastructure
;ro! an application integrator point of vie43 there are three /e2 aspects of ,I3 4hich are referenced through the rest of the docu!ent> ,I S1F. A co!bination of client libraries3 runti!e co!ponents3 and descriptive API docu!entation. 1evelopers use the ,I S1F and associated API docu!entation to initiall2 4rite their applications and3 later on3 pac/age the runti!e co!ponents 4ithin their o4n installation !odules to produce the final installation i!age of their products. ,I (unti!e. ,I co!ponents that actuall2 service the re:uests initiated at event consu!ers and event sources3 such as creation and purging of events. Applications interact 4ith the ,I runti!e through the ,I APIs.
,I Ad!inistration. Installation3 configuration3 and !anage!ent aspects associated 4ith ,I co!ponents. As part of the overall direction for WebSphere7centric products3 ,I server7side co!ponents are !odeled as a 62,, application running inside an WebSphere Application Server and client7side co!ponents rel2 on the WAS client to connect to these server7side co!ponents
Page + of 55
While ,I is interesting b2 itself3 the true value is e-posed in products that can consu!e3 correlate and present the aggregate results of these events as 4ell as other relevant infor!ation to a user as is seen in the deliver2 of the WebSphere $usiness 0onitor as 4ell as products fro! other vendors that support the ,IC $, standards.
Page G of 55
#. S pportin$ Services
In this section3 the focus is on the additional functionalit2 provided b2 the Supporting Services provided in WebSphere Process Server.
Supporting Services
Interface 0aps
$usiness Ob%ect 0aps
(elationships
Selectors
Figure % Supporting Services Supporting Services provide the !ediationCtransfor!ation pri!itives for the WebSphere Process Server Service o!ponents. This la2er provides a co!!on !appingCtransfor!ation service to enable !apping of !apping of interface signatures via Interface 0aps3 fields fro! one representation to another via $usiness Ob%ect 0aps3 as 4ell as correlation and s2nchroni9ation of /e2 relationship interfaces bet4een s2ste!s. The Selector fra!e4or/ provides for d2na!ic co!ponentCtarget invocation 4hich is currentl2 based on dateCti!e
"rans!ormations
;le-ible and scalable business integration and SOA7based solutions often re:uire support for different t2pes of transfor!ations. WebSphere Process Server delivers highl2 fle-ible3 2et po4erful transfor!ation capabilities through its 0ediation ;ra!e4or/ and 0ediation o!ponents. The transfor!ation capabilities in WebSphere Process Server can be used in different co!binations to create 0ediations that !eet the transfor!ation re:uire!ents of our custo!ers. The 0ediation ;ra!e4or/ provides functions to handle business infor!ation distribution and !ediation patterns. It provides a set of tools for co!posing "!odel3 unit test3 debug3 asse!ble3 generate and deplo2# 0ediation o!ponents visuall2 4ithout or 4ith !ini!i9ed progra!!ing efforts as sho4n in ;igure &. The 0ediation o!ponent is a progra!!ing !odel artifact for !odeling the distribution and !ediation patterns in business integration applications. ;inall23 the 0ediation ;ra!e4or/ delivers a runti!e infrastructure for invo/ing !ediations. 0ediations can be applied to $usiness Ob%ects "$O# or to events or re:uests "e.g. interfaces# associated 4ith $usiness Ob%ects. A 0ediation o!ponent is a Service o!ponent Architecture "S A# o!ponent 4hich is logicall2 separate fro! the source and target co!ponents. ;igure & sho4s the high level vie4 of the relationship bet4een !aps3 i!portsCe-ports3 and the business process.
Web Service WS ,-port 0ediation o!ponent $usiness Process 0ediation o!ponent ,IS I!port !"S
'ap
'ap
Figure & 'editation Flo( in WebSphere Process Server
Page 1) of 55
Figure ) *rans#ormations in WebSphere "ntegration +eveloper The 0ediation o!ponent supports Interface 0ediation3 4hich provides operation binding and para!eter !ediation. In addition3 a 0ediation o!ponent is co!posed fro! a se:uence of s!aller 0ediation Pri!itives 4hich i!ple!ent the basic !ediation patterns. 0ediation Pri!itives are the core functions that plug7in to the 0ediation o!ponent< the2 include 1ata 0ap Pri!itives3 (elationship 0anage!ent Pri!itives and Selection Pri!itives. 1ata 0aps provide and structural and se!antic transfor!ation of $usiness Ob%ects. (elationship 0anage!ent provides identit2 relationship !aintenance and trac/ing3 as 4ell as loo/up relationships in custo! transfor!ations. ;inall23 Selection supports d2na!ic deter!ination of the target i!ple!entation or destination. @ote that the Selection !ediation pri!itive is restricted to be the last !ediation in the se:uence of !ediation pri!itives. 0ediations help enable developers to bridge co!ponents together. As an e-a!ple3 adapters produce Hevents8 that have specific signatures "operation na!es and para!eters#. These events can be converted into different for!ats b2 !ediation co!ponents for do4nstrea! co!ponents in the overall solution.
"nter#ace 'ediation,
ridging incompatible inter#aces
The Interface 0ediation co!ponent provides resolution and reconciliation of differences bet4een interfaces found bet4een S A co!ponents. A 0ediation o!ponent can be created that understands one interface "cancelOrder# and invo/es another interface "updateOrderStatus# as sho4n in ;igure +. The interfaces can additionall2 !ap the data on these interface calls E for e-a!ple through a 1ata 0ap or custo! code.
Page 11 of 55
'ediation Component
Component A
Component
cancelOrder"Order order#
updateOrderStatus"Order order3 String status# Figure - "nter#ace 'ediation
In ;igure G3 the Order0anager co!ponent reference cannot be directl2 4ired to the SAP adapter interface because the interfaces do not !atch. The !ethod na!es are not the sa!e and the para!eter t2pes are different. When an Interface 0ap is introduced bet4een these co!ponents3 the 0ediation o!ponent acts as a bridge so these t4o co!ponents can be I4iredI together.
retrieve"Order#
fetch"SAPOrder#
Order0anager
SAP HAdapter8
retrieve"Order# retrieve"Order# Order0anager Interface 0ediator fetch"SAPOrder#
fetch"SAPOrder#
SAP HAdapter8
Figure . 'ediation component interposed
+ata 'ap,
usiness Ob/ect *rans#ormation
1ata 0aps are the si!plest for! of !ediation. WebSphere Process Server contains a rich graphical !apping tool that offers 0ove3 6oin3 ,-tract and Assign of data fields as 4ell as custo! !apping "through usto! Activities or 6ava ode#. It also offers sub7!aps for co!ple- business ob%ect structures as 4ell as relationship !apping. The 1ata 0ap Service is a Hs2ste!8 Service that enables graphical conversion of one $usiness Ob%ect into another as sho4n in ;igure 1).
Page 12 of 55
Figure 10 +ata 'ap in WebSphere "ntegration +eveloper +ata 'apping 1"nbound2 In the ;igure 113 an adapter polls the bac/end ,IS s2ste! "for e-a!ple> SAP# for reate3 (ead3 Jpdate or 1elete " (J1# events of application7specific business ob%ects "AS$O# "for e-a!ple> SAP usto!er and SAPOrder# and publishes the! to a set of business processes !odeled using generic business ob%ects "?$O# "for e-a!ple> usto!er and Order# for further processing. In this case3 the 1ata 0ap Pri!itive in the 0ediation o!ponent enables the re:uest to be transfor!ed into a canonicalCgeneric for!at "?$O# fro! an application7specific for!at "AS$O#. This built7in functionalit2 enables transfor!ation of the operation na!e "Interface 0ediation# as 4ell as the content and structure of the para!eter"s# being passed as part of the operation "1ata 0ap# as sho4n belo4 in ;igure 11.
Page 13 of 55
AS O ",-. SAP usto!er3 SAPOrder# 'ediation Component

+ata 'ap 1
4 O ",-. usto!er3 Order# Process 31 Process 31 Process 31
!"S Adapter
+ata 'ap 2
Figure 11 +ata 'apping 1"nbound2 +ata 'apping 1Outbound2 In the ;igure 123 the business processes is !odeled using generic business ob%ects "for e-a!ple> usto!er and Order# and re:uests (J1 access to a bac/end ,IS s2ste! "for e-a!ple> SAP# via an adapter 4hich supports application7specific business ob%ects "for e-a!ple> SAP usto!er and SAPOrder#. In this case3 the 1ata 0ap Pri!itive in the 0ediation o!ponent transfor!s the re:uest fro! the generic or generali9ed for!at to the application7specific for!at as sho4n in ;igure 12.
4 O ",-. usto!er3 Order# Process 31 Process 32 Process 35 'ediation Component

+ata 'ap 3
AS O ",-. SAP usto!er3 SAPOrder#
Adapter !"S
+ata 'ap $
Figure 12 +ata 'ap
Relationship #anagement$ dentity Relationship management and loo%ups

In business integration scenarios it is often necessar2 to access the sa!e data "for e-a!ple> custo!er records# in various bac/end s2ste!s. A co!!on proble! for /eeping data in s2nc is that different bac/ end s2ste!s use different /e2s to represent the sa!e data. The (elationship 0anage!ent service in WebSphere Process Server is used to ArelateB these disparate data sources. As a $usiness Ob%ect is converted fro! one application specific representation into another3 WebSphere Process Server can d2na!icall2 !aintain a database of /e2s enabling the !apping of one data record into another bet4een disparate bac/end s2ste!s. ;igure 13 sho4s the concept of a d2na!ic identit2 relationship 4ith a custo!er identifier being !aintained 4ithin * different applications. In conventional !iddle4are solutions3 this is an e-tre!el2 difficult solution to develop and3 !ore i!portantl23 to !anage in an ongoing basis. WebSphere Process Server auto!ates this activit2 through a set of capabilities that provide an integrated fra!e4or/ for !anaging d2na!ic relationships.
Page 1* of 55
ustLI1
1)& 1)' 101)G 11)
Relationship Role instances
(II1
*) *1 $2 *3 **
Relationship instance
(II1
*) *1 $2 *3 **
usto!erId
3*G* 3*G5 3$.& 3*G' 3*G+
Relationship Role instances
,IS1 ust Ora ust
usto!e r
,IS2 ust SAP ust
custo!erLid (II1
11525 1152& 11%2) 1152+ 1152G *) *1 $2 *3 **
(II1
*) *1 $2 *3 **
0asterId
($32+ (@*55 *6$21 111&* ($*5&
Relationship instance
Figure 13 "dentity Relationships (elationships are available directl2 fro! business ob%ect !aps and si!plif2 the !anage!ent of disparate bac/end data representations. The follo4ing e-a!ple in ;igure 1* depicts a reate event fro! an ,IS "for e-a!ple> create usto!er fro! SAP# 4hich re:uires the WebSphere Process Server to d2na!icall2 create and !aintain a relationship bet4een the ,IS7specific ob%ect I1 "for e-a!ple> SAP usto!erI1# and the generic ob%ect I1 "for e-a!ple> usto!erI1#. ;uture updates to this uni:ue usto!er fro! another application or ,IS "for e-a!ple> Siebel# use this e-isting relationship to ensure the correct records are reated3 (ead3 Jpdated or 1eleted. Si!ilarl23 a (elationship could be called fro! the 1ata 0ap to perfor! a loo/up of a value "such as Jnit of Issue e.g. 5iter is e:uivalent to 5t# or other static infor!ation.
'ediation Component 31 !"S Adapter

+ata 'ap Relationship
Process 31
Figure 1$ Relationships In addition to d2na!ic identit2 relationship !anage!ent3 WebSphere Process Server also supports loo/up3 or static relationships. This feature can be used to define static loo/up tables 4here one entr2 al4a2s represents another entr2 and this relationship never changes "for e-a!ple> 5T K 5iter3 F0 K Filo!eter3 etc.#. (elationships are created using the (elationship 1esigner in WebSphere Integration 1eveloper and stored in a database.
Selectors$ Routing Business &ogic

The Selector co!ponent provides a !eans of !ediation bet4een the client application and the target destination a d2na!ic selection !echanis!.
Page 15 of 55
The ob%ective of the Selector is to> 1eter!ine d2na!icall2 4hich i!ple!entation of a target destination to invo/e based on so!e defined set of criteria3 data and logic " urrentl2 the Selector onl2 supports dateCti!e# 1ecouple the client application fro! a specific target destination i!ple!entation allo4ing for d2na!ic selection and invocation of a target destination Allo4 ne4 i!ple!entations of target destinations to be added to the s2ste! 4ithout re:uiring changes to the client application Allo4 ne4 S A i!ple!entations of a target destination to be added to the Selector d2na!icall2 4ithout re:uiring a restart of the application or server Provide a fra!e4or/ allo4ing for custo! selector algorith!s to be e-ecuted fro! a Selector o!ponent
The Selector co!ponent design involves three participants> the lient3 the Selector and the 1estination as sho4n in ;igure 15.
lient
Selector
1estination
12na!icall2 choose 4hich destination to invo/e
Target 1estination s
Figure 1% Selector conceptual diagram lient> The client co!ponent !a/es a call on the Selector o!ponent. A client can be an2thing that can call a S A co!ponent. Selector> The Selector o!ponent is a generated S A co!ponent 4here each operation reflects a business need or tas/ and the target destinations provide the i!ple!entation. The Selector o!ponent chooses 4hich target destination to invo/e using a declared selection i!ple!entation. 1estination> The Selector o!ponent can choose an2 S A target destination t2pe. The destinations for each operation on the Selector o!ponent are associated 4ith the specific Selector o!ponent. ;igure 1& sho4s a si!ple e-a!ple that invo/es different co!ponents based on a selector rule. In this case3 the 1iscount selector is deter!ining 4hich target destination to call to deter!ine the discount available.
Page 1& of 55
Figure 1& Selector e7ample @e4 co!ponents can be hot7deplo2ed and the selector rules can be updated d2na!icall2. It should be noted that the Selector co!ponent is not designed to be a replace!ent for $usiness (ules3 rather a 4a2 to deter!ine at runti!e 4hich pre7defined co!ponent to call for a particular operation.
Page 1' of 55
%. Service Co&ponents
In this section3 the focus is on the functionalit2 provided b2 the Service integration i!ple!entation services for WebSphere Process Server. o!ponents provided as the
Service Components
$usiness $usiness Processes Processes
.u!an .u!an Tas/s Tas/s
$usiness $usiness State State 0achines 0achines
$usiness $usiness (ules (ules
Figure 1) Service Components These services ";igure 1'# are the high7level co!ponents of the WebSphere Process Server integration platfor! and can be 4ired together to create po4erful solutions based on the SOA ore technolog2. As a result3 the Service o!ponents provide the integration i!ple!entations 4hich can act as both service providers and service consu!ers as part of an SOA7based approach to integration though standard SOA interface relationships.
Business 'rocess
$usiness Processes are an i!portant concept in toda28s integrated environ!ents and pla2 a /e2 role in business7to7business and enterprise application integration scenarios b2 e-posing the appropriate invocation and interaction patterns. Processes are the building bloc/s for developing consistent distributed applications in heterogeneous environ!ents. Process based applications are co!posed of t4o distinct pieces> A process !odel that describes the logical order in 4hich the different activities of the process !odel are being carried out and the individual servicesCco!ponents that i!ple!ent the various activities. Therefore a business process is a set of business7related activities3 rules and conditions that are invo/ed in a defined se:uence to achieve a business goal. ;igure 1+ sho4s a logical business process flo4 4ith five activities and four co!ponent interfaces e-plicitl2 sho4n "@ote> The initiating activit2 is also a co!ponent interface 4hich could be an originating tas/ via the .u!an Tas/ 0anager3 a Web Service invocation or an invocation fro! another Service o!ponent 4ithin WPS. Those activities can be a variet2 of different resources that are represented as one or !ore S A co!ponents. All activities are logicall2 connected 4ith i!plicit or e-plicit connectors "control lin/s# 4hich define the logical order in 4hich the business process is e-ecuted. Process activities can be e-ecuted in se:uence or in parallel dependent on the business re:uire!ent and the internal dependenc2 of the process steps.
Page 1+ of 55
$usiness Process
62,,
Service s
$ac/7end S2ste!s
Partner Service
Figure 1- Conceptual picture o# a usiness Process The purpose of the $usiness Process engine is to interpret the process te!plates3 !anage the life7c2cle of business processes3 to navigate through the associated process !odel3 and integrate the appropriate business functions.
WS8 P!9
WS7$P,5 defines a !odel and a gra!!ar for describing the behavior of a business process based on interactions bet4een the process and its interactions 4ith e-ternal partners. It can be used to specif2 both the public interfaces for the partners and the description of the e-ecutable process. A partner can be an2 entit2 4hich either provides a service3 consu!es a service or both. WS7$P,5 provides the !eans to specif2 business processes that are co!posed of Web services as 4ell as e-posed as Web Services. The interaction 4ith each partner occurs through Web Service interfaces3 and the structure of the relationship at the interface level is encapsulated via partner lin/s. The WS7$P,5 process defines ho4 !ultiple service interactions 4ith these partners are coordinated to achieve a business goal3 as 4ell as the state and the logic necessar2 for this coordination. WS7$P,5 provides s2ste!atic !echanis!s for dealing 4ith business e-ceptions and processing faults. ;inall23 WS7$P,5 i!ple!ents a fra!e4or/ to define ho4 individual or co!posite activities 4ithin a process are to be co!pensated in cases 4here e-ceptions occur or a partner re:uests reversal of a scope of 4or/. WS7$P,5 is founded on an D05 notation and se!antics for specif2ing business process behavior based on Web Services. The standard evolved fro! $P,5*WS and features !an2 i!prove!ents for creating fle-ible $usiness Processes. It is based on WS15 1.13 D05 Sche!a 1.) and DPath 1.). WS15 !essages and D05 Sche!a t2pe definitions provide the data !odel used b2 WS7$P,5 processes. DPath provides support for data !anipulation. All e-ternal resources and partners are represented as WS15 services A WS7$P,5 co!pliant process can be e-ecuted in an2 process e-ecution environ!ent supporting that standard. Therefore WS7$P,5 process te!plates are portable. The highlights of WS7$P,5 are> $P,5 co!pensation "co!pensation handlers3 co!pensate activit2# for undoing process steps 4hich have alread2 been co!!itted ,vent handlers for having fle-ible 4a2s to handle as2nchronous event issues during process e-ecution Support for DPath as :uer2 and e-pression language "e.g. in conditions# providing !ore fle-ibilit2 e.g. for !odeling process conditions ,-plicit isolated scopes3 allo4ing for separation of internal error and event handling
Page 1G of 55
;ault handlers for advanced internal process error handling
usiness Process Features

WebSphere Process Server supports the follo4ing activities in the $usiness Process editor. This docu!ent 4ill not cover the individual activit2 t2pes ho4ever this infor!ation is readil2 available in other sources.
Figure 1. WS8 P!9 Activities supported WebSphere Process Server .u!an Tas/ 0anager functions are not included as the2 are covered separatel2 and are nor!all2 created as a separate S A co!ponent. WebSphere Process Server supports all the functionalit2 of WebSphere $usiness Integration Server ;oundation Mersion 5.1 "W$IS;# plus additional features. ;or readers fa!iliar 4ith W$IS;3 the follo4ing section e-plains these ne4 features in detail.
P!9 !vent :andlers

$P,5 ,vent .andlers allo4 for e-ternal re:uests to arrive as2nchronousl2 to nor!al e-ecution and add an optional parallel thread for process e-ecution. On occurrence of that event the $P,5 event handler is e-ecuted3 ho4ever the process continues nor!all2 if that event is not received 4ithin the configured process section.
P!9 Compensation :andlers

o!pensation is the concept of roll7bac/ over a se:uence of alread2 co!!itted transactions3 a logical undo of alread2 co!!itted 4or/. o!pensation in WPS is $P,5 co!pliant and 4or/s according to the $P,5 o!pensation handler !echanis!. o!pensation logic specified per process is added to the process b2 !eans of a $P,5 co!pensation handler3 4hich specifies co!pensation logic to be e-ecuted in case the unit it applies to "e.g. a scope# has to be co!pensated.
Page 2) of 55
;Path support
In accordance 4ith WS7$P,53 WPS supports DPath state!ents for process ele!ent e-pressions and conditions "e.g. Transition condition#. ,as2 access of custo! properties "activit2 or process properties# or initiali9ation and co!parison of process data ob%ects is possible via DPath e-tension functions.
9i#e8cycle support
WPS supports enhanced life7c2cle co!!ands. A process7subprocess relation is life7c2cle a4are. That !eans that if a processTerminate co!!and is issued against the parent process3 the subprocess is ter!inated as 4ell and vice versa. Apart fro! the processTerminate co!!and additional life7c2cle co!!ands have been added> Suspend, resume. The entire process instances can no4 be suspended and resu!ed. This is valuable to cover i!portant concepts li/e deferred e-ecution of a business case. Restart> The entire process instance can no4 be restarted3 e.g. in case of an e-ception 4hich corrupts the process3 a co!plete process restart is possible.
Business 'rocess ()amples

$usiness Processes are used to solve a 4ide variet2 of business proble!s. WebSphere Process Server i!ple!ents functionalit2 4hich !aps to features available in WebSphere $usiness Integration Server ;oundation3 WebSphere I S and WebSphere 0= Wor/flo4 and provides techni:ues for building solutions that !i!ic the functionalit2 available in each of these previous products. 5et8s :uic/l2 loo/ at ho4 these tools provide business process support to illustrate the advanced architecture of the WebSphere Process Server.
WebSphere
usiness "ntegration Server Foundation !7ample
WebSphere Process Server is a straight evolution of W$IS;. As such3 the business process !odel available in W$IS; is supported and e-tended in WebSphere Process Server as previousl2 discussed. ;igure 2) sho4s a si!ple WPS solution. On the left is a Web Services export 4hich is used to e-pose the service as a standard Web Service. The service in this case is a $usiness Process that has all the capabilities described in this section and is based on WS7$P,5. The $usiness Process can reference partners that are e-posed as references in the solution and are i!ple!ented as Web Services.
Business Process WS Export BO BO
WS Import
Figure 20 WebSphere
usiness "ntegration Server Foundation usiness Process !7ample
WebSphere "nterchange Server !7ample

WebSphere Inter hange Server "WI S# !a/es e-tensive use of adapters for both input " export# and output "import# and is often used to s2nchroni9e the contents of various enterprise s2ste!s. WI S !a/es
Page 21 of 55
e-tensive use of transfor!ations and co!ple- !anipulation of data through advanced graphical tooling. These features are delivered in WPS through transfor!ations in the 0ediation ;ra!e4or/. ;igure 21 displa2s a sa!ple WI S7st2le solution i!ple!ented in WebSphere Process Server On the left3 the adapter provides the source AS$O "Application Specific $usiness Ob%ect#. Jsing the sophisticated transfor!ation and 0ediation features of WPS "that is conceptuall2 based on WI S concepts#< the AS$O is converted to a ?$O "?eneric $usiness Ob%ect#. Optionall23 the ?$O can be passed into a $P,57 based business process for further enhance!ent or action. As a final step3 the ?$O can be converted bac/ to an AS$O for output to target s2ste!s via another adapter.
Adapter ASBO Mediation GBO
Business Process GBO
ASBO
ASBO
Figure 21 WebSphere "nterChange Server !7ample
WebSphere '< Wor=#lo( !7ample

WebSphere 0= Wor/flo4 is a WebSphere 0=7based 4or/flo4 solution. 0an2 of the concepts for the .u!an Tas/ 0anager are derived fro! WebSphere 0= Wor/flo4. ;igure 22 sho4s a si!ple e-a!ple of a 60S export receiving a !essage and passing it directl2 to a .u!an Tas/ 0anager service covered in the ne-t section. The .u!an Tas/ 0anager provides all the services to interact 4ith the user and !anage that interaction. Once the hu!an tas/ is co!plete3 the output could be to another 60S location.
Human Task Manager JMS Export BO BO
JMS Import
Figure 22 WebSphere '< Wor=#lo( !7ample
Combination o# Services
In this section3 4e have described the si!ple !appings of previous products in ter!s of their fra!e4or/ pattern to i!ple!entation via WPS functions. The /e2 value of the WebSphere Process Server is that the product "as a result of the S A fra!e4or/# enables developers to utili9e a co!bination of these features to develop solutions that support functionalit2 not previousl2 available in a single product.
*uman "as% #anager

The .u!an Tas/ 0anager provides the hu!an tas/ capabilities for WebSphere Process Server> To start a process or other service co!ponents To i!ple!ent staff activities
Page 22 of 55
To allo4 for process ad!inistration To d2na!icall2 create tas/s that involves hu!ans or services.
.u!an Tas/ 0anager addresses the basic scenarios !achine7to7hu!an "02.#3 hu!an7to7!achine ".20#3 and hu!an7to7hu!an ".2.#. The !achine7to7hu!an scenario is the classical W$IS; staff service co!ponent scenario 4here a process engine "a A!achineB# creates tas/s for people 4ho participate in the e-ecution of a business process. The hu!an7to7!achine scenario is different in the sense that it allo4s a person to create a tas/ that is e-ecuted b2 an auto!atic service. An e-a!ple of an auto!atic service is a $P,5 business process or an arbitrar2 4eb service that can do a variet2 of functions such as invo/ing a SOAP service3 calling a I S transaction3 invo/ing a !ethod on an enterprise bean3 or retrieving a docu!ent fro! a docu!ent !anage!ent store. In the hu!an7to7hu!an scenario a tas/ is created b2 a person "a hu!an# for another person. An e-a!ple 4ould be a travel approval re:uest created b2 an e!plo2ee for his !anager.
:uman *as=s
.u!an tas/s are used to allo4 co!ponents to Ainvo/e hu!ans as servicesB. The Ahu!anB is actuall2 a person that is authori9ed to select that tas/ fro! a group of authori9ed users. Since the hu!an is si!pl2 considered a service3 the replace!ent of one service for another is %ust a si!ple !atter of co!ponent 4iring or asse!bl2. . As a result3 an operation perfor!ed b2 a person in the first place could be replaced b2 an operation represented as a business process3 a Web service invocation3 an operation on an enterprise bean3 a I S transaction3 or other co!ponent interfaces. .u!an tas/s provide a co!!on interface for hu!ans to deal 4ith hu!an centric and auto!atic tas/s in a unifor! 4a2. lient applications using the .T0 API provide users 4ith a single vie4 to start3 for e-a!ple3 a $P,5 process3 a docu!ent !anage!ent s2ste!3 or a Wor/place application. The API allo4s users to create and start tas/s independent of their i!ple!entation and3 as a result3 this provides a unifor! ad!inistration sche!e across applications. A tas/ activit2 contains the data re:uired to co!plete the tas/. So!e of this infor!ation co!es fro! the specific business scenario "as an e-a!ple3 the creation of purchase re:uisition#. The properties of a tas/ t2pe represent the !eta infor!ation specific for that tas/. 0eta infor!ation can be specified 4hen creating a tas/ or b2 defining a tas/ t2pe called tas/ te!plate. .u!an Tas/ 0anager supports different tas/ t2pes to address the different scenarios li/e !achine7to7 hu!an "02.#3 or hu!an7to7hu!an ".2.#. The follo4ing different /inds of tas/s can be specified> An Originating Tas/ "O7Tas/# is a tas/ that invo/es another o!ponent3 i.e. a $usiness Process3 b2 the user assigned to the tas/. It is !ainl2 responsible for handling authori9ation issues. An Ad!inistrative Tas/ "A7Tas/# is a tas/ that is intended to ad!inister other Service o!ponents. A Participating Tas/ "P7Tas/# is a tas/ this is invo/ed fro! another Service $usiness Process. o!ponent3 i.e. a
A Apurel2B .u!an Tas/ ".7Tas/# that is created b2 another tas/3 that !eans .u!an7to7.u!an co!!unication. An Inline Tas/3 /no4n as staff activit2 fro! v5 !odeling3 has to be used 4hen the staff assign!ent for this activit2 has to have /no4ledge about the process and perfor!ers of preceding tas/s.
Page 23 of 55
;igure 23 sho4s ho4 so!e of these .u!an Tas/ t2pes !a2 be used in a business process. The follo4ing sections discuss these tas/s in !ore detail.
Figure 23 Processes and *as=s
Originating "as%s (*+#)

Originating tas/s are used to !a/e services available for hu!ans. An e-a!ple 4ould be a tas/ that starts a business process or invo/es a Web service. Technicall2 spea/ing3 oTas/s provide support for calling ever2 service that has its interface e-posed as a S A co!ponent. These tas/s are i!ple!ented b2 S A services. When the tas/ is created it invo/es the service offered b2 the associated Service co!ponent and goes into the state (unning. It re!ains in that state until the service returns or the tas/ e-pires. ;or oTas/s calling one74a2 services or services 4ith as2nchronous binding the state Running is transient. The e-piration !echanis! for oTas/s is e:uivalent to 4hat has been described before. When the service returns3 the tas/ goes into its end state Finis ed if the service returned 4ith a regular output !essage. If the service has raised a fault then the tas/ goes into its end state Failed. After the tas/ has reached an end state it !a2 e-ist for an infinite period of ti!e if no auto!atic deletion has been specified 4hen defining the tas/. The tas/ ceases to e-ist after it has been deleted.
Administrative "as%s
Ad!inistrative tas/s are created b2 co!ponents that 4ant to offer an interface for a hu!an ad!inistrator. A7Tas/s can be used to ad!inister arbitrar2 co!ponents. One particular usage scenario is to support ad!inistrative actions on a $P,5 process li/e suspend3 resu!e and ter!inate. Another scenario is repairing failed activities in a $P,5 process. Other scenarios 4here aTas/s could be used are the ad!inistration of an as2nchronous Service invocation3 a docu!ent in a docu!ent store3 or an application li/e Wor/place. Ad!inistrative tas/s have %ust a single state> Ready. The2 go into this state once created and re!ain there until the2 are deleted. As aTas/s can be used to ad!inister arbitrar2 co!ponents it is not possible to reflect the ad!inistered co!ponents state in the aTas/.
Page 2* of 55
'articipating "as%s
Participating tas/s allo4 a service to involve hu!ans into its operation. The classical e-a!ple for this is a business process 4ith staff activities. ;or e-a!ple 4hen loo/ing at $usiness Process horeographer there a process engine "a A!achineB# creates tas/s for people participating in the e-ecution of a business process. The use of pTas/s is not li!ited to $usiness Process horeographer. Participating tas/s are e-posed as Service o!ponents and thus can be 4ired 4ith other Service o!ponents to include a service 4ith a Ahu!anB i!ple!entation into a Service based application.
*uman "as%s (*+*)

.u!an tas/s are tas/s a person creates for either one or !an2 other persons. .u!an tas/s are si!ilar to oTas/s in that the2 are both created b2 hu!ans. .u!an tas/s are si!ilar to oTas/s in that the2 are both Ai!ple!entedB b2 hu!ans. An hTas/ can be seen as a shorthand notation for an oTas/ that is tightl2 coupled 4ith a pTas/. ,-a!ples for hTas/s are a travel approval re:uest created b2 an e!plo2ee for his !anager3 a tas/ that as/s so!ebod2 for the revie4 of a docu!ent3 or a tas/ re:uesting one of the e!plo2ees of a call7center to call bac/ a custo!er. WebSphere Process Server additionall2 provides for the creation of d2na!ic ad7hoc Tas/s. In adhoc scenarios3 hTas/s i!ple!ent subtas/s and follo4 on tas/s. These are onl2 supported for hTas/s and pTas/s and can be created and started b2 the tas/ o4ners. A subtas/ 4ill return to its starter3 a follo47on tas/ 4ill directl2 return to the service that invo/ed the hu!an tas/ initiall2.
:uman *as= !ditor

The runti!e co!ponent of the .u!an Tas/ 0anager is a Service o!ponent that e-ecutes .u!an Tas/s b2 instancing Tas/ Te!plates. The .u!an Tas/ ,ditor in I$08s Websphere Integration 1eveloper provides the develop!ent tooling for generating and !odif2ing such te!plates. The developer interface for the .u!an Tas/ ,ditor is sho4n in ;igure 2*. A Tas/ Te!plate consists of three !a%or parts> Staff Settings3 lient Settings and ,scalation Settings3 along 4ith so!e properties of the tas/ itself. Jsing the various tabs the developer can specif2> Staff Settings> In this part3 the user can set authori9ation andCor assign!ent aspects of the tas/3 i.e. 4ho 4ill be authori9ed to e-ecute3 !odif23 and vie4 the tas/. lient Settings> In this section of the tas/ te!plate3 one can specif2 ho4 the tas/ 4ill be presented3 i.e. in I$08s standard Web lient or in a custo! lient or as part of a portal page. ,scalation Settings> Within the escalation settings3 the user 4ill specif2 the escalation properties of this tas/. A!ong these properties are things li/e 8can this tas/ be escalated83 the startCend condition of the escalation3 to 4ho! it 4ill be escalated3 etc.
Page 25 of 55
Figure 2$ :uman *as= !ditor After the tas/s had been defined the2 can be used in 4iring diagra! to lin/ an activit2 in process diagra! 4ith the !anual tas/. In ;igure 253 a logical 4iring diagra! sho4s various lin/s> An Originating Tas/ "oTas/# invo/es another o!ponent3 i.e. a $usiness Process3 b2 the user assigned to the tas/. It is therefore !ainl2 responsible for handling authori9ation issues. An Ad!inistrative Tas/ "aTas/# is a created b2 other Service interface for a hu!an ad!inistrator. o!ponents 4ho 4ant to offer an o!ponent3 i.e. a
A Participating Tas/ "pTas/# is a tas/ this is invo/ed fro! another Service $usiness Process.
A .u!an Tas/ "hTas/# that is created b2 another tas/3 that !eans .u!an7to7.u!an co!!unication. In case of a subtas/3 the response is sent to the pTas/ 4hereas a follo4 on tas/ 4ould return to the initial service re:uester. An Inline Tas/3 previousl2 /no4n as staff activit2 in fro! v5 !odeling3 has to be used 4hen the staff assign!ent for this activit2 has to have /no4ledge about the process and perfor!ers of preceding tas/s. The approval activit2 1 has to be perfor!ed b2 the !anager of the person 4ho entered the re:uest in activit2 A.
Page 2& of 55
The concepts for e-ternal tas/s used as Service o!ponent provide for reuse. This !ight i!pl2 the need for a !ediation bet4een the re:uester and the hu!an tas/. It should be noted that 4hen developing hu!an tas/ interactions3 the s2ste! needs to consider life c2cle actions bet4een the involved co!ponents3 e.g. that the process 4ill be suspended.
Figure 2% Wiring +iagram
State *ransition +iagram and Programming "nter#aces

.u!an tas/ interactions are actuall2 a state !achine i!ple!entation fro! a runti!e perspective. If 4e loo/ at hu!an tas/s fro! a J05 2.) perspective3 a tas/ 4ith a Ahu!an i!ple!entationB has the !ain states Ready3 Claimed3 and !aitingForSubtas". When the tas/ is created3 it goes into the state Ready. As long as it is in state Ready3 it can be clai!ed. When a person clai!s the tas/ b2 perfor!ing a chec/7out on the tas/3 it then the tas/ goes into Claimed state. In the standard case3 the person 4ho has clai!ed the tas/ at so!e point in ti!e co!pletes the tas/ b2 specif2ing its output !essage. When the tas/ co!pletes3 the tas/ goes into its end state Finis ed. If a fault !essage is generated instead of the output !essage3 then the tas/ goes into its end state Failed. If 4hile 4or/ing on the tas/ the person decides to create one or !ore hTas/s as sub7tas/s then the tas/ goes into the state !aitingForSubtas" and re!ains there until all sub7tas/s have co!pleted. All the !ain tas/ states have the sub7states ,scalated and Suspended. A tas/ is in the sub7state ,scalated if one of its escalations has fired. ;igure 2& depicts the tas/ state7transition7diagra! for an hTas/ and pTas/.
Page 2' of 55
Figure 2& *as= state8transition diagram #or a p8 and h*as=
Authori>ations
.u!an Tas/ 0anager has an e-tensive authori9ation and staff assign!ent s2ste! 4hich is capable of !odeling both si!ple as 4ell as co!ple- 4or/flo4 tas/s. ;igure 2' provides an overvie4 of the various authori9ation roles. 1ifferent tas/s relate to specific authori9ation role 4hich either !ust be defined "Solid 5ine# or can optionall2 be defined "1otted 5ine# b2 the developer using the .u!an Tas/ 0anager.
Figure 2) Authori>ation Roles
Page 2+ of 55
!scalation and 5oti#ication

The .u!an Tas/ 0anager provides a fle-ible escalation !echanis!. ,scalations can be defined for an2 tas/3 either b2 defining an escalation te!plate together 4ith the tas/ te!plate3 or b2 defining escalation ad7hoc at run7ti!e. .u!an Tas/ 0anager supports starting escalations for one tas/ in parallel as 4ell as associating chains of escalations to a tas/. ,ach escalation has an associated action that 4ill be e-ecuted if the tas/ progress did not !eet the escalation e-pectations. 0ultiple escalations can be defined for each tas/. ;igure 2+ sho4s a sa!ple tas/ and its escalations.
Figure 2- !scalations and !scalation Chain Although a given tas/ !a2 not be re:uired to have !ultiple escalations .u!an Tas/ 0anager is fle-ible enough to full2 support such a scenario 4ith escalation hierarchies. If 2ou 4ant to ensure that a clai!ed tas/ is finished in ti!e3 2ou !a2 4ant to !odel escalations as sho4n in the first escalation chain. The chain is activated 4hen the tas/ reaches the clai!ed state. All escalations e-pect that the tas/ has reached or an end state at their ti!eout. The first escalation of this chain notifies the first line !anager3 4hen the escalation ti!er e-pires and the tas/ is not finished. The ti!er for the second escalation gets activated at this !o!ent and if the second escalation e-pires and the tas/ is still not finished3 the second line !anager is notified too. In a si!ilar fashion3 the ti!er of the third escalation is started3 4hich notifies the third line !anager if the third escalation e-pires and the tas/ has still not finished An escalation traverses various states during its lifec2cle> After creation3 an escalation re!ains inactive until the tas/ reaches the activation state. While an escalation is inactive3 all setter !ethods are still available. After activation3 onl2 those properties "e. g.3 displa2@a!e3 description# can be !odified that do not influence the escalation run7ti!e behavior. After activation "start# the escalation beco!es 4aiting. The ti!er is started and the escalation 4aits until it ti!es out. When a ti!eout occurs3 the at5east,-pectedState of the tas/ under surveillance is chec/ed. If the tas/ has reached or passed it3 the escalation state is changed to superfluous. If not 2et reached3 the escalation state is changed to escalated and the escalation action is invo/ed.
@ote that the tas/ state is different fro! the escalation activation state. The latter t4o states actuall2 refer to the tas/ state to !onitor b2 the escalation3 4hile the escalation state does not refer to the tas/3 but to the escalation ob%ect that traverses its o4n state diagra!. The escalation action can be e-ecuted repeatedl2< the interval is defined b2 the auto(epeat1uration. If set to 9ero3 the escalation action 4ill not be invo/ed repeatedl2. ;ollo4ing escalation3 various actions are supported such as> Wor/ ite! creation for a set of users
Page 2G of 55
,lectronic !ail "e7!ail# notification3 andCor Invocation of an observer event that allo4s for custo! reaction on the escalation.
The escalation notification provides a handle to the 4or/ ite! that allo4s the person that has obtained it to perfor! a 4ell defined set of actions on an associated ob%ect. The set of actions offered is dependent on the ob%ect and the role of the user. Independent of the action selected3 4or/ ite!s are created to ensure visibilit2 of the escalation for escalation receivers3 and people authori9ed to read the tas/. Together 4ith the escalation action invocation3 the associated tas/ priorit2 can be increased as defined b2 the propert2 increasePriorit2. The priorit2 can be increased repeatedl2 if an auto7repeat duration is set. The list of users to be notified is defined b2 a staff :uer2. This :uer2 resolves to a set of user I1s for 4or/ ite! creation. ;or the escalation action e7!ail notification a further staff resolution gets perfor!ed3 to resolve the set of e7!ail addresses.
:uman *as= 'anager Functionality

The !ain features of the .u!an Tas/ 0anager 4here introduced before. .o4ever3 co!pared 4ith W$IS; and WebSphere 0= Wor/flo43 the .u!an Tas/ 0anager provides a series of enhanced features. Support for oTas/s3 aTas/s3 pTas/s3 hTas/s and inline tas/s Separation of the process !odel and the hu!an interaction. This also !eans that the process !odel can focus on the $P,5 process "@ote> the $P,5 e-tension for staff activities are supported b2 the .u!an Tas/ 0anager# Support for adhoc processing in .2. and .20 scenarios ,scalations3 escalation chains and escalation actions for hu!an tas/s Priorities and increase of priorities in case of escalations 5ife c2cle !anage!ent support via suspension at both the process and single 4or/ite! level3 i.e. to put a 4or/ite! on hold A tas/ can be put into Aclai!edB state auto!aticall2 if is resolved to a single user Support for national language enabling via Aresource bundlesA i.e. the tas/ can specif2 and at e-ecution ti!e the displa2 settings3 descriptions3 docu!entation in different languages for a single tas/. A usto!Propert2 field allo4s to have additional colu!ns displa2ed in the Web lient
:uman *as= 'anager Summary

The .u!an Tas/ 0anager converge the /e2 functions of WebSphere 0= Wor/flo4 and W$IS; to create a po4erful3 full function hu!an tas/ solution. Jnli/e other 4or/flo47light solutions in other process integration solutions3 the WebSphere Process Server enables the creation of both si!ple hu!an7directed tas/ solutions as 4ell as traditional 4or/flo4 solutions. .u!an tas/s are i!ple!ented as S A services 4hich allo4s for si!ple substitution in the 4iring diagra! to allo4 organi9ations to substitute auto!ated services for hu!an tas/s directl2.
Business State #achines

$usiness applications often 4or/ 4ith re:uire!ents 4hich can be !odeled as a state !achine e.g. artifacts that !anifest specific states during their e-istence and specific actions to !anage the transitions bet4een those states. ;or e-a!ple3 if a business provides an on7line travel agenc23 the re:uire!ents !ight suggest the creation of a ne4 artifact called a Htrip8. The trip !a2 interface 4ith a nu!ber of other s2ste!s "or services# to perfor! activities such as reserving flights3 hotels and rental cars. A client of the
Page 3) of 55
on7line travel agenc2 can create a trip3 add flights3 hotels and a car as needed3 !a/e the reservations3 and purchase the trip. 1epending on the specific state of the trip re:uest3 different processesCservices can be enabled for the trip and these steps !a2 involve different actions. ;or e-a!ple3 a trip that has onl2 been reserved is eas2 to cancel3 but3 once the trip has been purchased3 there is a different process for cancellation of the trip "for e-a!ple3 a flight !a2 be changeable3 but cannot be cancelled#. As another e-a!ple3 once the first leg of a flight has been used3 it !a2 be i!possible to cancel or change the return flight. This /ind of stateful business artifact can be i!ple!ented using $P,5< ho4ever3 creating a state !achine using $P,5 pri!itives is a co!ple- tas/. As a result3 it is beneficial to be able to develop the process !odel in ter!s of a state !achine. The $usiness State 0achine "$S0# co!ponent provides this function and allo4s the business artifact to be defined in ter!s of a state !achine. This develop!ent approach enables develop!ent3 debug3 and !onitoring to be done in ter!s of a state !achine 4hile ta/ing advantage of all of the design fle-ibilit2 that a $S0 provides. ;igure 2G sho4s ho4 the $usiness State 0achine "4ithin WebSphere Process Server# i!ple!ents this develop!ent approach. The first stage is to define the state !achine and the processes it uses. This process can be acco!plished b2 using a graphical tool that allo4s the developer to 4or/ 4ith a J05 state diagra! 4hich generates the $usiness State 0achine description and associated WS15. The $usiness State 0achine description is an D05 docu!ent 4hose sche!a is called the State Adaptive horeograph2 5anguage "SA 53 pronounced sac el#. As an alternative3 a developer could 4rite the SA 5 and WS15 files directl2. These artifacts can be used as input to create the S A co!ponent. This co!ponent can then be !odeled and attributed through a state !achine perspective and can be debugged easil2 4ith the underl2ing tooling. J05 based state !achine develop!ent tools ,vents in $S0 ter!s 1ebug
reate $S0 description "D05 7 .sacl# and WS15 ?enerate $P,5 ?enerate "$P,5 $uilder# S A o!ponent
"D05 7 .bpel# "$S0 $uilder# and WS15
Figure 2. usiness State 'achine "mplementation Within WebSphere Process Server3 the $usiness State 0achine is provided as a S A co!ponent that e-poses events. These events3 assu!ing the guard condition"s# is satisfied3 causes an action to occur and changes the state of the $usiness State 0achine. The user !a2 decide not i!ple!ent a $usiness State 0achine as the central co!ponent in a specific integration and !a2 use it indirectl2 as part of the i!ple!entation of a higher level concept. The developer can develop additional code that 4or/s 4ith the $usiness State 0achine. 1evelopers !a2 add ?JIs "such as 6S;7based portlets# for the $usiness State 0achine 4hich d2na!icall2 gre2s out options depending on the state of the $usiness State 0achine. The application is developed such that that it 4or/s 4ith its $usiness State 0achine to e-pose 4hat can be done 4ithin it in different states. ;or e-a!ple3 a trip in the reserved state can be cancelled or it can have the tic/ets issued or an Order can be cancelled up until it is shipped. The benefit of this co!ponent is that it enables support for business artifacts through a state !achine !etaphor E this offers benefits to develop!ent b2 providing an intuitive 4a2 to !odel the process behavior !ore :uic/l2 than atte!pting to !odel these functions via a pure process7oriented !etaphor.
Page 31 of 55
Functional +escription
The $usiness State 0achine provides state !achine develop!ent 4ithin WebSphere Process Server. The $usiness State 0achine is closel2 based on the J05 2.) state !achine support3 so J05 2.) state !achine ter!inolog2 4ill be used. A $usiness State 0achine definesCcharacteri9es events that cause state transitions to occur. An event is accepted onl2 if its associated guard !ethod is passed. Actions are associated 4ith a successful event that signifies the entr2 andCor e-it of a state. The J05 diagra! for a si!ple state !achine is sho4n in ;igure 3) belo4.
Initial State 1 C Action 1 entr2C ,ntr2 Action e-itC ,-it Action ;inal ,vent 2N ?uard 2 O C Action 2
Figure 30 Simple ?'9 2@0 State 'achine The $usiness State 0achine consists of> SCA "nter#ace> provides the state !achine events as operations as 4ell as providing other functions for 4or/ing 4ith the state !achine variables "such as state#. State> a persistent variable in the $P,5 long running process that represents the current state of the underl2ing artifact and is used to control the flo4 of the $P,5. !vents> !a2 cause state transitions to occur in the state !achine. These are invo/ed b2 calling S A operation on the co!ponent interface. 4uards> provide a non7!utative $oolean function that can bloc/ the transition. These !a2 be i!ple!ented as si!ple 6ava snippets or !a2 invo/e a S A. ?uards are optional. Actions> i!ple!ent business logic that is e-ecuted 4hen an event is accepted and a transition is ta/ing place "I.e. 4hen the guard !ethod evaluates true#. These !a2 be i!ple!ented as si!ple 6ava snippets or !a2 invo/e a S A. Actions are optional. State !7it Actions> i!ple!ent business logic that is e-ecuted 4hen e-iting a state. This action is done no !atter 4hich event caused the state to be e-ited. These !a2 be i!ple!ented as si!ple 6ava snippets or !a2 invo/e a S A. State ,-it Actions are optional. State !ntry Actions > i!ple!ent business logic that is e-ecuted 4hen entering a state. This action is done no !atter 4hich event caused the state to be entered. These !a2 be i!ple!ented as si!ple 6ava snippet or !a2 invo/e a S A. State ,ntr2 Actions are optional. The guard3 action3 state e-it action and state entr2 action are all optional. Also3 there are so!e special cases 4here one or !ore cannot be specified< for e-a!ple3 in the above J05 diagra! "see ;igure 3)# the transition fro! the initial state to State 1 did not "and could not# have an event or a guard based on the representation.
State machine details

The $usiness State 0achine state !achine support is !ore e-tensive than the si!ple e-a!ple state !achine in ;igure 3). The e-a!ple sho4n in ;igure 31 is a !ore co!plete state !achine that uses !ost of the features supported b2 $usiness State 0achine.
Page 32 of 55
InitialState1 C 9) State) event2N g2 O C a2
eventGN gG O C aG
State1 entr2C entr21 e-itC e-it1
event+N g+ O C a+
;inalState1
event1N g1 O C a1 event3N g3 O C a3 QQ o!posite StateRR State2
C 92
event-N g- O C a-
State3 event after 12 secondsC Sevent5 event5N g5 O C a5
State*
event&N g& O C a&
State5
event'N g' O C a'
;inalState3
Figure 31 Complete state machine e7ample This state !achine has an initial state "nitialState1 "blac/ dot#3 4hich is the state for the state !achine 4hen it is created. This fact !eans that onl2 one initial state can e-ist in a state !achine. This initial state is a pseudo7state that auto!aticall2 transitions to the ne-t state3 State 0 in this e-a!ple. This !eans that there can onl2 be one transition out of an initial state and it cannot have an event or a guard associated 4ith it. An action can be perfor!ed 4ith this auto!atic transition b2 specif2ing an action on the transition "9) in ;igure 31#. In ;igure 313 State 0 accepts t4o eventsPevent1 and event23 4hich transitions to State2 or State1 respectivel2. 5oo/ing at the transition caused b2 event23 4e can see that the guard condition g2 is chec/ed and if it passes the guard condition3 the e-it action for State 0 is e-ecuted "none in this e-a!ple#. ;ollo4ing the optional e-it action3 the action a2 is perfor!ed and the state changes to State 1. ;inall2 the entr2 action "entr21# for State 1 is perfor!ed. The other transitions in the state !achine are si!ilar. The differences of interest are> The successful transition fro! State 1 caused b2 either event+ or event3 4ill cause the e-it action e-it1 to occur. Self transitions3 such as eventG fro! State 13 can be either internal or e-ternal. A successful internal transition does not invo/e the entr2 or e-it actions "it is as if the state did not change#3 4hereas a successful e-ternal transition 4ill cause entr2 and e-it actions to occur.
Transitions !a2 onl2 have at !ost one guard3 action state e-it or state entr2. If !ore than one guard or state e-itCentr2 is needed3 it should be done b2 developing code for the one allo4ed 4hich in turn invo/es the additional logic to support the guard andCor actions. ;or e-a!ple3 if t4o actions need to be perfor!ed 4here a1 is in our e-a!ple3 4e could create a $P,5 process that invo/es the t4o actions and have a1 invo/e the process as a S A. States can also specif2 that an event should be fired after the state !achine has been in that state for a specified duration to !odel3 for e-a!ple3 a ti!eout condition. State 3 specifies that after 12 seconds
Page 33 of 55
event5 should be raised. The event !ust be one that can be accepted b2 the state. If a ti!eout occurs3 but fails "such as being prevented b2 the guard !ethod E g5#3 the ti!er is not restarted. State 2 is a co!posite state. o!posite state !achines are provided to enable deco!position of the state !achine into easier to understand pieces. It allo4s a hierarchical organi9ation of the top !ost state
eventfN gf O C af QQInternalRR
InitialState2 C 91 State2a eventaN ga O C aa
State2b entr2C enter2b e-itC e-it2b eventcN gc O C ac
eventcN gc O C ac
eventbN gb O C ab
;inalState2
QQTer!inate StateRR
eventdN gd O C ad State2c
Figure 32 Composite state machine #or State 2 !achine. And3 co!posite states allo4 eas2 specification of an event that goes to the sa!e state fro! all of the states in the co!posite state !achine. A co!posite state is one that is defined b2 another state !achine 4ithin the sa!e SA 5 file. In ;igure 31 and ;igure 323 State2 is a co!posite state. When event1 successfull2 occurs3 the state !achine for State2 4ill be started. This is %ust li/e a nor!al state !achinePit 4ill be created into the initial state ""nitialState2 in this e-a!ple# and 4ill auto!aticall2 transition to the ne-t state " State2a#. This state !achine is the sa!e as the non7co!posite state !achine e-cept for the follo4ing> A ter!inate state ter!inates not onl2 the co!posite state !achine but also the !ain state !achine. It acts as if the !ain state !achine transitioned to a final state. @ote that these are usuall2 onl2 used in co!posite state !achines3 since a final state should be used directl2 in a non7co!posite state !achine. Also3 a co!posite state !achine !a2 have co!posite states3 but no !atter ho4 !an2 co!posite states are involved a ter!inate state ter!inates the !ain state !achine. A successful transition to the final state "FinalState2# 4ill cause the transition sho4n directl2 belo4 State2 out of the co!posite state. This transition can include an action "92#3 but does not have a guard or event. @o !atter 4hich final state "in the co!posite state !achine# is reached3 this transition 4ill occur. This is called a default transition. @ote that an2 e-ceptions thro4n b2 this action "or an2 other that is not directl2 caused b2 an event# 4ill onl2 be logged and the transition 4ill continue. Jse of co!posite states also allo4s definition of events that can occur in an2 of the states of the co!posite state !achine. This is sho4n in b2 the transition for event- co!ing fro! State 2. This !eans that fro! an2 state in State 2 "State2a3 State2b3 or State2c#3 the occurrence of event- 4ill result in chec/ing guard condition g-3 and if successful3 the co!ponent 4ill invo/e action a- and change to State$. This is called an e-ception transition. As in J05 23 a transition fro! a nested state ta/es precedence over a transition fro! an enclosing state. In other 4ords3 in our e-a!ple3 if 4e 4ere to define an event- in our co!posite state !achine3 it 4ould be tried first before the event- 4ould be tried.
Page 3* of 55
@ote that a state !achine !ust have at least t4o states to be valid. It !ust have an initial state and one other state.
!7ample State 'achine

;igure 33 defines a practical e-a!ple relating to Order processing.
reated
(ead2
purchaseN needsApproval O C doApprovalAction purchaseN @ot@eedsApproval O C doShipAction InApproval
cancel
cancelCdo ancelAction approve C doShipAction ancelled Shipped event Ti!erN 1uration 1 0onth OC STi!er
order(eceived
1elivered event Ti!erN 1uration 2 0onths OC Sarchive ... archive archive Archived
Figure 33 Partial State 'achine #or an Order In this e-a!ple 4e start 4ith the initial state reated3 represented b2 a blac/ dot3 4hich creates the state !achine. This state is a pseudo state and auto!aticall2 transitions to the ne-t state3 (ead2. The (ead2 state accepts 2 events E purchase or cancel. The event purchase has 2 guard conditions E needsApproval and @ot@eedsApproval. There are no entr2 or e-it conditions for this state. ontinuing through the scenario3 4hen an order is placed< the order process transitions to the purchase process or cancel the order based on guard and event. When the purchase event occurs3 the guard condition is chec/ed. If the needsApproval guard condition is !et3 since there is no e-it condition3 the order !oves to the InApproval state. 5i/e4ise3 if the @ot@eedsApproval guard condition is !et3 since there is no e-it condition3 the order transitions to the Shipped state.
Page 35 of 55
At the InApproval state3 there can be a guard condition of cancel or approve. With approve3 the order transitions to the Shipped state since there is no e-it condition. At the ancelled state3 there is an event that specifies an event that should be fired after the state !achine has been in that state for a specified duration "a ti!eout#. The ancelled state specifies that after 1 !onth3 a Ti!er should be raised. At the Shipped state3 the order(eceived guard condition is chec/ed and the order !oves to the 1elivered state. Again3 there is another ti!er event that specifies that after 2 !onths3 the order is archived and the order transitions to the Archived state. Archived is a final state3 4hich is sho4n b2 a blac/ dot 4ith a circle around it. A final state ends the state !achine and !a2 not have an2 events leaving it. ,nding a state !achine does not delete it E it si!pl2 !eans that it no longer 4ill accept events and cannot !a/e an2 !ore transitions.
Business Rules
$usiness rules are a !eans of i!ple!enting and enforcing business polic2 through e-ternali9ation of business function. ,-ternali9ation enables the business rules to be !anaged independentl2 fro! other aspects of an application. This independence allo4s for d2na!ic updating capabilities of the business rules to provide for a !ore agile business. Often business anal2sts focus on business polic2 to describe guidelines that drive a business and can range fro! !ar/eting heuristics to accounting principles to govern!ent regulations to !anufacturing standards to suppl2 !anage!ent :ualit2 of service levels or to an2 other aspect of the business that relies on specific conventions. $usiness rules represent a co!!on 4a2 for i!ple!enting and enforcing these business policies. There are t4o st2les of business rules> IfCthen ruleset 1ecision table
$usiness rules are invo/ed through a $usiness (ule ?roup co!ponent. A $usiness (ule ?roup co!ponent provides the interface for the business rule. ,ach operation defines a business need and not a specific rule i!ple!entation. $usiness rules3 b2 their nature3 change over ti!e to support3 for e-a!ple3 changing business polic2 or changing govern!ent regulations. The abilit2 to schedule rules to be in effect during specific ti!e periods provides the fle-ibilit2 for an organi9ation to respond to changes. With the integrated effective dates3 the operation !a2 be i!ple!ented 4ith !ore than one business rule 4ith each i!ple!entation 4hich is effective for a specified period of ti!e. ,ffective dates allo4 a client application to invo/e the $usiness (ule ?roup co!ponent as if it 4ere a ti!e in the past3 present or future. $usiness rule authoring is supported via WebSphere Integration 1eveloper for the developer and a 4eb based tooling to support rule !anage!ent for the business anal2st. The business rule runti!e includes support for deplo2ing3 installing3 d2na!ic authoring and e-ecuting the business rules.
usiness Rule 4roups

$usiness rules are invo/ed through a $usiness (ule ?roup co!ponent3 never directl2. The $usiness (ule ?roup co!ponent can be invo/ed as a 4eb service3 thus providing the abilit2 for a service to be i!ple!ented as a business rule. The client application does not need to be concerned 4ith the i!ple!entation t2pe or 4hich i!ple!entation is used to process the re:uest. The client application si!pl2 interfaces 4ith the S A co!ponent t2pe to !eet a desired business need. This construct allo4s $usiness (ules to be encapsulated and invo/e as a service fro! other consu!ers. The $usiness (ule ?roup co!ponent is the artifact used to interface and invo/e rules. As !entioned above3 rulesets and decision tables "representing the t4o for!s of business rules supported 4ithin WebSphere Porcess Server# are never invo/ed directl2. The rule group co!ponent provides a !eans for the user to for! logical groupings of the business rules. The integrated effective dates allo4 the user to
Page 3& of 55
build one interface "co!ponent# for their logical rule group and associate one7to7!an2 i!ple!entations of a business rule 4ith each operation on the co!ponent. A rule group co!ponent is a uni:ue co!ponent and is an e-tension to the 6ava co!ponent /ind. The i!ple!entation t2pe is 6ava. A rule group co!ponent is co!prised of a set of operations 4here an operation represents a business need. Onl2 one business rule i!ple!entation can be effective at an2 point in ti!e. This functionalit2 is depicted in ;igure 3* belo4.
$usiness (ule ?roup o!ponent

calc+iscount1a Ab2 W start1ate )1C)1C)2 W end1ate W $usiness (ule )1C)1C)3 )1C)1C)* )1C)1C)5 lass@a!e W $usiness (ule D05 calc1iscv1.ruleset W calc1iscv2.ruleset W calc1iscv3.dtable W co!.-29. alc1iscv1.class co!.-29. alc1iscv2.class co!.-29. alc1iscv3.class )1C)1C)3 )1C)1C)* W start1ate calcShipping1s At2 )1C)1C)2 )1C)1C)3 )1C)1C)*
co!.-29. alc1iscX.class
init "para!s# TUV
fire "a 3b# TUV
lient
W end1ate W $usiness (ule )1C)1C)3 )1C)1C)* )1C)1C)5
lass@a!e W Para!sCSe:uence 1atainit W "para!s# TUV calcShipv1.dtable calcShipv2.dtable calcShipv3.dtable W W fire "s 3t# TUV W
co!.-29. alcShipX.class
co!.-29. alcShipv1.class co!.-29. alcShipv2.class ?enerated co!.-29. alcShipv3.class
incorrectl2 called AdaptiveInterface ,ntities on this ,ffective earl2 screen :ualities to the platfor!.Sphere business rule Instance data of service dates shot# to bring the highest Para!eteri9ed
for business rules to the 1efinition for rule Hinstances8 6ava i!ple!entation ed Adaptive ,ntities on this earl2 screen shot# to bring the highest :ualities of service platfor!.Sphere business rule classna!e
Figure 3$ usiness rule group diagram The $usiness (ule ?roup co!ponent provides the integrated abilit2 to select 4hich business rule i!ple!entation d2na!icall2 at runti!e based on dateCti!e. The business rule co!ponent selector function is currentl2 available for dateCti!e selection and 4ill onl2 invo/e business rules. If a user needs !ore selection functionalit2 for business rules3 a Selector can be i!ple!ented in front of the $usiness (ule ?roup co!ponent.
usiness Rule *ypes

!,then Ruleset
An ifCthen ruleset is a set of ifCthen state!ents or rules 4here the Hif8 is the condition and the Hthen8 is the action of the rule. ,ach condition declared in the ruleset is evaluated e-actl2 once se:uentiall2 in the order the rules 4ere declared. ;or each condition that tests true3 the action is Hfired8. This !a2 result in !ore than one action being fired b2 the ruleset. This is de!onstrated in the follo4ing e-a!ple>
Page 3' of 55
!7ample, 1in pseudo rule code2 -iscountRulesetO%ay # discount $ %.% && initiali'e return variable, essentially anot er rule (f purc ase.order )$ *%%.%% t en discount $ .%+ (f purc ase.order )$ +%%.%% t en discount $ .*% (f purc ase.order )$ *%%%.%% t en discount $ .,% ,-ecution results> *otal purchase price B C%0@00 Three rules evaluated3 no rules fired E result K ) *otal purchase price B C2%0@00 Three rules evaluated3 one rule fired E result K .)5 *otal purchase price B C)%0@00 Three rules evaluated3 t4o rules fired E result K .1) *otal purchase price B C1000@00 Three rules evaluated3 three rules fired E result K .2) IfCthen rulesets are best suited for those business rules that have si!ple condition clauses. ;or e-a!ple3 if the ruleset in the e-a!ple above needed to evaluate the custo!er classification "bron9e3 silver3 gold or platinu!# as 4ell as the total purchase price "as sho4n above# the nu!ber of ifCthen state!ents 4ould :uadruple. ,ach additional conditional clause added to the business rule can cause the nu!ber of ifCthen state!ents to gro4 e-ponentiall2. Writing !ulti7conditional ifCthen rulesets is ver2 cu!berso!e and difficult to !aintain. These t2pes of business rules are better suited to the decision table for!at.
-ecision "able
A decision table is a balanced tree visuali9ed in the authoring tools in table for!at. The table consists of conditional cases and actions. The conditional cases are represented in the ro4 and colu!n headings and the actions are represented as the intersection points of the conditional cases in the table. The evaluation of the conditions is done in a tree7li/e fashion 4ith the leaf node as the action. ,ach condition is evaluated once and not all conditions are evaluated on each re:uest. There is never !ore than one action Hfired8. This is de!onstrated in the follo4ing e-a!ple> !7ample, 1in pseudo table #orm2 usto!er.t2pe K $ron9e purchase.order Q 1)).)) purchase.order RK 1)).)) YY Q 5)).)) purchase.order RK 5)).)) YY Q 1))).)) purchase.order RK 1))).)) ) ) usto!er.t2pe K Silver ) .)5 usto!er.t2pe K ?old .)5 .1) usto!er.t2pe K Platinu! .1) .15
.)5
.1)
.15
.2)
.1)
.15
.2)
.25
Page 3+ of 55
,-ecution results> *otal purchase price B C%0@00A Customer B ron>e T4o conditions evaluated3 one rule fired E result K ) *otal purchase price B C2%0@00A Customer B Platinum Si- conditions evaluated3 one rule fired E result K .15 *otal purchase price B C)%0@00A Customer B Silver ;ive conditions evaluated3 one rule fired E result K .1) *otal purchase price B C1000@00A Customer B 4old Seven conditions evaluated3 one rule fired E result K .2) 1ecision tables are easier to use for describing business rules 4hen the rules have !ultiple conditions that need to be evaluated. In the e-a!ple above3 the conditional evaluation consists of total purchase a!ount and the custo!er classification. Adding another condition is done b2 si!pl2 adding another ro4 or colu!n. 1ecision tables can be n7di!ensional to handle co!ple- !ultiple condition re:uire!ents.
usiness Rule *emplates

Te!plates provide the !echanis! for supporting 4eb based rule authoring in the runti!e. The te!plates provide a constrained 4a2 of allo4ing the business anal2st to author rules in real ti!e on the application server. If a rule3 condition case or action is not characteri9ed as a rule te!plate then the business rule cannot be surfaced through the 4eb tooling for rule authoring. Te!plates allo4 application developers to> ontrol 4hich aspects "conditionsCactions# of a business rule can be !odified b2 the 4eb user 1efine constraints "i.e. valid discount range3 list of states in the JS3 goldCsilverCbron9e3 etc# 1efine the structure of an ifCthen rule 1efine the structure of a condition case andCor an action for a decision table 1efine a natural language AstringB that is used in the 4eb based tooling for presenting the rule to the business anal2st "/no4n as Web Presentation or WPT#
Te!plates are applicable to both ifCthen ruleset and decision table business rules.
usiness Rule ene#its

Si!ple business rules provide the user the abilit2 to capture their business function3 or polic23 in a si!ple JI based !anner. The si!plified JIs are designed to be used b2 IT developers as 4ell as b2 business anal2sts 4ho have li!ited technical s/ills. $2 providing the abilit2 to define business rules outside of the IT 4orld b2 the business anal2st3 WebSphere Process Server enables a custo!er to have a !ore agile business. @o longer does the business anal2st have to put forth their re:uire!ents to the IT depart!ent and then 4ait for the turnaround on the ne4 code or application. The business anal2st can !a/e the updates to the business rules the!selves against a runti!e s2ste!3 b2passing the IT depart!ent in accordance 4ith organi9ational governance policies and WPS7based authori9ation.
Page 3G of 55
'.
WebSphere Inte$ration (eveloper
WebSphere Integration 1eveloper v &.) provides tools for creation of business integration solutions that can be deplo2ed to the WebSphere Process Server. $ased on ,clipse 3.)3 it is delivered as a stand7alone I1, 4ith the AIntegration SpecialistB as target audience. Optionall23 it !a2 be installed as a plug7in on top of (ational Application 1eveloper.) 4ith the APo4er 1eveloperB as the target audience. Integration 1eveloper is a co!plete integration develop!ent environ!ent for those building integrated applications. To si!plif2 and accelerate the develop!ent of integrated applications3 this environ!ent provides a la2er of abstraction that separates the visuall27presented co!ponents 2ou 4or/ 4ith fro! the underl2ing i!ple!entation. The tools allo4 both a top7do4n design approach to building an integrated application3 4here the i!ple!entation for one or !ore co!ponents does not e-ist and is added later< or a botto!7up approach3 4here the co!ponents are alread2 i!ple!ented and the developer asse!bles the! b2 dragging and dropping the! in a visual editor and then creates a logical flo4 a!ongst the! b2 %oining the! 4ith lines. A debugging and test environ!ent !eans full testing before 2our applications are deplo2ed to a production server. Setting !onitoring points lets 2ou see ho4 an application is used in real ti!e in order to fine tune it for opti!al perfor!ance.
Standards
Applications created b2 WebSphere Integration 1eveloper confor! to industr274ide standards associated 4ith the Service Oriented Architecture. @o one 4ants to create applications that are tied to proprietar2 code3 4hich !a2 be unsupported in a fe4 2ears or involve costl2 licensing fees. Standards7based integration is therefore a funda!ental aspect of WebSphere Integration 1eveloper. ;or connectivit23 62,, onnector Architecture standards are used. ;or as2nchronous !essaging3 often used in large applications re:uiring guaranteed deliver2 of data3 the 6ava 0essage Service "60S# standard is used. WebSphere Integration 1eveloper can easil2 integrate Web services based on Si!ple Ob%ect Access Protocol "SOAP#. To describe a service3 the 4ell7 established Web Services 1escription 5anguage "WS15# standard is used. To define a business process the $usiness Process ,-ecution 5anguage "$P,5# standard is e!plo2ed. These standards7based interfaces and co!ponents co!prise an open7ended and pluggable architecture. Proprietar2 ele!ents3 ho4ever3 are not e-cluded< the2 are accessed through the use of standardi9ed interfaces. This !eans applications created in WebSphere Integration 1eveloper !a2 interact 4ith .@,T applications3 for e-a!ple. In the architecture section3 a lin/ is provided to the full Service o!ponent Architecture3 4hich provides an e-tensive list of the !an2 standards supported.
Roles
T4o t2pes of professionals need to collaborate to build co!plete integration solution> the Integration Specialist and a Po4er 1eveloper.
"ntegration Specialist
The AIntegration SpecialistB is the pri!ar2 personCrole that uses Integration 1eveloper. This person3 through the use of visual tools3 can build a co!ple- integrated application 4ithout e-tensive /no4ledge of the underl2ing i!ple!entation. Integration 1eveloper presents applications and business processes as co!ponents. The i!ple!entation of the co!ponents re!ains hidden and the co!ponents interoperate through interfaces. As a result3 the integration specialist does not need to have e-tensive /no4ledge of the underl2ing i!ple!entation of the
Page *) of 55
co!ponents to create an integrated application that uses the!. The integration specialist3 ho4ever3 li/el2 has a broad7based technical /no4ledge in the integration field in the areas of ,IS s2ste!s3 business processes3 and applications coded in 6ava or other languages. ;or e-a!ple3 an architect has a broad understanding of ho4 a s2ste! 4or/s 4ithout /no4ing 4hat each co!ponent does in detail. 5i/e an architect3 an integration specialist !ight be the person in an organi9ation 4ho designs the overall application and then has others 4ho code the i!ple!entation of the specific co!ponents.
Po(er +eveloper
While the Integration Specialist designs the overall application3 the Po4er 1eveloper i!ple!ents the specific co!ponents. To i!ple!ent Service o!ponents in either top7do4n or botto!7up fashion3 the Po4er 1eveloper t2picall2 has strong 62,, and Web Services s/ills. The pri!ar2 tools of the Po4er 1eveloper are (ational Application 1eveloper and WebSphere Integration 1eveloper.
"he 'rogramming #odel

The WebSphere Integration 1eveloper8s progra!!ing !odel is based on Service o!ponent Architecture. ;igure 35 sho4s a high level architecture vie4 of the S A fra!e4or/. A given co!ponent can use the interface of the co!ponent in 0odule A to instantiate the specific co!ponent. 0odule A has an i!plicit co!ponent "4hich could be a !ediation co!ponent# as 4ell as an S A interaction 4ith 0odule $ "4hich could be a .u!an Tas/ co!ponent# via a reference to the co!ponent in 0odule $. Additionall23 0odule A uses the interface to interact 4ith other services e.g. Web Services3 Adapters3 etc. The user of Integration 1eveloper !ust be fa!iliar 4ith the basic concepts of S A>
Figure 3% SCA Programming 'odel
SCA "erminology
Service Components
A service co!ponent configures a service i!ple!entation. A service co!ponent is presented in a bloc/ diagra! as is sho4n in an upco!ing section.
Service #odules
The building bloc/s of the business solution are service co!ponents 4ired together to for! Service 0odules that can be deplo2ed to the WebSphere $usiness Integration Server.
Page *1 of 55
nter!aces
Interfaces define ho4 to invo/e S A. The interface t2pe !a2 either WS15 or 6ava.
Re!erences
(eferences define the interfaces through 4hich one Service o!ponents directl2 of via I!ports. o!ponent AcallsB other Service
.ires
A 4ire in the general !odule asse!bl2 allo4s 2ou to asse!ble service co!ponents into an integrated application or solution b2 identif2ing target services. The target of a 4ire !ust support the interface that the source specifies.
Service /uali!iers
An application co!!unicates its :ualit2 of service "=oS# needs to a runti!e b2 specif2ing service :ualifiers. Service :ualifiers govern the interaction bet4een a service client and the service.
Service mplementation "ypes

A WebSphere Integration 1eveloper offers !ultiple i!ple!entation t2pes to fit developers8 varied conceptual !odels and to !atch the diverse /inds of tas/s perfor!ed b2 soft4are. Several standard service i!ple!entations supported in the Service o!ponent Architecture3 such as $P,5 processes3 ,nterprise Infor!ation S2ste!s ",IS# s2ste!s3 and hu!an tas/s3 are available.
mports
I!ports and e-ports define a service !odule8s e-ternal interfaces or access points. I!ports identif2 services outside of a !odule3 !a/ing the! callable fro! 4ithin the !odule
()ports
,-ports allo4 co!ponents to provide their services to e-ternal clients.
Binding
$indings are associated 4ith ,-port or I!port. ;or e-a!ple3 an I!port $inding describes the specific 4a2 the e-ternal service is bound into a !odule. There are various binding t2pes that allo4 2ou to i!port the different e-ternal service technologies3 e.g. ,6$3 Web Service3 ,IS Service3 and so on.
Building an Application
WebSphere Integration 1eveloper enables an Integration Specialist to build applications using top7do4n3 botto!7up and !eet7in7the7!iddle approaches. In this section3 4e use the top7do4n approach to illustrate the general pattern of ho4 2ou 4ould create an integrated application 4ith WebSphere Integration 1eveloper. Within the $usiness Integration perspective3 4e describe the process of setting up a pro%ect and then loo/ at the tools and artifacts created that contribute to the develop!ent3 testing and deplo2!ent of 2our integrated application.
usiness "ntegration perspective

The $usiness Integration perspective is the develop!ent environ!ent for an integrated application. Tools3 editors3 infor!ation and resources are logicall2 arranged for :uic/ access b2 the integration specialist
Page *2 of 55
Figure 3& WebSphere "ntegration +evelopment user inter#ace
Setting up a Solution
An integrated application is t2picall2 large and co!ple- as it reall2 is a set of applications and processes3 each of 4hich can be in itself significant in si9e and co!ple-it2. To !anage the co!ple-it23 modules are used to subset the application into a logical structure of containers3 4hich together for! a solution. A solution folder contains subfolders 4hich contain all progra!!ing ele!ents re:uired for a solution. Solution Folder Solution Asse!bl2 Contents
ontains !odules and 0ediation ele!ents. 0odules contain Service o!ponents. 0ediations contain !ediation ele!ents such as 0aps3 (elationships and 0ediation o!ponents. ontains co!ponents. o!ponents are divided b2 their i!ple!entation t2pes into subfolders> Processes "$P,5#3 $usiness State 0achines "incorrectl2 called Adaptive ,ntities on this earl2 screen shot#3 $usiness (ules3 .u!an Tas/s3 Selectors3 Session ,6$s and 6ava beans. ontains the $usiness Ob%ects used in the Solution. ontains the Interfaces used b2 the o!ponents that are contains in the Solutions.
$usiness 5ogic
$usiness Ob%ects Interfaces
Page *3 of 55
,nterprise Access
ontains ele!ents re:uired for accessing ,IS s2ste!s via 6 A protocol> ,-ports3 I!ports3 etc...
Creating and 'apping
usiness Ob/ects
In the top7do4n approach 4e first create $usiness Ob%ects. $usiness data is stored and passed to co!ponents in business ob-ects. The tool to create $usiness Ob%ects is the $usiness Ob%ect ,ditor and is sho4n in ;igure 3'.
Page ** of 55
"nherits
Contains
Contains array o#D
Figure 3) usiness Ob/ect editor An .pplication Specific /usiness 0b-ect "AS$O# is used 4hen the business ob%ect is related to a specific environ!ent. A 1eneric /usiness 0b-ect "?$O# is used to 4hen the business ob%ect has no specific environ!ent assigned to it. 0apping is used to derive an AS$O fro! a ?$O. 0apping business ob%ects is done through the $usiness Ob%ect 0ap ,ditor. The ter!s AS$O and ?$O are arbitrar2 ter!s and have not specific to the tooling. The ter!s are used to describe the t2pe of business ob%ects that are being created.
Creating "nter#aces
o!ponents have different internal i!ple!entations. So!e !a2 have a $P,5 process< so!e !a2 have a O$O5 progra! fro! an ,IS s2ste! li/e I S. reating an interface to a co!ponent offers a co!!on 4a2 to access it regardless of its internal i!ple!entation. Interfaces are created b2 the Interface ,ditor ";igure 3+#.
Page *5 of 55
Figure 3- "nter#ace editor
Creating and Wiring Components

o!ponents for! the building bloc/s of an integrated application. In the top7do4n approach use fro! the Asse!bl2 ,ditor to open a !odule and then and create ne4 e!pt2 o!ponents using the editor8s palette. ";igure 3G#
Figure 3. Assembly +iagram editor @e-t3 for each o!ponent 4e need to associate interfaces and references b2 pointing to the appropriate Interfaces are created b2 the Interface ,ditor. At this point3 for each o!ponent3 developers create and i!ple!entation. The i!ple!entation is selected fro! co!ponent8s pop7up !enu.
mplementing Components
Jsing the Asse!bl2 ,ditor 4e can create and e!pt2 o!ponent i!ple!entation. With the help of the various o!ponent editors 4e can create the o!ponent8s business logic.
"mporting Applications on !"S Systems

Accessing applications on ,nterprise Infor!ation S2ste!s ",IS# is a /e2 part of an integrated application. The Enterprise 2eta Data Discovery 4i9ard discovers ,IS s2ste!s and the applications on the! and can create co!ponents representing these applications. Once created3 the re!ote application on the ,IS s2ste! can be treated li/e a local co!ponent as seen in ;igure *).
Page *& of 55
"mport
Figure $0 Wor=ing (ith resource adapters
Speci#ying
usiness Rules
$usiness rules3 4hich offer different 4a2s of i!ple!enting business processes3 are specified through the $usiness (ules ,ditor. ;igure *1 sho4s the basic $usiness (ules editor.
usiness Ob/ect
"nter#ace
!"S "mport
Figure $1 usiness Rules editor
Speci#ying :uman *as=s

$usiness processes occasionall2 need intervention fro! people. As an e-a!ple3 intervention is needed to approve a loan in a ban/. These hu!an tas/s are specified 4ith the .u!an Tas/ ,ditor. (efer to the section on .u!an Tas/s for co!plete infor!ation. ;or reference3 ;igure *2 sho4s the .u!an Tas/ editor.
Page *' of 55
Figure $2 :uman *as= !ditor
Creating a Process
$uilding a business process3 4hich often is a co!ple- procedure3 is a /e2 function in an integrated application. $usiness processes are built 4ith the Process ,ditor3 4hich si!plifies business process creation through its visual presentation and user interface. ;igure *3 sho4s an e-a!ple of the $usiness Process editor. @otice the activities3 the connecting lines. Also note the partners "other services referenced# on the right side of the pallet. These are e-posed as references on the 4iring diagra!.
Page *+ of 55
Figure $3 usiness Process editor
Creating a State 'achine

So!e business services are best represented as state !achines3 4here the current state reveals 4hat has preceded it and 4hat still needs to be done. ;or e-a!ple3 a re:uest to bu2 shares !ight have states li/e approving the purchase and then getting the shares. The State 0achine ,ditor creates state !achines. ;igure ** sho4s the editor.
Figure $$ usiness State 'achine editor
Page *G of 55
Creating Selectors
Selector co!ponents deter!ine d2na!icall2 4hich i!ple!entation of a target destination to invo/e. The selection is dateCti!e based. Selector ,ditor is used to configure Selector co!ponents. ;igure *5 sho4s a si!ple e-a!ple that selects different 1iscount Services to use based on the ti!e of the 2ear.
Figure $% Selectors editor
Creating "nter#ace 'ediations

@ot all co!ponents can be connected easil2. Since internall2 co!ponents !a2 be :uite different 7 for e-a!ple3 one co!ponent !a2 be a $P,5 process and another a 6ava application 7 occasionall2 a 0ediation co!ponent is needed bet4een the! to resolve differences. 0ediation co!ponents are edited using the 0ediation ,ditor as sho4n in ;igure *&.
Page 5) of 55
Figure $& 'ediation editor Interface !ediations !a2 involve (elationships. To create and !anage relationships used in !ediations 4e use the (elationship ,ditor as sho4n in ;igure *'.
Page 51 of 55
Figure $- Relationship editor
-ebugging0 "esting and #onitoring

Integrated applications can be debugged and tested li/e other applications. Also3 events can be !onitored. In this section3 4e e-a!ine the tools to refine 2our integrated application.
+ebugging a SolutionA 'odule or Component

1ebugging can ta/e place at several levels of granularit2. Zou can debug the entire solution3 a !odule 4ithin it3 or co!ponent in the !odule using the 1ebugger. So!e of the debugging tooling for specific co!ponents is sho4n in ;igure *G.
Figure $. WebSphere "ntegration +eveloper Component +ebugging
Page 52 of 55
0odule testing is also enabled directl2 as is sho4n in ;igure 5).
*esting a SolutionA 'oduleA or Component

Testing3 li/e debugging3 can ta/e place at several levels of granularit2. Zou can test the entire solution3 a !odule 4ithin it3 or a co!ponent in the !odule using the Test ,nviron!ent. ;igure 5) sho4s the overall testing fra!e4or/ environ!ent.
Page 53 of 55
Figure %0 WebSphere "ntegration +eveloper *est !nvironment
'onitoring !vents
Properties on a co!ponent can be set to !onitor the co!ponent at run ti!e. ollecting data at run ti!e in this 4a2 can help fine tune an application. Additionall23 the WebSphere Process Server is full2 instru!ented for !onitoring. As an additional la2er3 the WebSphere $usiness 0onitor can be used to !onitor best IT and business relevant infor!ation.
+eploying an "ntegrated Application

Once 2ou8ve developed3 asse!bled3 debugged and tested 2our application3 it8s ti!e to finish 2our 4or/ b2 deplo2ing the application to 2our production environ!ent using the deployment tools. Since 2ou built3 asse!bled and tested 2our application at the co!ponent level3 2ou also deplo2 at a higher level. The deplo2!ent tools let 2ou deplo2 2our solution si!pl2 and easil23 handling the lo47level pac/aging of the artifacts for 2ou.
Page 5* of 55
S &&ar)
In su!!ar23 process integration enables the design3 develop!ent3 and !anage!ent of operational business processes. 0ore i!portantl23 successful process integration results in a highl2 fle-ible integration architecture and opti!al2 are built on a Service Oriented Architecture to support loose coupling and fle-ibilit2. The /e2 for process integration is to enable tight lin/age bet4een business and technical co!!unities to ensure faster ti!e to !ar/et for business7driven IT solutions. In the past3 highl2 s/illed 62,, developers 4ere !andator2 for building integration solutions. Although products clai!ed to support a full range of integration3 the abilit2 to have a single tool to support integration 4as a drea!. WebSphere Process Server provides a co!plete co!ponent7based solution as part of the !ar/etIs broadest reaching SOA7based integration solution. Through the functional convergence of I$0Is historical integration solutions on a Service7Oriented solution fra!e4or/3 I$0 is the first vendor to offer an integration solution that provides business processing3 business state !achines3 business rules3 hu!an tas/ !anage!ent support and advanced !ediation capabilities n a single solution based on the !ar/et leading !essaging and application services. ,:uall2 i!portant3 I$0 has provided a tooling solution that allo4s for the develop!ent of si!ple to co!ple- integration solutions 4ithout re:uiring roc/et scientist caliber soft4are developers. WebSphere Integration 1eveloper enables developers to be highl2 productive through an eas2 to use ,clipse7based 4i9ard7oriented develop!ent platfor!. WebSphere Integration 1eveloper is based on (ational Application 1eveloper and provides e-tensive 4i9ards to develop and asse!ble integration co!ponents to rapidl2 develop integration solutions. The I$@0 Soft4are 1evelop!ent Platfor! provides 4ith the abilit2 to directl2 use WebSphere Integration 1eveloper via the (ational Application 1eveloper v&.) The /e2 to the WebSphere for Process Integration solution is the co!!on data representation enabled via the $usiness Ob%ect !odel and an open standards7based invocation !ethod to enable the rapid develop!ent of end7to7end integration solutions. This foundation provides the SOA basis for the I$0 solution for process integration. With WebSphere for Process Integration3 organi9ations can finall2 develop and !anage process integration solutions 4ith a single co!prehensive platfor! solution and developers can benefit 4ith an SOA7based approach for architecting3 creating and deplo2ing integration solutions 4ith higher speed and co!ponent :ualit2 than has been possible in the past.
Page 55 of 55

WPS V6 Technical Overview V1-3-SMS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

WPS V6 Technical Overview V1-3-SMS

Transféré par

Droits d'auteur :

Formats disponibles

WebSphere Process Server 6.0 Technical Overview Version 1.

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

Service Oriented "rchitect re Core

Service o!ponent Architecture

o!!on ,vent Infrastructure

Figure 2 SOA Core

Service Component Architecture (SCA)

WebSphere Process Server Technical Introduction

SCA and Business Objects (BOs)

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

Common !vent "n#rastructure

Event Source Submi t Complete

Store Event Data

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

$usiness Ob%ect 0aps

Figure & 'editation Flo( in WebSphere Process Server

WebSphere Process Server Technical Introduction

ridging incompatible inter#aces

WebSphere Process Server Technical Introduction

updateOrderStatus"Order order3 String status# Figure - "nter#ace 'ediation

retrieve"Order# retrieve"Order# Order0anager Interface 0ediator fetch"SAPOrder#

Figure . 'ediation component interposed

usiness Ob/ect *rans#ormation

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

AS O ",-. SAP usto!er3 SAPOrder# 'ediation Component

4 O ",-. usto!er3 Order# Process 31 Process 31 Process 31

4 O ",-. usto!er3 Order# Process 31 Process 32 Process 35 'ediation Component

AS O ",-. SAP usto!er3 SAPOrder#

Figure 12 +ata 'ap

Relationship #anagement$ dentity Relationship management and loo%ups

WebSphere Process Server Technical Introduction

,IS1 ust Ora ust

,IS2 ust SAP ust

'ediation Component 31 !"S Adapter

Selectors$ Routing Business &ogic

WebSphere Process Server Technical Introduction

12na!icall2 choose 4hich destination to invo/e

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

$usiness $usiness Processes Processes

.u!an .u!an Tas/s Tas/s

$usiness $usiness State State 0achines 0achines

$usiness $usiness (ules (ules

WebSphere Process Server Technical Introduction

WebSphere Process Server Technical Introduction

;ault handlers for advanced internal process error handling

usiness Process Features

P!9 !vent :andlers

P!9 Compensation :andlers

WebSphere Process Server Technical Introduction

Business 'rocess ()amples

usiness "ntegration Server Foundation !7ample

Business Process WS Export BO BO

usiness "ntegration Server Foundation usiness Process !7ample

WebSphere "nterchange Server !7ample

WebSphere Process Server Technical Introduction

Adapter ASBO Mediation GBO

Business Process GBO

uman "as%s (+*)

Figure 2& as= state8transition diagram #or a p8 and has=