How, what, when and why SOA?

After taking part in a recent discussion on SOA, I would like to say that SOA doesn't answer the questions How, What or even When in terms of use, but do answer the question Why.

How?
There is a misunderstanding that SOA has something to do with how people should implement their services or group them in types of service behaviors. SOA makes no difference between services implementing master-data, processes, use-cases, entities, identities, rules, or legacy adapters nor does it care. To SOA a service is just a service.

What?
SOA doesn't require a specific message-passing technology but Web Services is preferred for obvious reasons.

When?
SOA is not suitable in all situations - but that isn't up to SOA to decide. The answer here is dependent upon the how and the what described above.

Why?
SOA answer the why-question with - to achieve business agility. Not by how services are implemented or with what technology is used, but with service management - the things that happens between the 2 service endpoints during a call. Things like versioning, routing, filtering, virtualization, en/decryption, en/decoding, monitoring, transformation, logging, translation, billing, validation, etc - all packaged in a nice runtime governance tool.

Why patterns?!

Why can't you find a polymorphic pattern for OOD? Because it's so obvious!

Polymorphism is part of the paradigm and part of the oo-languages. It's not obvious how to use polymorphism, but there are no patterns describing it. Design patterns seems to concern ideas not really aimed for a specific software paradigm. I been thinking why patterns play such an important role today. It's just my believe that where ever there is a pattern, there is a shortcoming in the underlying paradigm/languages to solve a specific problem. I'm joining in criticism of patterns.

Cutting slices from a blob

I liked the way Mats Helander described service-orientation. To understand the good thing about SOA you really need to see it from the business perspective. From a 10000' view, IT really looks like a big blob. On a 1000' view, you can discern smaller blobs which are applications (aka black boxes or silos). The SOA will help breaking up the applications in small services that can be composed into new services based on policies. The selection for how the services will be used in a composition is up to the heart of the SOA - the mediation layer. The mediation layer (such as WCF or Synapse) will make sure that the policies are applied correctly.

Some people claims that service composition (orchestration) is part of the SOA paradigm. I would rather give credit to BPM for techniques related to service composition.

A Business-Oriented Architecture

While some people keep fighting for their knowledge domain, the world change around them. I'm talking about program languages, design tools and runtime engines, still using object-orientation as a model for implementing a business critical system. Since the early 90th object-oriented architectures have been the main technology platform for building solutions for business. What we got with us from those years is that technology driven view point of software development is bad. Whether an object-centric perspective helped the programmers understand the business or not isn't relevant. What we do know is that noone else understood the object model. Lot of initiatives have tried to bridge between the business and the OO model. Most of them have just made it worse, with really high cost as a result for software development.

No, there's a need for a new, better model for designing software. Something that the business can relate to, something that everyone can relate to. Processes and services are keys to this new model. We have all heard all the great stuff we can do with SOA and BPM, but what are the differences and can they play together?



A process-oriented architecture (POA) fits a company that's frequently changing and improving their business processes. This architecture supports a process improvement life cycle where bottle necks and bad design are found and adjusted using analyzis tools. A POA is a platform using a transparent model for business processes that aligns the business with IT very well.

A service-oriented architecture (SOA) on the other hand suites a company reorganizing their business structure frequently (such as out-sourcing, mergers and acquisitions, internal reorginization, etc). The main goal with a SOA is to control the services based on policies. These policies are defined in the service management framework. A SOA gives the agility in a business where services easily can be controlled from using service governance. A SOA will provide the virtual service mediation layer between the service consumer and the service producer where loosely coupling is crucial.

Normally a company would agree that both transparency and agility is important for their business. The only way to achieve this is by taking the road from OOA to a business-oriented architecture (BOA). This is a platform where the best from BPM and SOA is combined. People from the BPM community call this platform BPM 2.0, while some call it SOA 2.0. I think something neutral as BOA is more diplomatic.

The next question would be to ask which way is more natural to go from OOA to BOA, the red or the blue road. I would say the red because SOA is the foundation for a successfull POA.

Good Webinar on SAP Netweaver

Check out this webinar on SAP Netweaver and listen to Amberpoint about their service management tools.

Microsoft readings in SOA/BPM space

Here is a number of papers from Microsoft, relating to service-orientation.

BPEL & Humans

BPEL is said to be designed for orchestration of web services. Some say BPEL is competent and suitable for business process implementations, but not for human workflows. I've also read that BPEL lacks in the way it orchestrates human interaction with business processes. I think one should separate those two scenarios from each other since they will have different impact on the critisism.

First, BPEL cannot describe a human workflow and I don't agree. A business process contains a flow with several descions on the way forward. A human workflow is the same where the flow is central, except that humans makes the descisions them self (in their head based on facts in that very moment). A business process will make a descision based on predefined rules. Where a BPEL process goes to a Rules Engine to make descision for a business process, a human workflow asks a human. The human is responding through web services.

Secondly, BPEL cannot communicate with humans. BPEL use partner links for inter communication, where a partner link is pointing out a web service endpoint. Yes, it's an endpoint and not a human, but behind the endpoint there can be a human. Some say humans are resource when someone asks for a role. The same thing can be said about web services. A web service interface is a role, where the running instance is the resource. Allocation of resources is handled by resource management tools in the same way as SOA tools handles service management.

I'm sorry, I can't see why humans are different when it comes to processes and services.

Meta-applications

A classic application is like a black box of functionality which can be accessed and used by opaque interfaces. What's happening inside the application is not your business, but it guarantees the job will be done. A classic application is building trust by taking care of your data as long as you don't mess with how it's getting done.

In a service oriented world where services are used and reused as building blocks, the black box is gone. A SOA is transparent and built up of composite services. A SOA consists of meta-applications which consists of services. A meta-application is a set of services using the same policies as a trust boundary. With service governance the trust of meta-applications will be as high as for classic applications, or will it not?

Programmer, take control over your process!

Think about the code you are writing for a second. Where do you implement the business process? First of all, let's define a business process.



Figure 1: Process flow is like a pipeline controlling access to the business objects over time.

A business process controls the state of a business object over time. Think of a process as a pipeline controlling incoming and outgoing messages, from and to the process flow. Only predetermined access is allowed to change the state of the business objects. This is just like normal code execution. No one except the programmer can control the flow of the execution for a specific program.

puts("Enter your age:");
gets(age);
if (age>30)
 printf("Welcome! Enter your name please:");
else
 printf("Yo! What's your name?:");
gets(name);
printf("Hello, %s", name);

In the code above the flow defines how we are handle the dialog with the outside world in C, just like a pipeline. No one can change this flow after it's deployed. This code is totally in control over the state change of the dialog. Eventhough a modern programmer writes code in this way, the general business application never controls the business objects. Why is that?

System design as it is practiced today, business processes are everywhere and anywhere. They are implemented in the database as triggers/SPs, in windows services, in web applications, in desktop apps and in middleware. The processes is not centric (like the C code) and cannot be controlled and managed in a centralized manner.

The reason for scattered process definitions or no process definition at all is deeply rooted in the programmers mind. He takes control over his execution flow, but doesn't take control and responsibility for the business flow. Instead of taking control over the business flow, the business objects are open for arbitrary access and state modification over time. A programmer's way of thinking is related to not understanding the business' needs, but also in the lack of tools and languages for writing process-centric applications.

Controlling the business process will result in a new way of designing applications. Start now, take control over your processes!

CentraSite™ Community

"CentraSite Community is your community portal for all things SOA -- research, whitepapers, best practices, news, and opinion from the best and brightest in the SOA community."