In order to communicate effectively about a service-oriented system, stakeholders must use a shared nomenclature when discussing the different types of services within it. Their seems to be a real need for such a taxonomy in our industry, so I would like to share the following terms in hopes that readers will offer suggestions and additions. To help understand all of these classifications, the following Venn diagram shows the relationship between the different service types.
The utility service is a class of services that is comprised of those that are small, compact, indivisible and are used as the building blocks in a service-oriented system. They are used to construct the larger, higher-level services. They are not cluttered up with product- or system-specific logic or functionality (which instead is found in controller services). Utility services are atomic. Their standalone nature insures that the system is agile and flexible from the ground up. Their unfettered construction allows these core services to be easily reused across may service-oriented applications; it also facilitates swapping them out without causing system-wide disruptions. Entity, proxy, and framework services are examples of utility services.
The proxy service classification is comprised of those services that function as a bridge between other members of the service-oriented system and incompatible subsystems. Device and process services fall into this grouping. Services in this class are sometimes referred to as wrapper, broker, or gateway services. Proxy services are analogous to the design pattern by the same name popularized by the GoF.
Device services are a specialized type of proxy service that stands in front of a hardware device. They are used to control and communicate with devices that do not natively provide an API that is compatible with the protocols used throughout the service-oriented system. A device service translates between the machine’s communication channel(s) and those required to converse over the service bus.
Process services are another type of proxy service that are similar to device services. Unlike the latter, however, the former is used as a translator between a software application and the other members of the service-oriented system. Process services are almost always required to bring legacy software onto the bus.
Controller Service (aka Business Service)
Services that fall into this category are those that orchestrate the smaller building block services together to solve certain business requirements. These services must be as flexible as possible to meet constantly changing business needs. Often, these services are built using workflow technologies, allowing them to be implemented using a graphical, drag and drop programming model. This implantation strategy insures that they are produced quickly, keeping their development cost low. The TCO and rapid development of these services is important because they are highly susceptible to change and are the most product-specific services within a service-oriented system. Controller services manage utility services.
Entity Service (aka Data Service)
Entity services expose a single concept that is physically stored within a database. They are uncluttered by other utility services such as notifications and auditing. They provide access to information stored in backend databases via communication protocols used on the service bus rather than any technology-specific data access mechanisms such as OLEDB, JDBC, etc. They also shield consumers from any particular database server or specific database server version, isolating the system from changes in the IT infrastructure.
Framework services are those necessary for every SOA. Regardless of the industry or product, all service-oriented system have them. They may not all have device or entity services, for example, but every SOA will have framework services. Examples of services that fall into this category include logging, auditing, notification, and security services.
Integration services are those that lie at the perimeter of a system. They play a similar role as process services; however, they are distinct because of their outlying position. Together with controller services, integration services stand at the outer-most edges of a service-oriented solution whereas process services incorporate incompatible software applications into the system. Process services hide incompatibilities; integration services provide the input paths to the SOA. They do this by supporting many different communication protocols through which they receive messages that are normalized before being relayed to other service connected to the bus. Integration services are often implemented using EDI products such as BizTalk. Though controller services also stand at the borders of an SOA, they do not support a wide array of input channels through which messages can flow as integration services do.