|
The Glues
So far we have defined the EmployeeService and its interfaces.
We have seen that this interface definition is totally
technology neutral. However, at deployment time we may decide to
one or more instances of this Service supporting different
communication protocol. There is no restriction that the same
Service cannot offer more than one invocation protocol. Rather,
in different situations it is more appropriate to offer multiple
protocol support to provide service to different Consumers.
So far we had the Consumer component and the Service Component
being specified and implemented in isolation. But there must be
something in the middle to glue these two together. We discuss
the missing bits as follows:
Technology
In OO concept, the great thing about interface concept is that
multiple implementations of the same interface can co-exist.
Binding to any particular implementation can happen at run-time
or compile-time. Dynamic binding at runtime offers greater
flexibility to switch between implementations based on context.
For example, an AddressManager Component can be invoked remotely
using Web Service based on XML-SOAP protocol or also can be
invoked as a Pure Java component or EJB when it is invoked
locally.
It is a good design pattern to separate the technology layer
form the actual business logic and business operations. The
business operations can be implemented as a standard Java class.
The technology layer is solely responsible to implement the
technology logic and infrastructural service calls. For example,
in EJB technology, the technology layer will consist of the
EJBs, which will interact with the container to manage
transactions etc. However, the actual business logic may be
delegated to another standard Java class.
Service Discovery and Registry
When a Service interface is implemented using a specific
technology, the Service needs to publish itself to a registry
for the Consumers to lookup and use the Service. This is
implemented as another separate layer called Service Access
Layer. This layer is responsible for looking up Services using
certain lookup mechanism. For an EJB, this layer might perform a
JNDI lookup and for Web Service this layer might use a Web
Service Registry lookup.
Where Happens the Mapping
So far we have said that the Service consumer and the Service
provider specification are independent of each other. This also
meant that the data represented in both these domains can also
be different. So there needs to be a mechanism to align these
two worlds. An ideal place for this mapping to happen is the
Service Access Layer. This layer can receive the data object
from the Service consumer and then use the Service provider
Transfer object to map data. Also this layer can convert any
Exceptions generated into an appropriate one that is understood
and defined in the Service consumer specification.
Who Implements the Layers, the Responsibilities
We have seen that layering the application based on “separation
of concern” is a good way to achieve the loose-coupling between
the Service consumer and the Service provider. We have
identified the layers within Components carrying out different
roles and responsibilities. Looking at the full picture, we can
thus assign the responsibilities to the Service consumer and to
the Service Provider.
Figure 3 The overall picture
The Service Provider component is responsible for providing all
the above mentioned layers. A mistake often made is to make the
Service Access layer as part of the Consumer, which creates a
tight-coupling between the Consumer and the Provider in terms of
technology.
Conclusion
In this article, we have examined the technical aspects of the
Service Oriented Architecture (SOA) and its root in Component
Based Development (CBD). One of the biggest mistakes in the
world of SOA is that they are identified with Web Services. But
it is to be stressed that Web Service is one form of SOA. If we
do not design our Components carefully, we will end-up with a
solution which is tightly coupled with Web Services technology.
In the future, it will then be a big change to move towards
another technology such as Web Service. This sort of situation
defies the very basic goal of SOA that we should be able to
write Consumer and Provider Components irrespective of
technology used in either of them.
In the next part of this series, we will develop a Web service
example based on the Component concept discussed in there.
Please feel free to discuss and let me know your ideas on this.
Thanks.
Benoy Jose is a web
developer with over six years of experience in J2EE and
Microsoft technologies. He is a Sun Certified programmer and
enjoys writing technical and non-technical articles for various
magazines.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
