SOA in PracticeThe Art of Distributed System Design

Book Author: Nicolai M. JosuttisChapter Nine: SOA in Context

IT-Slideshares http://it-slideshares.blogspot.com/

Contents9.0 Purposes Of This Chapter9.1 SOA Based Architecture9.2 Dealing with Frontends and Backends9.3 Summary

9.0 Purposes of This ChapterSo 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.

9.1 SOA-Based Architecture ModelsDiagram 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.

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

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.

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.

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.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.

9.2 Dealing with FEs and BEsThis section will discuss some special aspects of

integrating SOA with frontends and back-ends.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.