Lecture 9 - SOA in Context

1. Book Author: Nicolai M. Josuttis
Chapter Nine: SOA in Context
IT-Slideshares http://it-slideshares.blogspot.com/

2. Contents
9.0 Purposes Of This Chapter
9.1 SOA Based Architecture
9.2 Dealing with Frontends and Backends
9.3 Summary

3. 9.0 Purposes of This Chapter
 So far , we have explored the concepts of Service-Oriented Architecture
and examined the organizational consequences of implementing SOA.
 However , in practice SOA is only one aspect of the overall architecture
of a system landscape.
 SOA has to do with how systems communicate to perform distributed
processes.
 Those distributed processes are initiated by frontends or batch
processes and store their data in back-ends , and the ways SOA
organizes the communication has an impact on both the frontends and
the back-ends.
 This chapter will situate SOA in the context of the global picture of
SOA-based system landscapes.
 We’ll begin by examining different ways of modeling a SOA-based
architecture.
 We’ll discuss topics such as work sharing between SOA and frontends
, and specific questions regarding connectivity to back-ends.

4. 9.1 SOA-Based Architecture Models
 Diagram of a SOA-based system landscape may look
very different , depending on the illustrator’s intention
and point of view.
 Such illustrations may focus on business, domain
logical, or technical aspects of the language.

5. 9.1.1 Logical Architecture Models
 An architecture model focusing on the business or logical aspects of a
system landscape might look like Figure 9.1

6. 9.1.1 Logical Architecture Models
 Inside your landscape you have different domains , which play specific roles and
have specific responsibilities.
 A domain usually is something you can identify in your organizational structure, and the
important point is that it should be a “natural” entity with clear responsibilities.
 E.g : a company, a division, a business unit, a department , or a team.
 A backend in this model represents the technical system and its associated data and
capabilities, for which the domain is responsible.
 It can be a single system, a collection of different systems, or even a component of a system shared with other
domains.
 Basic services are provided by specific domains.
 Figure 9.1 shows three types of them : reading and writing services, and rule services.
 This services wrap the technical details of the backend.
 Composed and process services , in contrast , won’t necessarily belongs to a single
“natural” domain, because they often combine functionality from different domains. Who
is responsible for such services?
 Have a cross-domain department that handles these issues.
 Need some way to assign cross-domain services to specific domains.
 Note : there can also be hierarchies of domains , making the rules governing
responsibilities more complicated.
 SOA is a concept that support heterogeneity, including in organizational structures
 Be careful about making too many rules.

7. 9.1.2 Mixed Architecture Models
 A slightly more technical view of the landscape introduced in the previous section might
look like figure 9.2
 In this figure , you can see both logical and technical aspects of the architecture . It
contains the following new aspects:
 All service calls are now shown as being routed through an ESB.
 Process services might be implemented (and managed) by BPM engine or tool.
 All basic logic services providing business rules are implemented in a rules engine.

8. 9.1.3 Technical Architecture Models
 An even more technically driven view might look like Figure 9.3
 The technical aspects of the system landscape dominate.
 The ESB in the center.
 Domain provide only basic data services and composed services.
 Basic login services and process services are separated.

9. 9.1.4 Choosing the Right Architecture Model
 How to deal with process and rule services is a central question, there are a few
points to consider.
 On the one hand , a domain should be responsible for all its business login.
 It should control not only basic reading and writing services but also basic logic services , and process
services if this make sense from a business point of view.
 On the other hand, having a common BPM tool and engine and/or a common rules engine
managed by one team helps to get synergy effects for tools and allows there to be one
common view for all processes and business rules.
 Tool vendors tend to prefer the technical model, because it allows them to bundle
together thing you can buy.
 Using good tools, you should easily get an overview of all your services, business rules, and
business processes both at design and at runtime.
 SOA and large systems are designed to allow heterogeneity.
 E.g : BPEL has limitation , you may find that you have to implement some process services
in an ordinary programming language such as Java.
 Be wary of falling into the trap of requiring homogeneity even when the price is too
high.
 There is a difference between commonality and centralization.
 If commonality leads to centralization , your system will no longer scale.

10. 9.2 Dealing with FEs and BEs
 This section will discuss some special aspects of integrating
SOA with frontends and back-ends.

11. 9.2.1 Roles and Responsibilities
 Services in SOA are interfaces for B2B scenarios.
 These scenarios are organized such a way that a system or component communicates
from time to time with another system to read or write some data.
 Between these service calls , the service consumer uses its business logic to perform
its task.
 A frontend that acts as a service consumer to some extend controls the overall
behavior .
 In SOA , a service serves the consumer, it doesn’t control it. This even applies to
process services.
 Process services usually do not allow human interaction.
 This lead to a specific programming model for the frontends.
 If frontends just present backend data.
 They just call basic reading services , according to user input.
 If the end user wants to modify backend data, things get more complicated.
 Guide end user by offering only valid options and checking input early.

12. 9.2.1 Roles and Responsibilities (Cont)
 Start collecting user data while using basic services to limit or validate user input (Figure 9.4)
 The former would typically be basic reading services.
 The later would be basic logic services (rule services).
 Note :
 Should not validate each input field by calling a services.
 Have some stable business rules redundantly implemented in the frontend instead of calling a service for each validation.

13. 9.2.1 Roles and Responsibilities
 Figure 9.5 show an example of calling a process service that uses composed and
