Java Reference
In-Depth Information
So how do you arrive at a definition that is specific enough to be useful and yet general enough
to admit the wide variety of approaches that people take in the real world?
Let's examine each aspect of the service definition before proceeding.
Platform-independent interface
The work a service can do must be described with an external interface. Some architects allow
that such an interface can actually be tied to a specific platform, as in the case of a Java inter-
face describing the operations on a remote session EJB. Services can certainly be approached
in this manner, and such an approach may be justified within a given business context. Dictat-
ing that consumers must use a certain platform, such as Java or .NET, to consume a service
can save valuable time and money and drastically simplify your implementation.
Many SOAs operate within a company, behind a firewall, in a known environment that is rel-
atively static. I have talked with architects in such circumstances whose entire SOA is defined
on EJB. That's a very specific platform, and they think they are doing SOA, and they are smart
and experienced people.
Their view is that it would introduce unwarranted developer effort, offer more complexity
than benefit, and garner unnecessary runtime overhead to use SOAP and its many attendant
specifications giventheirbusinesscontext. So while many authors are tempted to indicate that
a service must be defined in a manner that does not dictate platform, and while that sort of
service is the chief topic of this topic, my definition does allow for platform-specific imple-
mentations.
However, a service is generally created to address a systems integration problem, or at least
has an eye toward integration issues. A WSDL is one way to describe functionality in a way
that does not dictate implementation. While WSDLs may commonly use SOAP over HTTP,
this is not a requirement; other protocols can be used for bindings, and the same abstract
WSDL can address a variety of bindings, offering even greater flexibility.
HTTP is perhaps not the ideal transport layer for web-based services, but its simplicity and
pervasiveness have made it the default choice. Consequently, there is considerable support for
such service implementations.
RESTful web services use XML and native HTTP methods to define their interfaces, and this
approach has many proponents who cite the complexity and “bloat” of SOAP-based services.
I want to avoid this argument for now, and just indicate that REST sufficiently satisfies the
condition of platform independence. It is less clear that it satisfies an emphatic interface that
can operate as part of a service contract, however.
Because a service is not merely a piece of functionality, but something describable by a con-
tract that constrains consumers, it is important that a clearly defined interface work with-
