- The Web Services View; in the web services world services are primarily described using WSDL, therefore we can take the WSDL view of a service as being the collection of endpoints accessing an implementation of a portType (in turn having a set of operations or message exchanges). So service tends to get equated with the actual implemented, running "thing".
- The Design View; when we look at designing services we want to focus much more on the abstract definition of a service capabilities - in WSDL terms the portType - than the implementation details of the bindings and endpoints. This is not to say they are not important, specifically whether a service can meet it's quality of service goals can depend greatly on the transports and encodings chosen. So for many the service is the interface defining it's capabilities and this service may have multiple instantiations.
- The Action View; if you take a process decomposition approach to identifying services you often end up with a set of actions that are the leaf tasks in the process, implementing each as a service would imply that a service maps well to an operation (in programming language terms). In fact until recently the RUP for Systems Engineering1 Architecture Framework used a modeling approach that used UML operations as the definition of services.
So what, is it really that important to know whether a service is modeled as an operation or an interface? Well it turns out that it does matter, and it matters quite a bit. For example, those who prefer the decomposition approach whereby they end up with a catalog of "actions" that are invoked by a process consider each action a service "place order", "check availability", "update customer address", and while this is appealing and does seem to match well with the concept of "service" in every day use it has a particular drawback. Let us consider the "place order" service, if I think of the last time I placed an order for goods with a retailer it seems reasonable to consider the placing of the order as a service provided by the retailer - an atomic action. Except that it isn't, granted that in most cases everything goes well and the next I know of my order is the arrival of goods; however modeling this as an operation does not allow me to cater for the case where ordering is a more complex activity. In the e-retailer case this may be that I am told that an item is out of stock, would I like to wait for all my items to be available (therefore reducing shipping costs) or ship the available items now? In a business to business setting this conversation can get even more complex, I can ship you 10 today with the balance next week, or I can ship you all of the quantity of this compatible product, or we can wait for next week.... So it seems that really a service needs the ability to be defined in terms of a potential conversation, the sum of which is the action we identified supporting our business process.
We also mentioned that there is a notion that when we use the term service we mean the implementation artifact. In this case the drawback is simply that binding the service and interface in this way to become a single entity does not readily allow me to reuse service specifications and separate out the specification of the expected behavior from the actual implementation, and possibly multiple implementations of a given specification. It is vital therefore that whatever terms we use, service, interface, specification, contract, that we clearly separate and continue to manage the specification and implementation of a service as distinct elements.
Now there are also potential drawbacks to using an interface-like structure to defining a service - for example where some services really are single operations (for example there will most likely be a set of low-level data access services that are best modeled as independent transactions) then the overhead of a single provider implementing a single interface with a single operation can become cumbersome. Yet this really becomes a tooling issue - one which we IBM have to step up to, to make sure that our modeling and construction tools cater well for both the simple and more complex cases without over optimizing one over the other.
Interestingly the most schizophrenic discussion of the notion of a service can be found in a single source - the UML 2.0 specification. Here are a selection of the entries I found when I did a search through the specification for the word service.
From the glossary:
A feature which declares a service that can be performed by instances of the classifier of which they are instances.
From the definition of Implementation
The set of interfaces implemented by the classifier are its provided interfaces and signify the set of services the classifier offers to its clients.
From the definition of Interface
An interface declares a set of public features and obligations that constitute a coherent service offered by a classifier.
From the definition of Component
A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components or services in the system in terms of its provided and required interfaces.
From the definition of Connector
The interface compatibility between provided and required ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services.
From the definition of Port
A Port may specify the services a classifier provides (offers) to its environment as well as the services that a classifier expects (requires) of its environment.
The isService property of Port
If true indicates that this port is used to provide the published functionality of a classifier; if false, this port is used to implement the classifier but is not part of the essential externally-visible functionality of the classifier and can, therefore, be altered or deleted along with the internal implementation of the classifier and other properties that are considered part of its implementation. The default value for this attribute is true.
The service stereotype in the Intermediate profile
A stateless, functional component (computes a value).
The EJBService stereotype in the J2EE/EJB Component profile
Indicates that the Interface is an EJB Service interface that is exposed as a webservice definition.
So, be warned, whichever stand you take on this you will upset someone, on the other hand it is usually true that if you don't upset someone with an idea then it's probably not a useful idea :-)
- It seems that there is a rendering issue with this page using Firefox on Windows; it seems to work fine with IE on Windows, Safari on MAC OS X.