ESB market overview

{Client + Server + Service} = S+S

On 12 and 13 march 2008 the TechDays took place at ICC in Ghent. The second day I attended the architecture track on Software + Services (S+S). Eugenio Pace, who is working in the Software as a Service Architecture team at Microsoft, explained the anatomy of S+S applications and talked about his experiences in building (ISVs), running (hoster) and consuming S+S applications. He demonstrated LitwareHR, a sample S+S application with multi-tenant data access, extensible data model, multi-headed front-ends (web client, smart client and REST/SOAP APIs) and consumption of "services in the cloud" (Silverlight Streaming and SQL Server Data Services aka Sitka).

In my opinion, LitwareHR can be considered as a reference S+S application and Eugenio and his team will have to face different problems but it became clear to me that the whole approach in software architecture is just the beginning of a new era in IT. One of the main challenges will be to trust providers of "services in the cloud". For business critical applications, most companies want to control their applications themselves (on-premise) and as a result of that, they pay for it. Small and medium-sized companies rather would like to outsource things.

The team behind LitwareHR is experimenting with SQL Service Data Services (SSDS) for customization and multi-tenancy data in LitwareHR because SSDS has built-in support for extensibility and tenant isolation. I'm wondering if SSDS will be performant enough.

I was invited to join a round-table discussion with Eugenio Pace on S+S and he impressed me. Sometimes you get the impression that Microsoft is leveraging lots of stuff that we don't need in real-life business applications. When I talked to Eugenio I realized however that even companies which are not driven by technology can take advantage of "future" architectural approaches. As Eugenio told, programming languages, operating systems, technology changes constantly. Architecture and design patterns are more invariant. I certainly believe that the S+S approach will influence the way how applications will be designed in the future.

WCF Mindmap

Definition of SOA

So many definitions...I like this one:

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought - the end solution is likely to be composed of services developed in different programming languages, hosted on disparate platforms with a variety of security models and business processes.

The four tenets of SOA

Tenet 1: Boundaries are explicit

Services interact by sending messages across boundaries. These boundaries are formal and explicit. No assumptions are made about what is behind boundaries, and this preserves flexibility in how services are implemented and deployed.

Principles:

• Know your boundaries.
• Provide few well-defined public interfaces to your service.
• Internal (private) implementation details should not be leaked outside of a service boundary.
• Services should be easy to consume.
• Crossing a boundary can be expensive. SOA urges discipline in what is exposed to a boundary. It’s important to call services only when necessary and to do so as simply and efficiently as possible.
• Avoid RPC interfaces because this can lead to an overuse of calls. Accessing a service is not the same as accessing a local object!

Tenet 2: Services are autonomous

Services are not subservient to other code: a service reacts to a message – how that message was created and what will happen to any response the service creates is immaterial to the action that this service will take.

Principles:

• Deploy and version services independently from the clients. Hence, services can evolve separately from the clients.
• Design contracts with the assumption that once published, they can’t be modified. Build flexibility into the schema design.
• Design services by adopting a pessimistic outlook. From a provider perspective, expect misuse of the service. From a consumer perspective, plan for unreliable levels of service availability and performance.

Tenet 3: Services share schema & contract, not class

Only messages pass from service to service, code does not. These messages are not random but a sequence of one or more that have been agreed upon.

Principles:

• A service’s contract should remain stable to minimize impact upon service consumers.
• Contracts should be designed to be as explicit as possible to minimize misinterpretation.
• Avoid blurring the line between public and private data representations. A service’s internal data format should be hidden from consumers, while its public schema should be immutable.
• A service must be able to convert its native data types to and from some technology-neutral representation. No technology-specific things are exposed!
• Version services when changes to the service’s contract are unavoidable.

Tenet 4: Service compatibility is based upon policy

A service must be able to express in a standard representation of policy what it does and how clients should communicate with it.
Services don’t just blindly access each other: they need to determine areas of compatibility and agree on how they will interact. Every service provides a policy – a machine-readable description of its capabilities and requirements.
Each service has a set of policies that it expects to operate under and it is not prepared to operate unless these policies are satisfied.
Using policies allows the behavior of a service to be separated from the constraints of accessing the service.

Principles:

• Policy assertions should be as explicit as possible regarding to service expectations and service semantic compatibilities.

SOA Practical principles

Services are secure.
Services leave the system in a consistent state.
Services are thread-safe.
Services are reliable.
Services are robust.
Services are interoperable.
Services are scale-invariant.
Services are available.
Services are responsive.
Services are loosely coupled.
Services are isolated.
Services are location-independent.
Services are transport-neutral, protocol-neutral and format-neutral.
Services are platform-independent and implementation-independent.
Services are address-agnostic.
Services are (time)-independent.

Service Orientation vs Object Orientation

Service Orientation is a complement to Object Orientation, not a replacement for it.In a solely object oriented approach, an application is a tightly coupled collection of programs build from class libraries that have dependencies on each other. A service oriented application is a different entity entirely composed of loosely coupled autonomous service programs.Message-oriented services are used to build a distributed solution. Those services are created with object orientation.