Here is a definition of a service:
A service is a contractually defined behavior that can
be implemented and provided by a component for use by any
component, solely based on the contract.
There are several important points in this definition. Services
are provided and used solely based on a contract. This means
that the contract is not tied to a particular platform, protocol,
or discovery mechanism. This is what allows any service to be
used by any other service. There are several core principles
behind SOP:
- Everything is a network appliance or network service.
- Think about the services first.
- Maintain interoperability of services over time.
- Design for availability by discovering services and using
containers.
- Design components to be deployed and used in different contexts.
Principle 1: Everything is a network appliance or network
service.
It is the goal of Openwings to provide a network-centric view
of devices on a network that allows complete adaptability and
growth. Today, most devices that connect to your computer or
network require configuration or drivers. Openwings allows these
physical devices to become plug and play network appliances.
This is done by bundling Openwings software components with the
physical hardware components. A network appliance should only
require two connections: power and network.
Network services can be any contractually defined and published
service. This is not limited to jini services, web services,
or legacy services.
Principle 2: Think about the services first.
There are two key enables to Service Oriented Programming:
- Service Contracts
- Mobile Code
Any interface between components can be seen internally as an
application level method call. For synchronous, remote method
invocations this becomes obvious. For asynchronous messaging
this is a little more difficult to see. The following diagram
shows how this abstraction can be achieved.
This technology will allow us to move into a world of off the
shelf hardware components that can be easily integrated together.
Principle 3: Maintain interoperability of services over
time.
There are several ways to maintain interoperability of services:
- Provide the user interface for your service as mobile code.
Service User Interfaces can be attached to any service. By doing
this no knowledge of your service is needed to use it. ServiceUIs
can be provided for various types of user devices. This provides
a distributed Model View Controller pattern.
- Agree on the contract not the protocol.
One of the key reason component markets have not developed is
that components are typically developed to only work with one
protocol. The message with this point is to be protocol independent
through the use of connectors.
- Extend existing contracts.
By using interface inheritance backward compatibility is easily
maintained.
- Publish legacy interfaces.
If inheritance is not possible, one can still publish multiple
interfaces.
- Provide adapters for legacy interfaces.
Another way to support legacy interfaces
is to provide a simple adapter that maps the old interface to
a new interface. The adapter listens for service with the new
interface and publishes the old interface.
Principle 4: Design for availability by discovering services
and using containers.
Service Oriented Programs can easily fail over between services
by using service discovery. Service lookup can be done by interface
or attribute. Containers provide for life cycle management of
components. Containers can restart failed components or move
them around a cluster for availability or performance reasons.
Principle 5: Design components to be deployed and used
in different contexts.
To achieve true off-the-shelf components that interoperate, components
must not hard-code details of their deployment environment or
context. Openwings has an installable Jar format that is platform
independent. Openwings components also provide platform independent
execution descriptions, called Installable Component Descriptors
or Component Descriptors. This allows Openwings components to
be installed and run on any platform.
Component developers have a responsibility to avoid hard coding
details of their deployment environment. This allows their components
to be used in new systems in ways they may not have envisioned.
Developers should package elements independently so they can be
reused. This includes user interfaces, executable components,
and interfaces.
Basic Process
The basic process for Service Oriented Design is as follows:
- Understand your requirements (get some or write some).
- Draw a networking diagram showing you network elements (this
is important for large systems). This will identify the network
appliances and computing resources available.
- Make a list of services you will need.
- Make a list of User Interfaces you will need on various devices.
- Make a list of components.
- Draw your ADL diagram to layout your components and services.
Create a deployment diagram also.
- Write your service contracts (interfaces).
- Design your components (UML is recommended).
- Implement your components.
Next: Defining
Service Contracts
