Archive for the ‘SOA’ Category

Maintaining Service Orientation: Core Concepts

Tuesday, May 13th, 2008

I have received the question What is SOA? many times and I soon realized that a comprehensive answer to this question is not easy. Rather than searching a definition or offering a simplified answer, I decided to follow a different approach here. My plan here is to raise the level of abstraction slightly and describe a set of concepts and their relationships inside and outside of service orientation.
Concepts in service orientation
SOA Core ConceptsThe three core concepts of service orientation are depicted on the diagram together with other IT architecture and IT system concepts and their relationships.

  • Service categorization helps to distinguish between the different types, classes and forms of services.
  • Service life cycle describes what happens to the service during its lifetime
  • Service information model provides the meta-model for describing a service

Once these concepts are hardened – based on the architectural decisions – there could be many variations depending on the relationships defined between them. There could be many categories for a service. There could be many life cycles defined for the different categories of services. There could be many service information models to describe the different services. During the realization of these concepts the number of instances are defined. These numbers for each concept can vary between many and one, a variations of these describe different cases, where some may make sense, some may not.

Variations of service orientation concept realization
Having a single category only makes really sense when all the other concepts are also singular, all the other combinations are valid, for example: L categories, M life cycles, N information models; or L categories, M life cycles, 1 information model.

Service orientation guided by architcetural decisions

The three service orientation concepts are guided by a set of architectural decisions. Besides the determining the relationship between concepts, architectural decisions also determine the behavior of the concepts and their instances. For example as the service description changes – using the service information model as the template – it may trigger a change in the category of the service and a technical service may become a business service as new business relevant attributes are defined. Continuing this example, the change in category may dictate to change the applicable service life cycle applicable to this new category of service.
In other words, the architectural decisions also have define how the applying one instance of a concept will affect the application of other concepts to an instance of a service.

IT solution guided by the same architectural decisions
The IT solution, as a response to the business requrements, consists of three domains: design, implementation and operation. These domains are also interrelated:

  • design guides implementation, where implementation may influence the design;
  • design may guide operation, and operation will influence the design;
  • implementation is then handed over to operation, where operation may influence the implementation.

They are also guided by the same architectural decisions guiding sevice orientation, in addition to other achitectural decisions.

More service orientation related concepts…
As you may have noticed, many other service orientation related concepts are not even mentioned here, for example: services governance, business services, and so on. These concepts are not missing the model described here have not been extended that far to include them yet.

  • The services governance may extend on any or all of the core concepts, for example: defining the details of service life cycle.
  • Business services, which could be a category, may have a specific form of service description reflected in the service information model.

A simple realization of service concepts
The following example is a possible realization of the case where every concept has a single instance. The instances are also mapped to a possible implementation.
1 service category: Web services
1 service information model: WSDL
1 service life cycle: JEE Web application life cycle: build, assemble, deploy, run

What Service Oriented Architecture has to do with Newton’s apple?

Monday, November 19th, 2007

When looking for an explanation for SOA, the typical findings would include: architectural style , architectural approach. Sometimes the explanation may not elevate further than a buzz-word stuffed marketing statement.How about…

Newton’s apple Take mathematics, physics, or whatever science is closer to your heart as an engineer. Let’s look at how these disciplines described, modelled the world around us. Let’s take math (algebra) as an example…
…first we had integers to model numbers; then came zero and the negative numbers; later fractions and real numbers; complex numbers and so on.
Same evolution has happened to geometry as we learned to understand space and dimensions. Physics thought us about falling apples and a bit later about the quantum mechanics. Equally similar was geography where the world started flat and now it is an ever expanding universe of galaxies in a big boom.

So what is Service Oriented Architecture then?

It is a model for architectures, or it could be a meta-model if architectures had a proper notation for modelling.

Every single case when the model describing the world around us evolved there was something that had to be considered, there was a new aspect from which the world seemed flat again. As the models evolved they also had to ensure compatibility more-or-less with previous models; while pushing the boundary of understanding further and further.

It is quite similar with [IT] architectures. They describe, model a solution using our best knowledge and understanding of the domain.
Today we have arrived to Service Oriented Architectures, it is another step in evolution of describing and modeling IT solutions. It deals with some of the concerns more accurately, for example: business-IT alignment, loose couling, reuse, governance, and so on. It is also true that SOA may not be needed for an architecture, just like no need for complex numbers to count apples.

Is it the end of the evolution? Is SOA the perfect model? Far from it… These days, some of the concerns, decisions and their complex relationships are better understood than others. As the world moves together with our understanding of it, more complex requirements, concers and decisions emerge and they demand a new model, a new architceture.

Math still has problems that cannot be solved in the current models; physics is pushing the boundary to understand the smallest, astronomy is pushing to understand the largest thing there is.

Is this too academic?

Yes, at the moment it is, but it is a start. More details to come…