basic services to perform a modification on multiple back-ends.

14. 9.2.1 Roles and Responsibilities
 Note that if a problem occurs you can’t interact with the user.
 You can’t send request to the frontend.
 The frontend might even have terminated or ended the session.
 If you need some interaction all you can do is bring the process into a condition that
regularly checked by some monitor, systems, or users.
 Example : In a back office agent intervening to continue a process that has been stopped
(See Figure 9.6).

15. 9.2.2 Multiplayer Validation
 You can use the following basic validation/pre-validation policies
 Validate in back-end
 Validate in frontend.
 Redundancy
 Central decision point
 In practice , validation usually involves a mixture of these approaches .
 You have to deal with the fact that things will go wrong, and provide appropriate processes
to deal with this.
 The aim of pre-validation should be to ensure that process services will “usually” succeed.
 Be wary of expending a disproportionate amount of effort on pre-validation.
 In practice , there should be a central place for business rules that change
frequently. E.g
 Such rules might apply to pricing models, product portfolios, contract types, and so on.
 But having a central service to check whether a date or a salutation is valid and calling it
for each input is probably not appropriate.
 You will have to determine the right validation policies and the right amount of
validation for your concrete SOA and SOA-based solution.

16. 9.2.3 Multi-frontend channel Scenarios
 It’s common for distributed systems to require support for a multichannel, E.g :
 A customer might start a business process (such as an order) using an online portal , and
continue it via a call center . Likewise, processes started by a call center application might
be processed by the back office and monitored by the customer using a portal.
 To support this , instead of managing each channel ‘s process independently , you
must be able to switch between different frontend channels.
 This keeps the processes consistent.
 In practice , this means that the process engines must provide abilities to find and
identify running processes.
 Different frontend channels used different search criteria , just as they used
different views to manage the data. E.g :
 One frontend might start a process for a customer identified by a contract number, while
another channel used the customer number.
 A third channel might use the address of the customer to find the running process
 A solution would probably be for the process engine to get the task not only of
processing services but also of making them searchable by enriching them with all
the useful search criteria.

17. 9.2.4 Multiple-application Frontends
 Another common scenario is that different frontends running on the same system
or desktop need the same data provided by a service.
 Consider a desktop where you have multiple clients with graphical user interfaces dealing
with the same customer.
 You start with one frontend, which loads the customer data by calling an appropriate
service provided by the CRM department.
 Now say you need the same customer data in another frontend.
 The second frontend would need to call the same service to retrieve the customer data.
 This would be a waste of resources because the data is already on the desktop.
 The alternative is to enable direct or indirect local communication between the two
frontends :
 Direct data exchange would mean that both frontends establish and manage a
communication layer to exchange the data.
 This approach has nothing to do with SOA.
 Indirect data exchange would mean that there is some “magic” that knows that the
customer data was loaded by one frontend and can be used by the other frontend.
 This approach does and might be supported by your infrastructure (ESB).
 Both scenarios usually require some kind of local communication.
 You should usually start with both frontends calling the same service to load the
customer data and see whether this approach causes any problems.

18. 9.2.5 Future Management
 Another interesting aspect of business processes dealing with multiple back-ends which call
“future management”.
 Describe Scenario :
 If a customer calls in to change a contract or change an address , this change won’t necessarily
become valid immediately.
 That is, customers and business processes as a whole might define modification that should
happen later, a certain point in time.
 How do you deal with future modification?
 Arrange future management in such a way that the back-ends can deal with tasks that have to
processed in the future.
 Make future management part of your process management.
 It is usually better to make future management part of your process management.
 You might or might not choose to make it a responsibility of the usually process engine.
 In the later case , your process engine will still be responsible for :
 Running process directly.
 Putting processes for later processing into the system management future tasks.
 Processing those tasks when the system managing future tasks indicates that they should be run.
 Such a separation between one tool or system running the actual tasks and another tool
managing future tasks might help to separate concerns . But , of course , managing actual and
future tasks together might also be possible and have some advantages.

19. 9.3 Summary
 There are different models for structuring description of SOA-bases system
landscapes.
 While some prefer the logical view
 Others focus more on technical aspects.
 For the successful management of SOA landscapes , a logical or domain-driven
general view considering the technical aspect as “implementation details”
provides better scalability and is better able to deal with heterogeneity.
 Process services are backend processes, which usually provide no means of
direct communication with the end user.
 For this reason, frontends dealing with use cases that lead to backend modifications
have to use the pattern of collecting the data for the changes interactively while
performing the changes without interaction.
 To minimize the danger of process services running into failures, frontends can
prevalidate user input according to the actual situation and business rules.

20. 9.3 Summary (Cont)
 There are different ways to validate business rules and input data for
business functionality.
 Usually, the backend should validate everything, and the frontend should
try to ensure that the common scenarios run smoothly. Validating in both
the frontend and the backend can be implemented redundantly or via
common services.
 For multifrontend-channel scenarios, you have to deal with the fact
that processes initiated by one channel must be researchable by other
channels.
 When dealing with multiple clients on the same desktop, you might
want to avoid each client calling the same services. You might do this
using local communication and/or local caches.
 You have to think about how to deal with future tasks. You may choose
to give backends specific abilities to deal with future tasks, or designate
a special place where future tasks are managed.