I am concerned about how to interpret a “service” and a “system” as differentiated from an application or a hardware node (or Windows “box”).  There seems to be no small amount of confusion about the crisp definition of a service.  We seem to muddle the destination end point for a message with the definition of the collection of stuff that will be processing the message. 

Consider a couple of concepts that we all know and love but (for now) I am going to give them placeholder names “Foo” and “Bar”.

Foo:     This is a named endpoint that a partner can address and engage in a messaging relationship (NOTE: we frequently call this a service).  A partner interacts with a foo using only schema and contract.  A foo’s willingness to interact is defined by policy. 

Bar:      This is a collection of data and logic that is completely isolated from anything else except through incoming messages.  A bar has explicit boundaries and is autonomous.  Typically (i.e. in real applications), a bar is implemented as a bunch of code surrounding a set of tables in a single database.

Observations:

1)       A bar implements one or more foos. 

Many times, Foo-1 (one named endpoint) and Foo-2 (a completely different name for an endpoint) share the same database in their implementation.  If someone invokes Foo-1 and chatters with it for a while, Foo-1 may make changes to the data it fiddles with and a subsequent interaction with Foo-2 will yield different results than it would have yielded if the Foo-1 interaction not occurred.  Sometimes a new version of a Foo is created and given a different name to its endpoint. 

2)       A bar is implemented on one or more computer systems.  We typically see a single database engine but there may be a cloud of compute engines surrounding the database engine implementing the bar.

3)       The outside user (or piece of code on the outside) will invoke a foo which the network (hopefully using Indigo) will route to a piece of code that is part of the bar.  This piece of code will work on the shared data of the bar.

4)       It is quite reasonable to implement a bar on a single computer system (e.g. a single Windows machine running a single instance of SQL Server).

5)       It is quite reasonable to implement many bars on a single computer system and even on a single database.  For them to be separate bars, though, the data that each bar manipulates must be disjoint from the data manipulated by the other bars.  This is inherent in the explicit boundaries aspect to a bar.

6)   If a bar is autonomous, it cannot matter where it is deployed!  By definition of autonomy, it is independent of all others and so the act of deployment or redeployment cannot change the semantics.

So, what is a service, a foo or a bar?   They are fundamentally different things that we blur the word service for…

What is a system?  I’ve seen it described in different Indigo discussions as a collection of autonomous services.  First of all, if they are autonomous, who knows the difference of the collection of them?  Does this mean a collection of foos?  If you can tell the difference associated with the collection, they are not autonomous.  Does this mean a collection of bars?

Since these are autonomous, you shouldn’t be able to semantically tell if they are collected by their behavior.  This should only be a management/deployment issue.  I don’t get how we want to define this.  This definition would seem bizarre to me if the word system means a Windows node…  Many of the bars will be implemented across multiple Windows nodes.  From the programmer’s perspective, we shouldn’t even introduce the term system into the vernacular as programmer’s need to work with foos and bars.

Now we come to the word application.  (“Applications built from autonomous services”, and “A set of deployed services is an application”).  That would seem to me to be a bizarre statement in a world where the transitive closure of service interactions includes all computing…  Where is the boundary of an application?  Of course, the word application has a legacy meaning.  Of course, we need to allow that legacy meaning to be applied to an evolved solution where part or all of the implementing comprises services.

I would propose that we use the word application exactly as it has meant in the past.  An application is a collection of functionality that is tightly interrelated.  For the most part, applications have historically stood alone.  Sometimes, they have been a bit interconnected via EAI or B2B but that has been the exception rather than the rule.  It seems appropriate that we continue to use the word application exactly has it has been used in the past and gradually evolve away from using it.  An application may be implemented out of services.  We more frequently discuss services and the implementation of business functionality via services.  Both the notion of interfacing to an application as a separate entity and the notion of grouping code into applications will gradually dissolve over time,

So, I propose that both system and application be terms that we treat in a low-key fashion allowing them to retain their existing usage but not highlight in our presentations about service oriented architecture.

But what do we name the foos and the bars of the world?  One possible use of terminology would be that a (bar ßà service) and (foo ßà service-interface).  Given this terminology, we can speak to the implementation of the service (i.e. bar) running on one or more Windows Nodes.  We can speak about the service (i.e. bar) being autonomous and having explicit boundaries.   We also can speak about the service supporting a set of service-interfaces each of which exposes schema and contract and is invoked only when the policy is met. 

This definition complies with the four tenets of service oriented computing being espoused by the Indigo team (and which I wholeheartedly support).  The interesting twist is that the schema, contract, and policy apply to the service-interface (i.e. foo) and that the union of these is applied to the implementing service (i.e. bar). One more twist is that the service as an entity continues with its identity even as it evolves to support a differing set of service-interfaces.  Of course, the invoking partner code needs to be aware that it is invoking a service-interface.  The actual name of the underlying service is transparent to the partner.

I am NOT hung up on the term service-interface.  I am strongly advocating that we come up with TWO TERMS for these two concepts.  We have muddled the use of the word service and it is a source of confusion.  The words application and system are problematic in this realm and we should tread lightly on their use.

Love,
Pat