How to implement identity based Service Access Control in SOA

Identity

In consequence of the growing openness of IT-infrastructure (Internet, SaaS, public services, remote access, Web 2.0), security based on fortresses (isolated environments) is becoming less adequate. Secondly there is an awareness that security incidents are not only caused from outside these isolated environments, but also from inside such an environment. These aspects together with the introduction of compliancy regulations (be able to quickly proof who did what and when, on penalty of legal sanctions) a trend is recognized toward identity management based security mechanisms. These mechanisms are based on the idea that all components in an IT-environment (people, devices, software) that can act more or less autonomous have an identity. Access to resources is controlled at the resource-level and is based on the identity credentials of the user of that resource.

Service Access

This pattern describes an identity based solution for protecting services against undesired use. Without protection every arbitrary service can call any other arbitrary service. This raises risks with regard to intended and unintended violations of the system. Also with regard to compliancy regulations (knowing who did what and when) such a situation is undesirable. These risks are present even in a fire-wall secured environment.

Arbitrary Service Access

Controlled Service Access

The solution described in this pattern assumes the availability of a security infrastructure based on identity management.

When a service is called by a caller (service access) the identity credentials of the caller are added to the message. The called service can only be accessed via a proxy (security proxy). This proxy will validate the access rights of the caller based on the credentials passed in the message and the defined access policies before passing the message to the called service. In case of a synchronous communication implementation the identity credentials of the called services are added to the reply to allow the caller to validate the integrity of the reply.

This model supports authentication and authorization of service calls:

• Identity Credentials: proof that a service is who it claims to be (authentication)
• Policies: managing what service may be called by whom (authorization)

SAML (Security Assertion Markup Language, XML standard by OASIS) may be used to pass credentials in a secured way.

Secured Service Access

By establishing trust relations with external companies, secured service access can be offered to external or federated parties without the need to maintain the external identities; only the (e.g. role based) policies have to be maintained (relying on the adequate role allocation by the trusted party).

Identity Credentials Propagation Trail

The service-access and security-proxy combinations can be chained together. This allows for complex access policies based on a complete chain of identity credentials. For example:

• If D is called by C and C was called by A: access allowed
  
• If D is called by C and C was called by B: access denied

The figure below illustrates this pattern.

Credentials Propagation Trail

Anti-pattern: security-agent nested in the service

There are products available that offer comparable solutions where a security agent is built into the service in stead of using an external security proxy. Such a solution may be qualified as an anti-pattern. Mixing up security components with the service components decreases flexibility and increases vendor lock-ins. An infrastructure based on embedded agents leads to a load of extra efforts to change the services when you want to choose another vendor in future; proxies can easily be replaced without any effect on the services.

Anti-pattern

Identity Credentials in Business Events

Beside passing identity credentials to services (SOA), identity credentials can also be added to published business events (EDA). This allows for the consumer of the message to validate the identity of the source of the message. A trail of identity credentials may be added to the published messages in a process flow to allow for determination of the process flow route, based on the identities of the services in the flow. The figure below illustrates the pattern of identity credentials in a business event.

Identity Credentials contained in a Business Event

ESB: Service Bus or Data Bus?

The ESB is a lot about messaging and therefore a better name perhaps would be "Enterprise Data Bus". It's the asynchronous messaging that needs such an infrastructure with persistency- and mediation facilities. All the WS-* standards are about messaging as well, leveraging the message itself to tell the infrastructure how the message has to be handled (see this). I think WS-* will make it possible to have the ESB evolve from a vendor-product to a concept implemented in the operating systems and network devices that understand WS-*. Then you can leave the prefix "Enterprise" and we will be ready for an universal asynchronous data bus over the Internet (or any other network you like). This will help breaking the current "services centric" idea of SOA into a "messages centric" perspective.

How to implement a loosely coupled process flow (EDA)

A process flow contains subsequent activities or steps. These may be manual or automated activities. In most cases an instance of a process flow uses a persistent document that holds the state of that process instance. This document contains data to be queried.

Figure 1 shows services 1 till 4 representing subsequent steps in a process flow. “Dossier” represents the collection of persistent documents holding the process states. Service X detects the state of the flow and updates the dossier.

Figure 1: Process flow based on business events

Services that represent the flow are independent of the dossier

In this pattern a service (representing a business activity) results in a business event. The business event triggers the next service in the sequence by means of a subscription of this subsequent service to this event. Every step in the flow delivers (messages about) event types. All services in the flow are completely autonomous (stateless) in relation to one another and to the dossier. I.e. every service can complete its task fully based on the data stored in the message (modeled business event) it is subscribed to. Services 1 till 4 do not query the persistent dossier in behalf of the process flow; perhaps they do query the dossier for other reasons, but in essence they are completely decoupled from the dossier and they don’t need to know about the existence of the dossier.

The dossier persists in behalf of services that have an interest in the current state or historical states of the process. In general these will be other services than those forming the process flow.

Full contained messages

For example (see figure 1), to have service 3 perform its task, the message about event 2 will contain the full context of event 2. This may (and mostly will) mean that the data of event 2 will contain a lot of the data of event 1. This mechanism allows for connecting new services to the flow, without these services having any knowledge of the other services in the flow nor any knowledge of the persistent dossier.

Separate topic for every business event

So the messages about the different event types within one process flow may look much alike. They even may be identical, but it concerns different business event types and so have different semantics in the flow. That is why they always will be designed as separate message types (topics) and not as one message type with a status code plumbed into it.

Anti-pattern

Using such a status code must be regarded as an anti-pattern. In such a solution, the service should subscribe based on the value of a artificial added field in the content of the message. This implies knowledge of the existence, values, semantics and format of this field when subscribing services to business events and also when building the publishing services. This increases complexity and decreases robustness of the system.

By distinguishing different event types, even if their contents and formats are equal, no specific semantic nor syntactic knowledge about the content of the message is needed to subscribe services to events.

Declarative process definition

A loosely coupled process flow as clarified in this pattern allows for declarative process definitions. The process flow is defined by first defining the subsequent business events and then defining which services consume and publish these events. A strong system design contains declarative descriptions of all the process flows within the system. Figure 2 shows an example of the process flow as depicted in figure 1.

Figure 2: Declarative definition of process flow

Conditional branches in the flow (see figure 3), like If-then-else or Do-case constructs, are implemented by content based subscriptions. These conditions are formal decisions based on business rules where these business rules may be very complex constructs. (here I enter the domain of my friend James Taylor)

Figure 3: Branches in the process flow

The conditions are not defined within the services, but outside the services. This allows for easy changes by reconfiguring the publish-and-subscribe mechanism without modifications to the service-implementations. The services will be more robust by retaining their pure functions.

