The Decade of the Component - Service orientation is just the beginning

I guess, before I start my day, I need to get this out of my system: You know what´s happening right now? It´s the decade of the component! The 1970/80ies were the decade of structured programming, the 1990ies were the decade of object orientation - and now we´re right in the middle of the decade of component orientation.

Why am I saying that instead of calling if the decade of service orientation? Because what´s happening is a struggle for a definition and infrastructures of components as building blocks that get manufactured independently. But everybody is talking about services, you say. That´s true. But services are just the starting point of a larger movement. After having been in object orientation up to our chins, there needed to be a next step up the abstraction ladder. Objects (or classes for that matter) are too fine grained as to enable us to build large systems.

Unfortunately current tools and lots of legacy software and long standing practice made it impossible to gradually move from objects to - let´s call it "real software building blocks" within (!) the boundaries of a process. Sure, I know, the term "component" has been around for a long time. And we all know COM as "Component Object Model". But let´s be honest: Who is building components besides 3rd party user interface control manufacturers or Microsoft? It´s always the others doing component oriented programming (COP), but not your shop, right? ;-)

Contrary to popular belief, the software industry has not (!) broadly adopted COP. And I can proove it: Look at Visual Studio and tell me, if it actively supports Contract First Design (CFD)?

It does not! It does not, because Microsoft does not use the term in its communication. It does not, because there is no (official) way to reference a contract instead of an implementation and map the contract to an implementation in a separate place. (I´m not saying, this is not possible using the .NET Fx. I´m just saying, Visual Studio (or Microsoft for that matter) does not favor or even mention this approach.)

But why´s that a proof? Because without CFD there is no real decoupling of "software building blocks". Only if contracts - or interface descriptions - are separated from the clients and providers of those contracts can they be developed separately. And this separation is at the heart of all industrial production on the planet.

But that´s just the first step. CFD alone is not enough. It´s just a concept for architecting software. To reap its benefits, client and provider of a contract must not (!) reference each other directly, when you build the software. Because if you depend on them referencing each other, you don´t just depend on the contract anymore. The contracts purpose is to make development of client and provider independent. That means, they don´t know of each other. And that means, they don´t reference each other in Visual Studio. (Binding a client to a provider of a contract later during runtime then sure is a challenge. But there are solutions for it. They are called IoC (Inversion of Control) Frameworks or Microkernel, e.g. Spring.Net or picocontainer.)

So, since CFD and Microkernels are no concepts with which Microsoft or Visual Studio are conerned, there cannot (!) be real component orientation. Existence of a System.Component class is not enough. Putting a manifest into an assembly is not enough. The fundamental notion of "real building blocks" being separate from their specification (contract) is not implemented in current tools or languages.

Modula-2 and Eiffell started in that direction. But they are either outdated or not widely adopted. Commercially relevant languages like C# or VB or C++ or Java are not component oriented. Again: don´t let yourself be fooled by container structures like assemblies or some class called Component.

Enter services. With the advent of Web Services there suddenly was a very natural unit of software that could serve as a "software building block": the process.

Processes are isolated from each other by definition. They have an explicit boundary around their address spaces and resources. No, they are (!) this explicit boundary, they define it. So if you want to have two processes communicate with one another you need to explicitly define how this should be done.

Bingo!

Processes form units of software and need an explicit contract for communication. Processes are thus ideal candidates to manifest the concept of software components as independent software building blocks.

Although in the beginning (Web) Services were wired together like ordinary assemblies using direkt references, there is a fairly large movement towards CFD in the SOA world. Visual Studio might not yet support it, but it´s on its way - or 3rd parties might provide CFD/Microkernel tools.

So, what have we? There are classes and there are services. Classes are on a low level of abstraction and not fit to be building blocks for large software systems. Services are on a much higher level of abstraction and fit for building large software systems. Classes are not components, assemblies are not components, but services (or to be more general: processes) can be viewed as components.

But that´s not enough. Although we should be very happy to have the whole service discussion and a movement towards being able to turn processes into "software building blocks" aka components, it´s a jump too far ahead. There´s a gap between classes/assemblies and services.

