Note the message request and response functionality generic
format that is used for each activity step.
Planning Service-Oriented Transactions 295
getQuoteReq(tickerParamIn.string)
Account
Balance
Atomic
Service
ORC
getQuoteRes(quoteParamOut.string)
Market
Quotes
Atomic
Service
1
2
EXHIBIT 14.13 FUNCTIONALITY NOTATION EXAMPLE
PLANNING SERVICE-ORIENTED TRANSACTIONS
The time has come to plan transactions. Obviously, the two design diagrams delivered so far??”the
design relationship and the logical design composition??”are the fundamental logical units that
can be leveraged now to construct the service-oriented transaction diagram (discussed in detail
in Chapters 12 and 13). All the facilitating ingredients are in place. Modeling service-oriented
transactions is simply a matter of orchestrating and choreographing the activities the must come
to pass to provide solutions. Indeed, there are a growing number of vendors that offer orchestration
and choreography tools to accomplish this task. Still, the transaction diagram must be the
fundamental logical design blueprint to guide this process.
What should be the essential approach to planning service interaction and collaboration?
How should we strategize service-oriented transactions? After having defined the rudimentary
relationship between participating services and consumers and having already identified message
exchange paths, the process is well underway.
Pages:
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512