Figures 4 and 5 illustrate how to add additional business rules to the process flow.

Figure 4: Declarative definition of branches in the process flow

The process definition makes use of the results of the applied business rules which are defined separately from the process flow definition.

Figure 5: Defining conditions based on business rules

Implementation by a notification server

One might think of a notification server to trigger services by events at run time. The conditions are the result of business rules-based filters on the published events that the notification servers evaluates to trigger the correct services. So the notification server should have access to a repository that holds the declarative process definitions and a repository that holds the business rules.

One might also think of the implementation of service X and the persistent dossier (see figure 1) by the notification server. If the notification server logs all events and the repositories hold history logs of the process definitions and business rules, it will be possible to derive all process states and decisions for any moment in time from these three sources. This construction can support very rich business intelligence.

Why?

This pattern makes it easy to implement process flows by declarative configurations and to change the flows on an ad hoc basis, also by configuration.

Because the process flow is defined in terms of publish/subscribe and autonomous stateless services, it becomes easy to add, change and remove steps and branches in a plug-and-play alike way, without breaking the system.

Based on this pattern, complex processes can be accomplished that - despite their complexity - are yet easy to change.

Things you always wanted to know about EDA

Great video presentation in which Ian Cartwright presents some of his work (developed with Martin Fowler) on Event Patterns.

If you want to get a grip on EDA, then watch this video. Ian explains some interesting patterns, which may open your eyes.

Really, really good stuff!!

There is no one-size-fits-all approach to SOA

Are you seeking for that one most suitable approach to SOA? An approach that covers all your needs, respecting (the lack of) your company's IT governance, the (im)maturity of the IT staf, your heterogenous application landscape, the (lack of) innovation forces (including budget)? You won't find it.

Some projects will focus on new software for old processes, and others on new processes with old software. Or both new processes and new software (lucky you!). Or old processes with old software (bug fixing, poor you!). And then there are proprietary SAP-solutions and eSOA-based SAP-solutions and combinations of proprietary and eSOA-based SAP-solutions. Some ownerships are crystal clear, others are political disasters. Managers may not support innovation, looking forward to the bottle of champagne at the date of the deadline. Others don't like champagne, but may or may not be very stubborn on architectures they are not educated in to understand. Developers may or may not be averse to things that are new to them. Every project has its own context characteristics with regard to people, knowledge, motivation, business and technology. Not all projects are ready for new things; if you have bad luck, MOST projects are not ready.

And all of this within one single company or even worse: within one big project. So, no, you won't find that ultimate SOA approach of which the guru's let you know to put all the right things in place as a prerequisite to the success of SOA. You just can't get all the right things in place. That's not our world and will never be our world. We will have to deal with chaos. Also when in comes to SOA approaches. Take it or leave it.

But what can you do to succeed in SOA? Well, my suggestion is:

Stop trying to convince averse project teams and averse or cynical managers of the benifits of SOA. But look for curious innovative managers with charisma and seek to empower your project teams with passionated new age developers; no matter the technological or business context. And then start doing the things you think (know) you should do with an approach that fits the project context. That's how to step-by-step contribute to SOA in the context of chaos. And you don't even have to mention the word SOA. It's the teams respected - and trusted - craftsmanship, that leads to SOA and to the company's SOA-heroes of the future.

Zachmann versus Zachman

Quoted from Zachmann (beware!):

• SOA is a plausibly good and sometimes even useful idea that has been blown far out of proportion by various parties with their own axes to grind.

And this:

• By all means, include real SOA in your range of options. If you get the chance, enjoy the cocktails and the golf! Don't, however, let yourself be beguiled into believing that it's really anything different from what you can already do quite well using Web services with .NET. It most certainly is not.