The gap lies within (!) a process. Services are building blocks for large distributed software systems. But not every software needs to be designed as a distributed system. Take for example Microsoft Word. It´s a very complex software system - but yet manifests itself as just one process.

What´s lacking is components to build single processes. Classes are still not enough, too fine grained. Sure, assemblies can be used to partition classes, which logically belong together, into smaller packages. But that´s not really COP as I tried to explain above.

Looking at all this, my personal opinion is: Despite all the efforts regarding service orientation, building large systems will not really take off unless we realize, how to build single processes/services from larger grained building blocks than classes.

That´s why I say, this is not the decade of services, but the decade of components. Because services are just large scale components, but we need real small scale components, too.

7 Comments

  • Thanks for posting this in English. Really intersting. I have been giving a good deal of thought to how to improve granularity within a process. For my taste I'm seeing too much use the facade pattern over IoC and dependency injection. All to often the Facade layer becomes fine-grained and pointless.



    Keep posting - great stuff.

  • @Ian: I guess you´re right: The facade pattern often is a workaround the lack of real component. But IoC/DJ alone don´t solve the problem either.



    We need to start with strict CFD. Then we need some discovery and instanciation framework. But we also need tool support and language support.



    Languages are needed that have a notion of real components to guide my thinking.



    And tools are needed to make dynamic binding using mappings of interfaces to implementations easy. As far as I know, Spring.Net et al. are lacking such kind of tools. That makes it very tedious to work with them.



    -Ralf

  • Since there are so many developers that do not yet understand OO, can we say that the "decade of the object" is over? More so, without the basics of OO, can those developers raise to component orientation?



    I think not.



    However, I don't think it matters.



    Yes, it bugs me that I don't have tooling to help me. But I still can, and do, design systems using component principles. I then "force" the team to follow those principles.



    I think that the same will be true for SOA. Yes, we'll be hearing the same old lines "but it works this way, too", and "why is that better than what we have now?" but that never stopped us before.



    Wide spread adoption and tool support would be nice. It's just that its not absolutely necessary.

  • @Udi: I agree, that OO has not been fully adopted either. But I think, OO has been thouroughly reasearched and there are many excellent tools and languages out there to support OO.



    That´s why I say: we need to switch focus. OO is an old hat - we need to move on, up the abstraction ladder.



    We need to realize, we´re in an elevator. And, ping, you here the bell to tell us, we reached the next floor? The elevator voice says: "Next floor, components. Get off, if you want to build software more productively and make it easier to maintain and understand." :-)



    -Ralf

  • @Arnon: Sure, we want to keep OO in the future. It´s great - for what it is designed to do. That is building the internals of components.



    But we need to move on the the general discussion. All that´s necessary has been written about OO and patterns and what not.



    Now let´s take the next step up the abstraction ladder. Let´s talk about components: small scale components as building blocks for processes, and large scale components (aka services) as building blocks for software systems spanning several machines, networks or even companies.



    As for your Micro Services: If they are processes, then I think the name is appropriate. If they are intra process building blocks, I´d rather call them components.



    In any case: In order to gain decoupling it´s not necessary to let code run in a separate process.

  • I think you are right to make a distinction between process boundaries and component boundaries. Fowler makes a similar point in PEAA where he draws a distinction between physical tiering and layering. A well designed system is layered but those layers are not necessary deployed on separate machines.



    I would also add that the component\service revolution is not happening in isolation; we are also witnessing the Rise of Workflow. Workflow is already seen as the tool of choice for Orchestrating services but this is only the start, users are crying out for more configurability and as developers start using tools like Windows Workflow Foundation implement the logic within their component\services so traditional OO (with methods close to their data) will have to retreat.



    In a weird way this almost takes us back to structured programming. If this is going to be the future I think we need to avoid the pitfalls of Spaghetti Workflows and Service Bloat.

  • @Tony: You´re right: workflow also is a very important topic nowadys. And I hope, OO will be put into perspective: it´s very usefull - but no panacea. We need more levels of abstractions which have manifestations in code. Then we can orchestrate those abstractions.

Comments have been disabled for this content.