Service Classes distinguishes different types of services. Service classification is an activity that should be started as the first candidate services are identified. A service model:
•    Provides guidance on design and development of services.
•    Provides guidance on “service consumption” rules.
•    Provides guidance on “service enablement” mechanisms.
•    Provides guidance on use of component types, Application Programming Interfaces (APIs) and Domain Specific Languages (DSLs).
•    Creates a mechanism to easily find services by category.

Aside from architectural considerations, service models could also be used to identify service ownership. For example, all data services might be owned or managed by a particular group within the enterprise.

A hierarchy and – to some degree – layering are implied in this model to highlight the fact that by nature SOA is an approach where services can be composed using lower-level services. Additionally, this model imposes a logical separation of the business functions which are fairly stable from business processes which may change and evolve rapidly.

Enterprise Resources
Enterprise resources include all custom or packaged application assets found in an enterprise computing environment that support business activities. Those include:
•    Custom/homegrown applications.
•    Legacy applications and systems.
•    Databases.
•    Packaged applications and solutions also known as commercial off-the-shelf (COTS) software.
Enterprise resources generally represent significant investments in the many years of coding, developing, enhancing and operating them. An effective SOA strategy focuses on leveraging the existing enterprise resources and identifying the useful functionality and tasks that can be exposed as services. Furthermore, enterprise resources are always accessed via integration services.

Integration Services
Integration services provide access to enterprise resources. They leverage objects, components, and adapters that allow easy integration with the enterprise resources. Integration services are atomic services and can be seen as providers of service-enabled interfaces to enterprise resources. This is where service enablement occurs in an SOA.
Integration services are often implemented by leveraging:
•    Open standards such as Java Database Connectivity (JDBC) to interface with databases, or Java Naming and Directory Interface (JNDI) to interface with LDAP Directories.
•    Adapters built using J2EE Connector Architecture (J2CA) to interface with software such as Oracle and Siebel, or even databases.
•    Message-Oriented Middleware such as IBM MQSeries, or messaging bus such as TIBCO Rendezvous.
•    Proprietary or native interfaces.

Data / Information Services
Data or information services expose enterprise data elements from a system of record in a consistent way – for common usage throughout the enterprise. They are atomic services and are characterized by their implementation which is directly related to an enterprise data element. In addition, data services do not complete meaningful business functionality by themselves. Data services can be seen as providers of service-enabled Create, Retrieve, Update and Delete (CRUD) operations for enterprise data elements.
Data Service Examples:
•    Creation of a new customer profile for the Order Management System.
•    Retrieval of all orders from an Order Processing system for a given customer.
•    User's password update in a LDAP Directory server.

Business Services
Business services expose core, discrete business functionality that is not necessarily tied to a given information system, in a consistent way and for common usage throughout the enterprise. They could be atomic services but are usually composite services. They include business logic and business rules – and are composed of other lower-level services (e.g. data services, integration services). Still, they do not complete meaningful business processes or functionality by themselves.
Business services examples:
•    Online account opening process.
•    Transfer funds process.

Orchestration Services
Orchestration services expose business processes in a consistent way and for common usage throughout the enterprise. They are usually composite services and they are usually composed of other lower-level services (e.g. business services, data services, integration services) using specialized orchestration languages like Business Process Execution Language (BPEL). They include the high-level multi-step business logic required to implement business processes and may represent long running processes.

Presentation Services
Services found in the layers below the presentation layer generally expect input data and return output data that is represented using normalized or canonical data formats. Often, these data formats are not well suited to support user interfaces built using modern technologies and techniques (e.g. AJAX).
Presentation services are presentation components exposed as services. These services act as translator between the services found in the layers below the presentation layer and the user interface components.