And what about this one (for heaven's sake!):

• SOA simply means designing application systems that create and access local or network services

Okay, fair enough, he is right in: The basic architectural ideas date back to the '60s.

But thank goodness it is not Zachman with single N, author of The Zachman Framework for Enterprise Architecture, but Zachmann with double N who wrote the rest of this joke equating SOA with .NET web services.

In one of my previous postings I concluded that developers - in general - don't get the clue of SOA... See what I mean?

Canonical Model, Canonical Schema, and Event Driven SOA

Nick Malik just posted a great article on the importance of:

• Enterprise Canonical Data Model
• Canonical Message Schema
• Event Driven Architecture
• Business Event Ontology

This is the first article I came across explaining the need for a canonical data model and the event-driven mind-set. It strongly relates to my own posting a couple of weeks ago. But I don't even come near the talented way Nick knows how to explain this subject.

My advise is: don't even think about doing SOA without fully understanding Nick's article.

Great Nick, you have all my credits.

The magical A of SOA and EDA

We are all talking about SOA and EDA, trying to explain what services are and – a bit less intensive – what events are. But what is the A in SOA and EDA? What is architecture at all?

There are formal definitions (IEEE 1471 for software architecture) and less formal definitions of architecture. Many books and articles are written about the subject architecture.

In my lingo architecture means "purposeful composition". This implies:

• Components
• Separation
• Arrangement
• Connections
• Purpose
  

It doesn't say anything of domains. It can be about a piece of music, electronic circuits, buildings, IT, organizations, landscapes. Everywhere you recognize structures of distinct components that are determined, distinguished and arranged based on predefined (concurrent) purposes I mention it architecture. So the structure of a tree has no architecture (not based on predefined purpose), but the structure of a garden has. The architecture of a building recognizes spaces as components and combines purposes with regard to function, aesthetics, safety, maintainability, adaptability and cost. Purposes put constraints on the architecture and may be conflicting. It is the architects job to balance between conflicting purposes. The less conflicting purposes there are, the more freedom the architect - as the conceptual arranger of components - has. In arts purposes are often limited to not much more than aesthetics and triggering emotion,(triggering emotion sometimes is the only purpose), which gives the artist, being the architect of the work of art, very much freedom. Like purposes put constraints on architecture, architectures put constraints on development. See also this nice posting.

The enterprise may be your scope of the architecture with regard to SOA and EDA. But be careful with enterprise level IT architecture. The enterprise IT is fading into a bigger global IT in the context of Internet, SaaS, Service Orientation, outsourcing, off-shoring, and so on. All kids in the street are participating with their own LEGO blocks to build your castle.

One of the purposes of IT architecture at the enterprise level is the ability to follow changes in the context. Not only in the business context, but also in the technology context. So the components must be defined and connected in a way that makes it possible to deconnect them and reconnect them in other arrangements and other contexts. This puts constraints on the components and here is where autonomy based on strong cohesion and loose coupling comes in place.

SOA is an architectural style the recognizes services (functionality representing process steps) as components. EDA is an architectural style that recognizes events (messages representing process states) as components. Both styles focus magically on the same architecture from an inverse viewpoint. The components in EDA are strongly related to the component connections in SOA; events connect services by transferring process state from one service that detects and publishes events to other services that are triggered by specific events. On the other hand the components of SOA are strongly related to the component connections in EDA; services connect events by transferring the process from one state to another; a service triggered by an event may cause a new event bringing the process in a subsequent state. The two main purposes of both SOA and EDA are (among others):

• Support ease in rearranging the components (commonly known as the LEGO metaphor)
• Support concurrent use of components in different contexts (commonly known as "reuse")

Note that these purposes are commonly accepted with regard to services, but at this moment in time hardly mentioned in the context of messages (representing events). As it is desirable that events can trigger multiple unrelated services in concurrency which can be changed by configuration on the fly, these purposes are also applicable to messages.

SOA prescribes constraints on the services to fulfill these purposes (autonomy, strong cohesion, statelessness). EDA prescribes constraints on the messages to fulfill these purposes (loose coupling, canonical messages with self contained context). SOA can hold synchronous patterns as well as asynchronous patterns. As EDA prescribes an asynchronous pattern, EDA not only puts constraints on the messages, but on the interacting services as well (publish/subscribe, deliver and consume full contained messages). Note that in consequence EDA puts constraints on SOA, but SOA not on EDA. From this perspective EDA might be seen as of a higher architectural magnitude then SOA.

This does not improve business processes themselves, but it improves support for adaptability of business processes; so it also supports changing lousy processes from bad to worse. Ultimately business processes may be changed without any IT changes.

It is like painting a GUI-screen where the buttons, entry-fields and display-fields may be reshuffled over and over again to the most ugly and poor screen design, without breaking the under laying functional support. Just as easy as that.

Why is screen-printing so easy?

• Because functionality of the screen objects is based on stateless autonomous functions (reusable in different context)
• Because interaction between the screen objects is based on self contained messages representing the state of the screen (button_pressed, mouse_clicked, field_entered)
• Because the screen objects are configurable by the user to the user’s needs and wishes (color, position, size, values)

If you are a daredevil you possibly have the courage to say that SOA and EDA make the enterprise level application landscape, painted on the companies screen canvas much like modern GUI-development tools.

I think I am a daredevil...!

SOA is not Business Agility but offers Business Agility

Is it the task of the CIO or any other IT-guy to convince the business people the "service orient" their processes? I don't think so. I think it is the task of IT-folks to organise and architect IT in such a way that it can quickly follow changes in the business context, or even better: to be agnostic for changes in the business context. It is the responsibility of business people to optimize their processes and organisation structures with the freedom for whatever reason not to do so.

I think, from an IT point of view, that SOA should offer agility to the business. Business must be able to change without headaches about IT. I think a well designed SOA even supports a badly structured organisation and clumsy business processes. That is the power of SOA, IMHO.

SOA This. SOA That.

No Comment...

How to implement Business Activity Monitoring in an SOA

This pattern describes how business activity monitoring (BAM) can easily be implemented in the context of SOA using EDA. It is about the monitoring of "business" activities, which is not the same as "system" activity monitoring as Mark Palmer explains in his BAM Myth #2: "The problem is, it's not easy to put a system monitor on the IT infrastructure and gain business insight from technical activity." Of course system activity monitoring can (and will) be based on the same kind of pattern, but that's not what I focus on in this post.

Essence of this pattern is that services that deliver data to be monitored are decoupled from the monitoring functionality. The responsibility of the services is limited to publishing the relevant data. In a well designed loosely coupled system, this data will probably already be available as in such a design autonomous services exchange business events in a formal format to establish process flows. The services do not have any knowledge of the (existence) of the monitoring functionality. You might say in a correctly designed EDA based system, a properly configured business activity monitor can be plugged-in on the fly.

The monitor consists in its simplest form of event processing components and a dashboard for publishing alerts as depicted in the figure above.

• Event correlation: correlate desperate event types and their occurrences based on configurable rules concerning value-ranges, comparisons and time-frames.
  

• Event processing: additional processing to enrich the data delivered by the event messages.

Depending on your preference you might say that event correlation is a form of event processing. I purposely distinguish between the two because of the special time-frame based nature of event correlation in the domain of Complex Event Processing (CEP), whereas I position event processing as - more or less - straight away algorithm processing.

The event processor publishes alert events based on the correlation and processing results. A monitor dashboard subscribes to these event types and prepares them for publishing via a portal.

This is a very simplified representation of BAM functionality. BAM tools may offer extended functionality like persistency, analyzing, replay, multi-channel presentation, etc. Reporting via a dashboard is only one of the possibilities to present alerts. Custom services, email services or datawarehouses may also gain benefits of the published alert events; plug-and-play. An alert event is a special type of business event.

Example

A service in an ordering process publishes a message about the event of a customer placing an order. It is the company's policy to deliver within two days after ordering. If the delivery is delayed, the customer gets a discount of 10%. The idea behind this policy is that no customers will be lost after a delivery delay; some customers will even prefer a delay.

To monitor this process the "order placed" event is correlated with the "order delivered" event, which comes from a service at the expedition department (or an external company in case of outsourced expedition services). The occurrences of both event types are correlated based on the ordernumber. If an "order delivered" event is not detected within two days after an "order placed" event, an alert event is generated. A service of the financial department is subscribed to these event types. This service initiates a rebate for the concerning customer. Also a dashboard of the expedition department is subscribed to these event types to notify the employee on duty of the delay in order to have him take action and notify the customer. (A phone call is more customer-intimate then a generated email.)

It is easy (and better) to reconfigure the two-day time-frame in this example to an one-day time-frame and take corrective actions before the delay occurs.

This simplified example shows to power of events based systems in combination with CEP and BAM. Mature CEP and BAM tools are available on the market, but for an experienced development department it is no big deal to home-build this kind of functionality for systems that at this level of abstraction are based on EDA.

Why?

• This pattern decouples the process flow from the monitoring functionality. By using this mechanism the process flow as well as the monitoring functionality can be changed independently, without affecting each other.
  

• By using this mechanism the monitoring functionality does not influence the performance of the business process in any way.
  

• By using currently available standards based CEP and BAM products a uniform generic facility can be implemented, which reduces costs and maintenance in comparison to proprietary and/or more tightly coupled system specific monitoring solutions.

The two worlds of SOA

Nick Malik posted a reaction on the idea that entity services are anti-patterns. I agree with his conclusion that it depends on where you stand.

Looking from the business side, there is the composition of business activities into autonomous business functions. These functions offer services to each other and communicate - preferably - events based to obtain their autonomy. Such a business service could easily be outsourced without any disruption of the overall business process. Such a business service can also easily be delivered (shared) to different business contexts (internal or external). I call this the Service Oriented Enterprise. This has nothing to do with IT.

On the other hand there is the composition of application constructs. The top level of such a construct preferably maps with an autonomous business function. Current standards based technologies make it possible for IT to support events based interaction between the autonomous business functions, which in turn boosts the Service Oriented Enterprise.

The idea (or pattern, if you like) of autonomous business functions can be prolongated into the finer grained application constructs which may e.g. lead to autonomous entity services or deeper layers of granularity.

See also:

• How EDA extends SOA and why it is important

• Granularity of Services

So: No, entity services are not an anti-pattern.

Business doesn't ask for SOA

Testimony from practice: Up till now, at this very moment in time, I didn't meet one single business manager who begged me to please deliver him an SOA-based solution. They are running after deadlines and project-cost reductions, but not after SOA. They are even cynical about SOA as being yet another promise after all those previous ones. Of course all those previous promises were a step ahead, just as SOA is. And I believe SOA is a big step ahead. But our business people don't want SOA's, they want flexible and cheap solutions. And they want I.T. not to be a big hurdle when they change the way they happen to do things. But they definitely did not ask me for an SOA.

And another testimony from practice: Developers - in general - don't get the clue of SOA. The marketeers of most software companies evangelize their ability to build service oriented systems. But the people who really have to deal with the details are not educated to get a grip on the practical use of the principles of autonomous business functions, loose coupling and asynchronous design. They are trained to use the modelling tools of Websphere, Sonic and Tibco, but SOA is not their mind-set. It's the individual passionated nerds we have to rely on, not the average developer or designer.

But fortunately I can also testify about curious development teams that are slowly adopting the new wave. Development teams that operate very close to the business in a very rapidly ever changing commercial context. These are the people I enjoy working with.

And another good sign is that the builders of packaged software - like SAP - not only evangelize SOA, but are really spending big efforts to service enable their legacy. Also the SOA initiatives of SaaS-providers like SalesForce are a great boost.

All together I believe it will take at least another 10 years or so before SOA becomes mainstream and common sense to all of us. And keep in mind that we are not hired to deliver SOA's to the business, but solutions. That's what they ask for.

Do we understand SOA?

I came across this posting of Galen Gruman, contributing editor at InfoWorld. He cites Roberto Medrano, executive vice president of SOA Software:

• "Maybe 20 percent of IT folks understand SOA and half of the rest think they do"

He might be right. Perhaps we currently understand that breaking down your business activity into a business component model of autonomous business functions is key to SOA. It is a lot less common thinking to loosely connect these autonomous business functions, events based. I tried to clarify this aspect in SOA Magazine.

And then there is the widely spread misuse of some core terminology. "Experts" tend to speak of "reusable" services. But what they mean is "shareable" services, which is quite a different thing. It makes sense to focus on shareable messages and not only on shareable services. Did you ever hear somebody talk about "shareable messages", typically representing business events? I didn't, while the use of shareable messages really is the key to success. It's shared messages that make the innovation, not shared services.

And what about the idea of loose coupling related to SOA? I quote: "Shared services are disruptive, increasing dependencies and raising questions about what it means to own a service and who should own it." From a lower level IT-perspective this is such a very truth! However it doesn't seem to bother most of our "experts". Not to mention how and why exactly to "share" a service, if a service equates to a properly designed autonomous business function.

How to implement loosely coupled transaction processing

This pattern describes how to accomplish transaction processing within the context of autonomous services. The pattern is based on the idea that - by design - every action has a compensating action to undo the original action.

The autonomous services fulfill action requests from the transaction controller (see "1" in figure). If one or more services reply not to have been able to fulfill the request (see "2" in figure, fault feedback) then the transaction controller will send requests for compensating actions to the services that did fulfill the original requests (see "3" in figure).

The concerning services do not distinguish between a normal action and a compensating action. To the services compensating actions are normal actions like any other. The services are not even aware of being part of a transaction.

Examples

• A service is designed to make, change and cancel reservations for hotel rooms. These are three equivalent types of actions. In the context of compensating actions, a cancellation can be considered a compensation for making a reservation. This compensating action results in undoing the original make reservation action.
  

• A service is designed to increase or decrease the balance of an account. These are two equivalent actions. Both can be seen however as compensating actions for each other (mutual com-pensating actions). An action that increases the balance with 100 euros can be compensated with an action the decreases the balance with 10 euros.

It need not only be fault feedbacks that lead to compensation. The transaction controller may make use of a timer to detect if an acknowledgement has been received within a preset time-frame. If one of the services doesn’t respond with this preset time-frame, requests for compensating actions will be sent to the other services. If a service sends the acknowledgement after the preset time elapsed and compensation action requests have been sent to the other services, this late service will be sent a compensating action request as well. Or one might choose to resend the original action requests to the other services if that is appropriate.

Design considerations

The designer of the transaction system must for every action always design a compensating action. This is not trivial. Consider the second of the above mentioned examples. Suppose the service was not developed to increase or decrease an amount, but to replace the old amount with a new one. Compensation would then not be possible. If the action would replace the old amount with a new amount of 10 euros, this can not be reverted without endanger the integrity of the data. Not even if the transaction controller would be aware of the old amount (or if the old amount would have been returned to the transaction controller). Other amount changes (triggered by other sources) may have occurred after the replacement transaction has been executed. If afterwards a compensating action would replace the amount back to the original amount, the amount would be corrupted.

Why?

In situations where by nature the transaction processing cycle is long (minutes, hours, days, weeks, …) the described pattern of loosely coupled transaction processing allows for an adequate alternative to the well known two-phase-commit mechanism. Also in loosely coupled of decoupled environments (B2B) where minimal dependency (maximal autonomy) is pursued, this pattern offers a more appropriate solution then two-phase-commit.

Traditionally transaction systems use the two-phase-commit mechanism. All participating software components must support and adhere to this mechanism. All components reply whether or not they can honour the request of the transaction controller and - if so - retain the action until a commit- or rollback command has been received. A commit command is issued by the transaction controller as soon as all concerning components have replied that they made their preparations and are ready to commit. If one or more of the components deny the request, the transaction controller will send a roll-back command to the other components in order to allow them to release their retention state.

Because after a commit command the participating components must actual perform the action if they replied to be ready to commit, these components must - awaiting the commit - place locks on the data that is involved in the transaction. This puts a claim on the performance of the system. Such a mechanism is therefore only appropriate for (very) short running processes where a participating component can rely on the performance of the other participating components and on the performance of transaction controller.

If the processing time to complete the transaction takes relatively a long period of time, the inherent locking strategy of the two-phase-commit mechanism is not appropriate because it can hang the complete system. Also in loosely coupled of decoupled environments such as B2B the two-phase-commit mechanism puts undesirable dependencies on the environment and the proposed loosely coupled transaction processing will be more appropriate.

Rambling thoughts of an architect

Quoted from Martin Fowler:

Complexity

• Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes a system hard to change.

Limitations

• Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”

Know any similar wisdoms? Please drop them here...

How to mediate semantics in an EDA

Sharing semantics

Systems that pass data to each other share commonly understood semantics. Explicit data semantics is the key to success in an EDA (and any other messaging system). In striving for loose coupling, data semantics is the ultimate level; when systems are decoupled at the semantic level - e.g. they don't share semantics - the coupling becomes useless, because in this case the systems will not be able to communicate at a logical level. Shared semantics is a prerequisite in connecting distinct systems, no matter whether it concerns EDA, SOA or any other form of EAI (Enterprise Application Integration). It should be obvious to anyone that analysis of data semantics will always be the first activity of any integration project.

In contrast to sharing semantics, distinct systems do not share formats that express these semantics. Think of different date formats or amounts (semantics: balance on a bank account) expressed in different currencies. Or think of different identifiers: CustomerName versus Custnm. The same semantics is expressed in different formats.

Mechanisms must be in place to harmonize between these different formats that carry semantically the same data from one environment to another environment. This pattern describes such a mechanism based on intermediate canonical formats for semantics representation.

Canonical Data Model (CDM)

In an EDA a business event is represented in a canonical format (presentation) with unambiguous semantics. This format and semantics are defined as canonical message types in the enterprise's Canonical Data Model. These messages are the core of the event-driven architecture and are valuable business assets that must be treated as such with regard to protection.

A message type may be invoked by several source systems in several environments. Several target systems in several environments may consume the same message. The environments that send and receive these messages don't need to know the canonical format. Every environment communicates in its own local format with the messaging system (typical the Global Dataspace implemented by an Enterprise Service Bus). A prerequisite is that every concerning environment has defined their local data formats and semantics in the CDM. The messaging system will provide services to transform the local format to the canonical format and vice versa. These services depend on the CDM.

There will always be a transformation from the local format at the sending side to the canonical format and there will always be a transformation from the canonical format to the local format at the receiving side. Even if the local format is identical to the canonical format a transformation will still be implemented. Such a null-transformation makes the mechanism generic and more agile when changes occur.

At design time, the definition of format transformation is not the only thing that must be accomplished. First of all correctly mapping the corresponding semantics from the local formats to the canonical formats is of utmost importance. Format transformation is the second step. Semantics mapping is vital to the success of the system, so in consequence defining semantics and recording these descriptions in the CDM is not an option, but a must if you want to succeed with EDA, SOA or EAI.

CDM, no commonly used datamodel

The CDM is not a storage component, but a metadata component. The CDM holds definitions of the local formats and semantics of the participating systems and the CDM holds the definitions of the canonical formats and semantics. There is not any persistent processing data in local or canonical format stored in the CDM. Also the CDM doesn't provide a common datamodel that everyone has to adhere to. Such a common model is no longer appropriate since we buy systems from the marketplace with their own datamodels and since we connect many systems from a variety of environments, old and new, sometimes in a B2B context or inherited from merging with other companies, each with their own datamodels, formats and semantics. The pattern described here, doesn't bother the systems owners with constraints on datamodels, formats and semantics. Everybody can use their own models, formats an semantics. Transformation services support the transformations of the shared semantics to and from canonical formats, using the definitions in the CDM. The sending and receiving systems are completely unaware of this; they talk in their own language.

Enrichment and translation algorithms may be part of the transformation services. This applies to different data representations with the same semantics, but it also applies to conversions of different but deducible semantics.

Example of data representation transformation

Two systems share the semantics for "railway station"; they both interpret the meaning of this entity type in the same way: a railway station involves a location and platforms and is owned by Dutch Railways; the rails are not part of it. However, one system uses alphabetic characters to identify a railway station. The other system uses numeric characters to identify the same set of railway stations. So one system identifies railway station Oudenbosch by "A" and the other system by "01". The canonical format uses even another set of identifying characters: alphanumeric. The transformation services must have knowledge of all railway station identifying sets and how they correlate. A persistent data set (e.g. a database) lies at the basis of the resolving algorithm of the transformation service.

In practise the case of this example may be rather complicated; think of how to keep the intermediate data set up-to-date if the connected systems may autonomously add new railway stations (or worse: change the railway station id's).

On the other hand there are also very easy translations, like translations of date formats or miles versus kilometer translations.

Note that all of these data representation translations can be bi-directional.

Example of correlating semantics conversion

In some cases it is possible to convert one semantics to another. Of course this is only possible if one semantics embodies the other one in some deducible way. Let's look at a strongly simplified example of a purchase order.

The canonical format of a purchase order consists of an order number with a set of order lines each with a part number, a quantity and the price of the concerning part on that line. The consuming system understands a purchase order as an order number and a total order amount. The transformation service multiplies the quantities by the prices and summarizes the resulting amounts.

You might argue that this example doesn't mention two semantics, but a different representation of only one semantics. You are right, it is ambiguous. On the other hand, the canonical format holds more data of the order than the consuming system does. So how can the semantics be same?

This is a simple example. In practise you may come across very complicated situations, where multiple complex data structures and complex algorithms are involved.

Note that the conversion can only take place into one direction.

Why?

• Using canonical message types decouples systems at the level of message formats. Systems don't have to make assumptions or have to rely on other system's data formats. This is an important aspect in striving for loose coupling.
  

• Defining canonical message formats creates the opportunity to supply the company with an unambiguous catalog of available messages about business events, representing valuable business assets. The business events in this catalog are independent from the sources that generate these messages. Based on this catalog policies can be implemented with regard to ownership and degree of free availability of data that is exchanged between domains. New business models may pop up with regard to data exchange. The catalog may contain rates associated with messages about business events. Publishing data about business events may be marketed: suppliers get paid for the published data by consumers. The IT-department delivers the market place (infrastructure) an may play a role as business events broker.
  

• In a technical sense this pattern has a benefit in that at the endpoints only one transformation service per message type has to be configured. A subscriber needs to subscribe to only one message type, regardless whether there are multiple sources or not.
  

• If transformations would take place directly between local formats (skipping the intermediate canonical format), transformation services have to be created for every source-target combination. This would lead to higher loads of management and maintenance efforts. Consumers would have to subscribe separately to every source of a particular message type and should in consequence have knowledge of the existence of these distinct sources.
  

• Without intermediate canonical format a format change at the publishers side must be followed by changing all the transformations to the subscribers. Using an intermediate canonical format makes the transformations to the subscribers independent of changes at the publishers side.
  

• Without canonical formats for semantics representation semantics would be represented in multiple equivalent formats. This obstructs the possibility to supply the company with an unambiguous catalog of business events independent from their sources. Also the lack of canonical formats will consequently cause system designs and resulting systems to be more complex and harder to change.

How to implement service versioning in an SOA

In this pattern every versioned service has a proxy. There is one proxy for the whole collection of versions per service. The proxy decides which version of the service must be accessed.

This is accomplished by use of a version identifier in the SOAP-message. This version identifier identifies the version of the WSDL document that the calling component used to call the service. There is always a WSDL document for every service version. At design-time the concerning version of the WSDL document must be known, because the program code of the calling component must be aligned with this particular WSDL. The version identifier of the WSDL document in use at design time is added to the SOAP-message.

The services are registered in a registry. For every version of the service the registry holds the version identifier of the corresponding WSDL document. In addition, for each registration of a version of a service the registry holds a backward compatiblity list; with every newly registered version of a service a list of compatible earlier versions is registered. Backward compatibility means that a version of a service can be called by components that were built with earlier WSDL versions.

The proxy queries the registry with the version identifier from the SOAP-message and looks for the highest operational version of the concerning service that is compatible with the version identifier from the SOAP-message. Once the correct version of the service is determined the proxy passes the message to that determined version of the service.

In case of a component calling a service using an old version identifier of which no compatible service versions are operational anymore (e.g. after end-of-life of a service version) an adequate error message may be returned by the proxy to the calling component.

The specific versions of the services to which the proxy passes the messages are identified by their URI (URN and/or URL).

Why?

Support of multiple concurrent operational versions of a service leads to more flexible and robust systems. Separating the callable service name (represented by the proxy) from its version identifier has advantages:

• Calling components automatically make use of the highest available compatible version of the service on the fly without any modification.

• Multiple incompatible versions of a service may exist concurrently without any effect on the calling components.
  

• New versions of a service can easily be tested in a production environment, without disturbing the current version. After approval just add the backward compatibility list for this version to the registry and all compatible calls are directed instantly to the new version.
  

• Superfluous versions - versions of which higher compatible versions are available - won't be called anymore and can be removed without any modifications to the calling components.
  

• The process needs not be aborted to pass control to the infrastructure layer if an old version identifier is detected that is not supported anymore by an operational service. If desired control can be maintained at the application level where an appropriate action or message can be generated.

Architecting for SOA: best SOA presentation I have ever seen

In this non-marketing presentation, Microsoft Architect Beat Schwegler introduces the notion of a service model as a mediator between the business and technology models. And he explains how a migration towards such an architecture could occur through a step-by-step architectural refactoring.

If you are serious about SOA, you really have to watch this refreshing video presentation that lacks any form of hype. You won't regret...

Using events to bridge decoupled service boundaries

I am honoured that my article "SOA and EDA: Using events to bridge decoupled service boundaries" is published by:

• The SOA Magazine

and

• SearchWebServices.com

Publish-and-subscribe is not EDA

There seems to be some ambiguity when discussing the patterns publish-and-subscribe and request-and-reply with regard to the architectural approaches EDA and SOA. This ambiguity origins from a "flat" view on architecture. To fully understand the relationship between these patterns and approaches it is necessary to distinguish between two viewpoints: logical and implementation.

When designing your architecture, are you driven by business events that trigger processes? Or are you oriented on a composition of hierarchically encapsulated layers of callable business services that form processes? Probably the overall architecture will hold both approaches simultaneously. When in a particular context (see How EDA extends SOA and why it is important) your approach is driven by events you will fall into a logical publish-and-subscribe pattern. When your approach is oriented on a layered composition of interacting services, you will end up in logical request-and-reply patterns. This has nothing to do with the patterns at the implementation level.

At the implementation level there are other forces, like available infrastructure, that make you choice for a pattern.
You may choose to implement a logical publish-and-subscribe pattern in a synchronous way. E.g. an RSS feedreader implements the subscription by periodically starting a synchronous interaction by requesting newly published events and wait for a reply. These events may be published by synchronously requesting a service to add a message to the feed store and wait for a "storage fulfilled" acknowledgement.

On the other hand you may choose to implement a logical request-and-reply pattern in an asynchronous way. Simply separate the issuer of the request and the consumer of the reply and separate the receiver of the request and the publisher of the reply. Publishing a request and subscribing to the reply doesn't make the architectural style an EDA. Neither does subscribing to a request and publishing the reply, nor does any combination of these types of interaction make an EDA. It is a loosely-coupled - e.g. asynchronous - request-and-reply implementation.

Web 2.0 meets SOA - AJAX UI for SOA

On one hand there is Web 2.0 going on. On the other hand there is SOA. The cool stuff versus the lasting robustness. Two opposite worlds. Joe McKendrick charactized the two:

The "SOA" guy is the one in a corporate suit, a bit uptight, and prone to making things more complicated than they should be. The "Web 2.0" guy, on the other hand, is the cool, good-looking one.

But these two worlds are running toward each other with the speed of light. Not to collide into damage, but to collide into fusion. Web 2.0 and SOA (or better: Internet technology and Enterprise Architecture) will come together in close harmony and in the end there will be no difference between the two anymore.

This article is a practical illustration of the convergence of emerging web technologies and emerging trends in Enterprise Architecture combined with emerging application services business models. All based on currently available components.

The components are:

• Web Browser
  
• Portal Server
  
• SOA (but may also be Web Service wrapped legacy)
  
• ESB (preferably)
  
• B2B Gateway (preferably)
  
• Portlets
  
• JSR168
  
• Web Services
  
• WSRP
  
• AJAX (yep, Web 2.0… At least, the face of)
  
• DOM (Document Object Model)
  

What these components and their purposes are will be explained during "composing the system" (below). The terms "application" and "SOA" in this article are equivalents with no distinguishing purpose.

Composing the system

1. Connecting the portlet to the portal server: JSR168

Figure 1 (click to enlarge)

The face of the portal server is a web server a user can connect to using a browser. The portal server provides access control, personalization and presentation. In the background the portal server is served by the security services infrastructure (keywords: Single Sign-on, directories, authorization, authentication, PKI, LDAP, certificates). The portal server also provides a way of decoupling from the user devices like laptop, PDA, Smart phone, PC or whatever the browser is running on.

Portlets are the windows from the portal server to the application (SOA-based in our case). They supply functionality like decoration, application navigation and some application level session control. Portlets can talk to each other which make them suitable to aggregate multiple applications at the application presentation layer. Portlets can be programmed to offer a wide (and wild) range of functionalities; the designer's professional craftsmanship is needed to preclude poor designs.

JSR168 is an open standard to provide a standard API between the portlets and the portal server (well, in fact the portlet container of the portal server). This standard provides interoperability between portals and portlets; e.g. JSR168 based portlets can plug into any JSR168 based portal server. Today most portal servers support JSR168.

In connecting the portlet with the portal server we use JSR168 to enable independency between the portlets and specific portal server products. In this way we don't have to maintain portlets for every portal server that accesses our SOA. We can deliver standard portlets with our SOA to be used by multiple portal server products. We don't need to reprogram our portlets when we decide to replace our portal server by another product.

2. Connecting the portlet to the SOA: WRSP

Figure 2 (click to enlarge)

The portlet has to be connected to our SOA. We don't want to create a tight coupling between the portlet and the specific SOA-implementation context (technology, geography); we want technology and geography independency between the portlet and the SOA-implementation. So we use Web service technologies for this interaction. Web services are the standards based interfaces to application functionality.

We also would like functional independence between the portlet on the portal server and application specific presentation logic of the SOA. Otherwise we have to maintain application specific logic in two places (portal server and "SOA-environment"). Even worse, it would become a burden if we want to access the SOA from multiple portals, each of which would have an instance of the portlet implemented with application specific logic. Not to mention the nightmare if you happen to be an independent party offering application services to dozens of customers.
So we split-up the portlet in a generic part (at the portal side) and an application specific part (at the SOA-side). The generic part facilitates generic UI logic such as presenting personalization, house-style decoration and other mock-up. The application specific part facilitates application specific logic, such as menu-structures, application navigation, application state.

The application specific part of the portlet need not be a "portlet", but is the application specific presentation logic which is conventionally is implemented by a portlet. In figure 2 the application specific presentation logic is identified by the name "Portlet" (between quotes) to indicate the strong relationship with common portlet functionality (presentation logic). In fact this component needn't be a "portlet" in the sense of running in a portlet container of a portal server (it nevertheless can be implemented in that way). Whatever the implementation will be, in an SOA it will be exposed as an addressable presentation service: the user interaction point of the SOA.

We introduce WSRP, Web Services for Remote Portlets, for the interaction between the to portlet parts. WSRP is an open standard to allow for portlets as presentation-oriented web services that can be used by portal servers. WSRP supports the publishing and consuming interaction of remotely implemented portlets. Sometimes WSRP is referred to as UI-web services.
There is a WSRP-consumer implementation at the portal side and WSRP-producer implementation at the SOA-side. Modern portal servers offer a WSRP-consumer platform and a WSRP-producer platform. However the WSRP-producer platform can well be a separate platform without the need of a portal server-deployment.

3. Creating a controlled messaging environment (optional): ESB

Figure 3 (click to enlarge)

The ESB, Enterprise Service Bus, is the enterprise's web services platform. Of course you may use plain HTTP as a web services platform for the enterprise, but we all know that is not a very good idea (at least not until "all" WS-standards are mature and embedded in the network and OS-infrastructure).

Within the enterprise we us an ESB-infrastructure to pass the WSRP-messages. In this way we obtain a level control for security, identity, accountability, auditability, reliability, performance and so on.

4. Connecting the browser to the portal server: AJAX

Figure 4 (click to enlarge)

No we get at the "cool, good-looking guy" stuff: AJAX, Asynchronous Javascript And XML, the technology to create cool and appealing web based user interfaces. AJAX can be (mis)used in a lot of ways. We'll apply AJAX not like a script kiddie but as a professional craftsman.

The DOM is the Document Object Model, which the browser uses to controls the screen layouts and screen objects. The DOM is manipulated by the user who enters keyboard keys, who does mouse movements and who does mouse-clicks on the screen. However, the DOM may also be manipulated by Javascript (or better: an ECMA-compliant script implementation). This is why web-site builders can irritate you with popup-windows, blinking logo's and flashing sale alerts. Javascript also provides access to a very interesting object called: XMLHTTPRequest. With this object you can set up an asynchronous communication session between the browser (using Javascript) and the web server.

The idea is to create a replica of the browser-DOM (or relevant part of it) on the portal server and to synchronize between the browser-DOM and its replica on the server. In the browser on the client it is Javascript (or an other browser scripting language) that handles the DOM manipulation and AJAX-communication. On the server it may be a servlet to fulfil this role.

Once we have this instance of the DOM on the server available and the AJAX synchronization mechanism in place, we are able to support the following interaction pattern:

• User interacts in real-time with DOM on client
  
• AJAX synchronizes in real-time DOM on client and DOM on server
  
• Portlet interacts in real-time with DOM on server
  
• Portlet interacts in on real-time with our SOA
  

This is a very powerful pattern. As the SOA interacts with the DOM on the server, the SOA can see all user events and can instantly react on it. Every change of the SOA to the DOM on the server is directly propagated to the DOM on the browser and visible to the user. In this way a real-time interaction between the user and the SOA is made possible while keeping the client perfectly thin. It is recommended to keep the client as thin as possible (ultimate: only synchronization code).

Traditional client-server solutions perform input validation checks on the server as well as on the client. The reason is that we want to inform the user about invalid input as soon as possible and not have him wait until the complete screen is sent to the server and the server responds. The server performs the checks again to avoid wrong input from manipulated clients. It the developer's responsibility to keep the client-side and server-side validation code synchronized.
When using AJAX in a proper way, there is no need for duplicate validation code, because the user input is directly propagated to the user entry point ("portlet") of the SOA. A validation check service of the SOA can alert the user on invalid data by asynchronously sending back a warning via the presentation service ("portlet").

When synchronizing keep in mind to avoid bad latency experience by the user. A very fine grained server-response mechanism - at the level of distinct key-strokes - will probably not be satisfactory to the user, because he might experience inconvenient delays. The time it takes for the user to enter data and the latency of the expected response must be designed to be in the right balance. Therefore it may be more suitable to collect the key-strokes at the server and have the application reply on a complete field or a logical collection of fields by design. This is of no difference to common desktop applications. If a very UI-intensive application has to react smoothly to distinct key-strokes or mouse movements, anticipate to it e.g. by designing smart - perhaps even predictive - caching solutions on the portal server (portlet) or even at the client side (browser).

Modern portal servers support AJAX and commercial products that implement the replica-DOM solution are available today.

A very good, clarifying whitepaper on this subject is available here.

5. Extending the enterprise (optional): B2B Gateway

Figure 5 (click to enlarge)

The B2B gateway provides secure and controlled access between the enterprise and the external world. The external world can be external partners, but also highly autonomous departments in a federated enterprise. The use of a B2B gateway is not mandatory, but highly recommended to obtain a level of control. It is possible that one company uses a B2B gateway and the other doesn't; this will not fail the system. It's the responsibility of the individual companies to deploy a B2B gateway or not.

The difference a B2B gateway and a portal server is that the portal server interacts with a human user (with the help of a browser), so is User Interface oriented. The B2B gateway controls the external Web Services access (inbound as well as outbound), so is Application Interface oriented. Like the portal server the B2B gateway is also served by the enterprise's security services infrastructure in the background.

The complete chain

Figure 6 (click to enlarge)

Figure 6 visualizes the complete chain from the user to the SOA. The chain includes a separate application service provider, company 2, offering the application service to company 1. Of course company 1 and company 2 may be the same one company using a common infrastructure. In that case there is only one ESB and no B2B gateways.

The SOA at the end of the chain may be coupled with yet other applications (SOAs) of yet other companies (preferably via the B2B gateway). So a user in New York may be working with an application that is constructed of components deployed in Sidney, Tokyo and Amsterdam with the experience of a local desktop application!

Software as a Service (SaaS)

Perhaps you don't agree with the terminology SaaS and ASP (Application Service Provider) the way it is used in this paragraph, but I merely want to illustrate two different viewpoints in delivering and consuming software based functionality. One viewpoint is you as the consumer of the software based functionality and the other viewpoint is you as the provider of the software based functionality. The model of delivering software based functionality to a third party I called SaaS and the provider I called the ASP. In the context of this article it is of no importance who in fact owns the software - provider or consumer (in which case the provider is only hosting the software) - and whether it is custom coded or commercial packaged.

1. You making use of ASP

Figure 7 (click to enlarge)

When you obtain application services from an external partner (typically the Application Service Provider or a business partner who gave you access to his application) you are happy to use this software as a service. But you don't want to bother your users with different look-and-feels and logons for each distinct application. You want a common access in your company's common house-style look-and-feel, integrated on your company's own portal server. So your user will experience one uniform set of services not being aware these services are provided be multiple independent ASPs.

This appealing use case is supported by the system as we just composed it.

Mind that it is out of your control and of no importance to you whether the external partner uses an ESB and B2B gateway or not.

2. You as ASP

Figure 8 (click to enlarge)

If you are the application service provider, your customers (or autonomous departments or business partners given access to your applications) will be happy if you don't bother them with the look-and-feel and the access control you designed for your application. And you won't be happy if all of your customers want you to support there house-style decoration. And how would you implement a single sign-on requirement for access to your application and all other applications (not yours) you customer uses? And in case of multiple users?

The system we just composed provides a solution. You can deliver application services to external customers each using their own house-style decoration and access control.

It is out of your control and of no importance to you whether the external partner uses an ESB and B2B gateway or not.

Conclusion

With this - simplified - architectural description of adding a typical web 2.0 user interface to an SOA, I tried to demonstrate the convergence of emerging web technologies and emerging trends in Enterprise Architecture. I made use of components like ESB, Portal, B2B gateway, which are currently available on the market. I also made use of standards like JSR168 and WSRP, which are mature and implemented in products available today. I made use of a known programming paradigm - AJAX - to synchronize between the browser and the web server in real-time. AJAX-support is currently implemented in modern browsers and portal servers. I've positioned the architecture in the context of emerging business models like B2B, SaaS and ASP. I illustrated a globally distributed application deployment with a user experience of the application running on his local device.

Standards, products and business models will further mature. New standards, technologies and products will emerge and will encourage application services business models at a global level. I think there is no way back from the convergence of internet technologies and Enterprise Architecture. I think SaaS will have a big future making global scale profits out of these evolvements. And I think it will go faster than many realize.

What is a Service in an SOA?

A Service in an SOA meets the following criteria:

• Multiple-use
• Non-context-specific
• Composable with other components
• Encapsulated i.e., non-investigable through its interfaces
• A unit of independent deployment and versioning

Duh...

A Service is written to a specification. It does not matter what the specification is: COM, Java Beans, WSDL, etc., as long as it adheres to the specification. It is only by adhering to the specification that it becomes a Service and gains features like reusability and so forth.

Duh...

The idea in OO (Object Orientation) is that software should be written according to a mental model of the actual or imagined objects it represents.
Services, by contrast, makes no such assumptions, and instead state that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics.

Duh...

When a Service is to be accessed or shared across execution contexts or network links, some form of serialization (also known as marshalling) is employed to turn its interfaces into a bitstream.

Duh...

It takes significant effort and awareness to write a Service that is effectively reusable. The Service needs:

• to be fully documented;
• more thorough testing;
• robust input validity checking;
• to pass back useful error messages as appropriate;
• to be built with an awareness that it will be put to unforeseen uses;
• a mechanism for compensating developers who invest the (substantial) effort implied above.

Duh...

No big deal to agree with these statements, is it? Now read, for fun, the definition of a Software Component where I took these text fragments from while replacing "software component" by "Service".

So, is a software component a Service and is CBD (Component Based Development) the same as building a Service Oriented Architecture? Not quite, it is the other way around: A Service in an SOA (as SOA is currently understood) is a software component, but a component with a strong business function constraint. SOA is an instance of a component based architecture. So building an SOA has always to do with CBD, but CBD has not always to do with building an SOA as we understand an SOA.

The idea that software should be componentized, built from prefabricated components (like Services), was first published in Douglas McIlroy's address at the NATO conference on software engineering in Garmisch, Germany, 1968 titled Mass Produced Software Components. A very interesting reading. Some quotes:

• The most important characteristic of a software components industry is that it will offer families of routines for any given job.

• He will consult a catalogue offering routines in varying degrees of precision, robustness, time-space performance, and generality.

• He will expect families of routines to be constructed on rational principles so that families fit together as building blocks.

• We have to begin by thinking small.

• It will take some time to develop a useful inventory, and during that time money and talent will be needed.

• Even before founding a pilot plant, one would be wise to have demonstrated techniques for creating a parameterized family of routines for a couple of familiar purposes

• I think that the whole project is an improbable one for university research. Research-calibre talent will be needed to do the job with satisfactory economy and reliability, but the guiding spirit of the undertaking must be production oriented.

• The personnel of a pilot plant should look like the personnel on many big software projects, with the masses of coders removed.

• Very good planning, and strongly product-minded supervision will be needed.

• the level of programming here will be more abstract

• One instantly thinks of distribution by communication link.

• The catalogue will be equally important.

• Quite soon one would expect a components industry to converge on a few standard types of interface

• but again unless the standards encompass the bulk of software systems (as distinguished from users), the components industry will die for lack of market.

• I would like to see components become a dignified branch of software engineering.
  

• I would like to see standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters.

• I would like to apply routines in the catalogue to any one of a large class of often quite different machines, without too much pain.

Fascinating similarity, these quotes from a respectable 40 years old document and our modern innovative SOA-thoughts, isn't it?