As its name suggests it, the key element of SOA (Oriented Architecture service) is Service. It is however difficult to make consensus around service notion and it is often difficult to answer this simple question  What a service?  . This subject comes out invariably on, in the choice: A white; a convoluted and uncertain answer; an ignited debate (or a sterile debate).

It would be possible to offer following definition:  A Service is a distributed software component, displaying functionality to strong added value of a domain job  . Unfortunately, such short definitions (although precise) are necessarily incomplete and bring an anthology of questions.

To answer question more precisely, we offer you to review eight aspects which characterise a service:

• Standardised contract: All the services of the same Technical System are displayed through contracts respecting the same rules of standardization.
• Coupling gives way: The contract of a service must impose a cowardly coupling of his clients.
• Abstraction: The contract of a service must contain only information essential for its conjuration. Only this information must be published.
• r utilisabilit : A service expresses a logic agnostic and can so be positioned as a r utilisable resource.
• Autonomy: A service must exercise a strong control of its subjacent environment of execution. The more this control is strong, the more the execution of a service is pr dictible.
• (without state): A service must minimise the consumption of resources by delegating the management of state information when it is necessary.
• D couvrabilit : A service is supplemented by group of m tas given by communication through whom he can be discovered and interpreted in a real way.
• Composabilit : A service must be conceived in order to participate in service compositions.

These 8 aspects come from the book    of Thomas Erl, also author of the site .

In this ticket, we will stay over notion of r utilisabilit .

The r utilisabilit of services (and more widely resources of YES) constitutes one of the cornerstones of the implementation of an orientated architecture service. Indeed, the implementation of SOA aims, between others, at avoiding the wasting of resources by eliminating inherent redundancies in the model in silo. On the other hand, reuse (and therefore the r utilisabilit ) is a first condition of the agilisation of so necessary to the reduction of the time-to-market, the king's main element of the SOA.

Service production r utilisables passes by the combination of the processes of software engineering traditional and processes of industrial production for the consumption of mass. Indeed, even if m thodologues has of cease offering a mode of standard production of computer plans, force is to note that the cycle of production of a computer plan is often specific for it. Software so produced is intended for a definite usage within IF and offer a potential of r utilisabilit quasi everyone. In the opposite, the chaines of production for the industry of mass aims at the production of generic and standardised products giving a strong potential of r utilisabilit .
Objective is to produce a service register giving a very very much potential of r utilisabilit and which is really reused (this second part being often more difficult).

In order to do that, it is essential to apply the concept of centralisation of logic job which wants that every logical function given by IF is accessible only by the single point of entrance (1): the service which implements him. This approach is necessary to the positioning of services as r utilisables resources within the firm.

The combination of (who guaranteed that a consumer has access to service only by his contract (2)) and of this centralisation of logic job allows to get a highly normalised service inventory. The standardization of this inventory is essential to maximise the r utilisabilit (and reuse) of available services within the firm. She will also make easier .

So, the organizational software processes of production owe beings seen again to guarantee the centralisation of logic job. During the conception of a process or of a composite service, these organizational processes have to include a research systematically in the inventory of existent services. If the logic job searched already exists in this inventory, the service which implements it must be reused. Otherwise, his realisation must be made in form of service with an enlarged vision (broader than his simple use as part of concerned process).
That is why, as we explained it in  Implementation of SOA: The keys of success  , the installation of SOA is an effort (an initiative) which must be led of a transverse way. She cannot be treated plan by plan.

The main brake in the reuse of services is the resistance to change and wars of chapel.
As pointed it out Bruno in comment in the ticket  SOA: Of the component in service: The standardised contract  ,  in a multi-partite organisation a service is not used because it exists, but because they have the right to it; and this right is given by one town planners who manage de facto the putting in contact.  . It is indeed case in some organisations. They fall again here into foibles linked to the property of components and to the financing in plan.
It is unfortunately for it that in many structures (notably the broadest), the real reuse of services remains a pious wish.