What is Service?
A service is an Independent system
which accepts one or more requests and returns one or more responses via a set
of published and well defined interfaces. A service
is
implemented by one or more components, and is a higher-level aggregation. COM
or COM+ (Learn more about COM+ component of .net,Learn more about COM component of .net)components functionality limited within homogeneous environments;
service orientation fills the gap by establishing reuse in heterogeneous
environments (.net service can communicate with java or another client) by
aggregating one or more components into a service. Service communicates through
message using open standards (Use XML).
What is Service Oriented architecture?
In reality,
SOA is a collection of well-defined services. Basically SOA use loosely coupled
service to get the desire result easily. Implementation details of a service are hidden
from the client/consumer so any change in the implementation doesn’t affect the
service until the contract between them is change. Service providers are
components that execute some business logic based on predetermined inputs and
outputs, and expose this functionality through an SOA implementation. This
allows systems based on SOA to respond more quickly and cost effectively for
the business. The main difference between component and SOA is that, SOA
provide a open standards message which is not specific to any programming language
or platform. As a result, you can achieve a high degree of loose coupling and
interoperability across platforms and technologies. In a traditional
client-server world, the provider will be a server and the consumer will be a
client
Note:
Tight coupling is when a group of classes are highly
dependent on one another. This scenario arises when a class assumes too many
responsibilities, or when one concern is spread over many classes rather than
having its own class.
|
Loose coupling is achieved by means of a design that
promotes single-responsibility and separation of concerns. Interfaces are a
powerful tool to use for decoupling. Classes can communicate through
interfaces rather than other concrete classes, and any class can be on the
other end of that communication simply by implementing the interface.
|
Figure 1–1. How SOA components interact with each other
Picture description:
A repository contains a description of the services, where the providers register their services and consumers find what services are provided.
Service orientation defines loosely coupled autonomous business systems (or services) that exchange information based on messages. The term services are used in many contexts, but in the context of service orientation, a service is based on four fundamental Principle proposed by the WCF team of Microsoft, in the following sections.
1: • Know your boundaries: A well-defined public interface
is the main entry point into the service, and all interactions occur using
that.
• Services
should be easy to consume: It should be easy for other developers to consume
the service. Also, the service interface should allow the ability to evolve
over time without breaking existing consumers of the service.
• Keep the
service surface area small: As the number of public interfaces grows, it will
be difficult to consume and maintain the service. So interface accept well
defined message and respond the same.
• Don’t
expose implementation details: implementation details kept internal since it
uses loose coupling between the consumer and the service.
2: Services need to be isolated and autonomous. The
design principles to keep in mind for the second tenet are as follows:
• Service versioning and deployment are
independent deployed system.
• Contracts
should not be changed, after publish.
3: Services Share the Schema and Contract, Not the
Class Services interacts using policies, schemas, and behaviours instead of
classes, which have traditionally provided most of this functionality. The
service contract should contain the message formats (defined using an XML
schema (Learn more details about XML)), message exchange patterns (MEPs, which are defined in WSDL (what is WDLC?)). The
biggest challenge you face is the stability of the service, once it has been
published, which can become difficult to change without impacting any of the
consumers. The design principles to keep in mind for the third tenet are as
follows:
• Service contracts constituting of message
format (define using XML Schema), Message exchange pattern (define in WSDL),
and the policy remain same.
• Contracts
should be as explicit as possible; this means if any change in contract for
newer version of the service then it will not affect the old consumer.
• Do not
expose internal data representation publicly; the public data scheme should be
absolute.
4: When we design a service then you should ensure that the
policy assertions should be clear if there is an exception on your service. The
above four principle help us to design a service. If we know the requirement then
properly then it will be very easy to define a service, because that time we
can build the service properly. The individual operation within a service logical
and it will not contradict the service. Similarly if we use the same operation
it is not mandatory to rename it, try to keep the naming as generic as possible.
Naming convention initially is not so important, but when your service
inventory in the organization grow reuse the existing service to achieve
integration within the various groups and systems
Advantages of SOA
Services can
provide a significant benefit because you can achieve reuse at many levels of
abstraction, as compared to traditional methods. SOA can offer reuse at multiple
levels, including code, services, and functionality. This feature enhances
flexibility in the design of enterprise applications.
COMPONENTS VS. SERVICES
It
is natural to be confused about the terms component and service, and what they
mean. A component is a piece of compiled code that can be assembled with other
components to build applications. Components can also be easily reused within
the same application or across different applications. This helps reduce the
cost of developing and maintaining the application once the components mature
within an organization. Components are usually associated with the
object-oriented programming (OOP) paradigm.
A
service is implemented by one or more components, and is a higher-level
aggregation. Component reuse seems to work well in homogeneous environments;
service orientation fills the gap by establishing reuse in heterogeneous
environments by aggregating one or more components into a service and making
them accessible through messages using open standards. These service
definitions are deployed with the service, and they govern the communication
from the consumers of the service via various contracts and policies, among
other things.
