Reuse of services is usually measured in terms of the amount of extra features makes our service that can be reused in the future and how much of the functionality of the service goes beyond current requirements. This encourages the services that contain additional features that are built around the possible future use of the service. However, quite recently in the design of the service logic in a manner which can be reused for several automate business processes.
Therefore, there is more focus on equipping the services with extra features that really focuses on making the basic service of reusable logic. This leads to the gold plated services, whose development needs more time and effort. This additional functionality that falls outside the original context of operation of the service and cannot even be used at all, since it was built without establishing their needs. Most important of all, the result of SOA would not be able to offer a real service.
Another wrong conception on the reuse of services is that the reuse redirected to the frequency of use. Contrary to this, the actual reuse refers to when the service is used to automate various business processes. This is the real reuse of services.
The principle of reusing service addresses these misconceptions by giving a set of guidelines to help design the logic of the services it contains, which is not tied to any particular business process and therefore can be reused throughout the company to automate multiple business processes. This helps to achieve greater ROI higher.
A service must also be visible throughout the organization. It should be prescribed for use on specific projects in order to avoid redundancy and duplication. Must be associated with the company and is governed throughout the entire life cycle, from design time to runtime. Service reuse must be measured, and should always be related to the corresponding business value, which was the original driver for the development of the service. Strive for reuse at the enterprise level. The logic behind the service should not be limited to the individual concerns of an activity within a single business process, but must address multiple activities in multiple processes across the enterprise.
1) The loose coupling
Loose coupling between service consumers and service providers is one of the most important principles. A loose coupling strategy is to use WSDL for a Web service SOAP or the service interface to limit this dependency, hiding the implementation of the service consumer. The flexible coupling can be addressed by encapsulating the functionality of services in a way that limits the impact of changes in the implementation of the service interface. However, at some point have to change the version management interface and without affecting consumers of services, and managing multiple security restrictions, transport number, and other considerations.
The pattern of mediation, with an enterprise service bus (ESB), will help achieve this goal. Mediation will be docking at the highest level. It’s about creating independence between consumers and providers at all levels, including message formats, message types (including SOAP, REST, XML binary) and transport protocols (including HTTP, HTTPS, JMS). Architecturally speaking, this means that the separation of interests between consumers and suppliers in the transport, message type, and levels of message format. This will promote the reuse and extend the scope of SOA so it can be extended from a single department of the enterprise and beyond. The same service can be reused with security restrictions and different formats. The exposure of services to minority interests is an additional way to promote reuse. This exposure can be to have different messages, different means of transport or special security conditions for the same business service.
Autonomy allows the reuse of services. The more services are independent of each other – with their own resources (databases, legacy, etc.): more reuse and composition is possible with these services. This autonomy also facilitates adaptation to changes in service restrictions in terms of availability, QoS, SLA, scalability, and so on. This also prepare to take advantage of services that virtualization has to offer in terms of dynamic resource allocation. However, full autonomy for each service may not make sense in some contexts. For example, services that access legacy resources are shared with existing legacy clients. Autonomy can be achieved, at the functional level, for all services that belong to the same functional building block. These services can and should be completely autonomous in relation to other services belonging to other functional blocks.
A reusable service should be stateless. You can have a context in stateless execution, but will not have an intermediate state waiting for an event or a callback. The retention of data relating to the state should not extend beyond a request or response service. The state management consumes a significant amount of resources, and this can affect the scalability and availability required for a reusable service.
In some cases it may be necessary to address the status information for the services of conversation, or for long running business processes. Long running processes will have a state and can be invoked as services, but should be considered as special cases and should be referred to composite applications instead of reusable services. (I elaborate on this point later.)
Long running processes should be related to business processes, and have to adapt quickly to business changes. In order to promote flexibility, long processes running not be reused within a service composition. On the contrary, may be invoked or activated via SOAP web services.
The same reasoning applies to submission services. A filing service must be independent and autonomous. A portlet is autonomous and can be integrated and reused in multiple portals. However, a portal that is used for the federation or mashup presentation services may have dependencies that make it a poor candidate for consideration as a reusable service.
Finding the right level of detail has been a primary concern for architects since the beginning of distributed information systems. Within the J2EE and EJB architecture are DTOs (Data Transfer Objects), where employers considered filling several entities, with a call, as valuables. However, we still need your heels on the client side to address the United Nations, bringing together the objects. SOAP have looser coupling, which makes reuse agnostic with respect to the heels of techniques, but it is still necessary to find the correct granularity to promote reuse.
The composition is the process by which the services are combined to produce composite applications or composite services. A composite application consists of the aggregation of services to produce an enterprise portal or business process. A composite service is an aggregation of services it produces another reusable service. It’s like the combination of electronic components to create a computer motherboard, and then use that motherboard on a computer. Think of the motherboard as a reusable service compound is a component of the computer, and computer as the composite application.
Service Component Architecture (SCA) provides a model for creating service components. A service component exposes services, referrals to other services, and has properties common to all services in the component. SCA defines a service based model for assembling services to compose other reusable composite services, and defines the wiring connecting service components within a compound. The compound also exposes services, referrals to other services, and has a set of properties. SCA also defines a way to deploy the assemblies at runtime within a domain multiple SCA.
SCA compounds may have components are running on one or more instances of the Java virtual machine in one or more machines. The composition can be performed using an enterprise service bus that exposes the compound as a service to be used by corporate business processes or composite portals.
While the prescription of services is important as a means of ordering design time service reuse, runtime service discovery is equally important. A repository of business can play an essential role in the reuse prescriptive, while a service registry with UDDI capabilities can dramatically improve service discovery at runtime.