It’s All in a Name: What’s a Service?

 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.


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.


Comments (20)

  1. Pat,

    Glad to have you aboard. I saw you present at the PDC in October (I continue to refer people to your slide deck every so often when in heated discussions of services). Looking forward to your thoughts and insight as time goes on.

  2. Pat Helland starts blogging. I have been respecting him since when I first hear him talk at TechEd (2000 IIRC) about Fiefdom and Emissary.

  3. Pat, absolutely great presentation at the PDC!

    I’ve got a question regarding your description above using foos and bars to differentiate between service interfaces and a completely autonomous service. In the talk which immediately followed yours at the PDC, David Campbell spoke about Service Agents and Service Masters. In terms of foos or bars, what “type” of services are these?

  4. Pat:

    I like your thoughts on foos and bars but I have a question about bars. Since bars are autonomous from a data perspective, how do you deal with the fact that business applications rely on a data model that is completety intertwined and related. For every type of systems (ERP, CRM, PLM, HR, SCM,…) there are usually one or more centers of the data model and all the other tables, without a single exceptions are related. As a matter of fact, within an enterprise very few pieces of data are independent (I could only think of HR and everything else). Does that mean that a bar is as big as an ERP or CRM system?



  5. Luke Stevens says:

    Is the difference between a service and a service interface any more substantial than the difference between a circle—in the sense of a solid filled circularly shaped area—and the boundary of that circle, also known as a circle?

  6. Pat Helland says:


    re: It’s All in a Name: What’s a Service? 3/19/2004 5:33 PM Jean-Jacques Dubray

    JJ asked about the fact that MANY enterprise systems end up with their data being accessed by many different apps and there ending up with no clear boundaries.


    Great question! I think the issue is that many apps have created the “Big Ball of Mud” as described by Brian Foote and Joseph Yoder (see

    It is natural to get everything complete entwined when you can just open the database table and get to the data you want. The easy thing happens and soon every application on the system is sharing one humongous data model. One of the driving forces of SOA is to emphasize a new and coarser encapsulation.

    Objects do encapsulation just fine to protect member variable… indeed, the object folks (as a sweeping generality) think about in-memory data and encapsulation but don’t think about the fact that real data (i.e. enterprise data) is kept in a database. This leads to a programming environment where many different objects would open up the database tables and whack on the data contained within them.

    Sure, during the execution of a transaction their member variables are encapsulated but database records are effectively global variables unless we impose some discipline on them.

    The way I think about SOA is that the service (or the “bar” if you will) is a scoping of these “global variables” to live within disjoint sets (which I have jokingly labeled as “bars”).

    So, is a bar as big as an ERP or CRM system?

    In the future, we will see new systems defined to understand that some data is published by one service as read-only snapshots of data (which I frequently call reference data). For example, the Accounts-Receivable package will definitely need to refer to the customer information and have an identity for the customer. It is likely that changes to the customer data only happen at the CRM system and are periodically published as a version of the customer info (e.g. Tuesday’s customer-info, Wednesday’s customer-info). This is a modeling abstraction for how data is handled across multiple services that acknowledges the need for passing out copies of information (to other services) that understand it is not absolutely the freshest state. This is inevitable as systems are designed to be more independent and yet interact together.

    Many of today’s enterprise apps are not designed with this in mind. They were developed for environments in which it was OK to open another apps table in the shared database (perhaps only open it for read-only access but still open it directly). This allowed the app to see the up-to-date and accurate state of affairs as of the last transaction. This is a different semantic than the read-only snapshot version that is sent out periodically.

    Many of today’s apps will not get broken apart because it is too hard and too expensive. That is OK. They will continue to exist but will not get the scale-out benefits that are possible with an SOA designed app and will perhaps be more challenging to maintain.

    Still, you can surround these apps with service-based interfaces using messages coming in and out. I’ve said before that it is frequently a great idea to export only a subset of the functionality that makes business sense to creating message-based interfaces for. This will mean that many (pre-SOA) apps (e.g. ERP, CRM, etc) will be very large services. Indeed, they will be very large services with some work arriving via service interaction (where it makes business sense to retrofit the app to cope with certain functions arriving via messaging) and other work directly arriving from human operators the way it always did because there was no business justification to change those interfaces to the app. Only do programming when it makes business sense.

    In freshly designed apps, smaller grained services will be created. The ERP system may comprise dozens of services. This is practical when you are designing it in from the beginning. It is far less likely for an app that was not designed to have the data kept separate into different “bars”.

    So the answer is “it depends” and over time, more and more boundaries will appear. It is the creation of programmatic models to encourage this evolution that is one of the major goals of SOA.



  7. Pat:

    thanks, I saw your presentation on MSDN, what a great string of presentations from Norm et al. This is great stuff. I can sense a bit of hand waving in your answer here, but that’s ok, this was a very difficult question, probably a billion dollar question. OAGIS did define some clear boundaries already and I have a lot of respect for an architecture that was concieved in 1995 and is becoming more relevant on a dayly basis.

    I am having a debate on my blog related to this question (so the question was not completely innocent), I argue that model-oriented business logic (i.e. the bars services) must be orchestrated, rather than request/response invoked by a BPEL process.

    My argument is basically that "BPM" greatly impacts the "controller" of MVC, but that’s not enough. It is clear that the view is also impacted (e.g. UIP application pattern). I also content that the model needs to be orchestrated to avoid spaghetti business processes. An orchestrated model reflects far better the lifecycle of business entities like Orders or Invoices, while the process can decide rules and steps that advance this lifecycle.

    Part of the debate is at:

    Since you have been the father of COM+ and MTS, I might as well ask you another question I keep asking on my blog. What about creating a Microsoft Coordination Server (on top of Indigo for instance). Where all forms of coordination could live (transaction, orchestration, …)


    Jean-Jacques Dubray

    Architect, Attachmate

Skip to main content