![]() |
Sponsored Link •
|
Summary
Does service oriented architecture mean Web Services? Is Web Services even appropriate as an SOA technology? These and other issues are explored in this post.
Advertisement
|
This post is based on a Birds of a Feather I gave at JavaOne. Thanks to Michael Ogg, CTO of Valaran Corporation, for an earlier presentation that this is based on.
I suppose we should be thankful for web services: we are no longer considered aliens when speaking about service oriented architecture (SOA). In fact, it's even cool to talk about SOA. The company I work for has even recieved RFPs that require SOA. The unfortunate side-effect of all this is that SOA is now often understood as synonomous with web services. This despite the fact that web services are not particularly well suited for the task.
Why mention CORBA? Well, CORBA was the first serious OO-based SOA. Second, it has a lot in common with web services. And, finally, thanks to it's past popularity, the lessons to be learned from the CORBA experience should resonate with many of us.
WSDL and OMG IDL are meta-languages whereas Java is a real language. The distinction is fundamental because it is the interface that enables the semantics.
interface foo
cannot be confused with interface bar
even if all their methods have identical signatures. In web services, there's
no guarantee that a lookup will get the right thing back. All you are doing is
using names.
Java interfaces are polymorphic and the methods have strongly-typed parameters, return types and exceptions. These notions extend to all other classes and interfaces in the language.
If using RMI, an interface's implementing class (aka proxy, or stub) has an associated ClassLoader. This is a powerful feature because we can choose which class to load based on its ClassLoader. If we don't trust the ClassLoader, we don't load the class. Jini 2.0 takes this further by providing means for establishing proxy trust on a per proxy basis. With these mechanisms, a service client can safely load never-seen-before classes.
There are two main problems with langugage-independent IDLs. The first
is that history has shown it is hard to reliably achieve correct behavior
at the endpoints. And secondly,
as I hope to show, an unacceptable number of architecture-critical
features are lost.
Java includes JAAS, a complete language-based security model. This is not
a high-level add-on; it's built into, and enforced by the language. There's
no question how the security patterns will behave when properly used.
Jini Extensible Remote Invocation (JERI) provides a highly-customizable
RMI programming model. JERI provides a set of patterns for establishing
communication transports, for establishing per method constraints (most
notably security constraints), and for exporting them to remote clients.
JERI provides a protocol-independent, secure means of performing RMI-style
interactions with remote services. This is much more convenient and reliable
than a protocol-based, language-mapped system can provide.
Meta-language interface definitions lose all these capabilities.
But (a small part of) the WSDL reveals problems:
First off, there's an obvious difference in complexity and readability.
It's trivial to write a Java interface but even a simple interface is
daunting in WSDL. Thank God there's tools that usually work.
Secondly, and most important, Java's strong-typing means an
If you as a service writer, happen to be using JERI, then you get the
benefit of controlling both service endpoints through mobile code.
This means that even if you
are using a custom protocol, you are in control of how objects are marshalled
and unmarshalled on both ends of the wire. You no longer have to put your
service's reliability into the hands of some unknown entity on the far end
of the wire. You don't need to worry about endpoints that might be out of
compliance with the
protocol, that might have bugs you can't fix, that might not support the
same version of the protocol, or that might even be malicious.
"But the XML stream is ASCII so I can see what's going on."
So when was the last time you had to crack a JRMP stream? Readable
protocols may be good for debugging in the absence of middleware support,
but if you still require human-readable protocols in your application,
then you have more serious problems. Anyway, are
SOAP suds any simpler to read than JRMP? And if you really
want readability, Jini and JERI can give you an ASCII stream
if you want one.
"But in practice, the end-points are Java anyway."
If so, then why go to all this trouble? You're still at the mercy of the
endpoint implementations.
"But I can us HTTP/HTTPS for the transport."
With Jini you can use HTTP/HTTPS if you want to. JERI makes it quite easy to
do so.
"But everyone else is using it."
When it comes to fads, software technologists are no better than teenagers.
We chase the latest thing in hopes it will solve our problems. We falsely
assume the next new technology is a step forward. The facts are that we
work on hard problems, that technology doesn't always take forward steps,
and that "everyone else" are often wrong.
A grid needs a point of entry:
Notice the semantic richness of this example. Furthermore, the use of
dynamic callbacks makes for a much more powerful application. This is beyond
the reach of web services. Inside the Grid cloud, the argument for real
objects is stronger still:
Here's an example of the Active Object Pattern for distributed
objects. Again, this is way beyond the capabilities of web services but
dramatically increases the power of a grid application. Anyone familiar with
Jini is probably thinking, "what about JavaSpaces?" Indeed, JavaSpaces is
an ideal grid service technology that would be very difficult to leverage in a
web services-based grid solution.
Web Services breaks one of the key doctrines identified in the classic
"Note on Distributed Computing": Local vs. remote objects. The argument
made by Waldo, Wolrath, et. al., is that there is a fundamental difference
between local and remote objects and any distributed system that attempts
to hide that difference is fundamentally flawed. At the time, CORBA was the
example of remoteness-hiding, but we can substitute web services and make
the same points.
After all this, it seems amazing that the Globus group would use Web
Services as the basis for a globally distributed system!
Web services has begun to slide down into the trough of disillusionment.
For reference, Jini appears to have
passed through the trough of disillusionment and is climbing up the slope of
enlightenment. (These are my estimates. You can see exactly how the Gartner
Group evaluates them for only $495). How deep will the web services trough be?
Will it find a niche after enlightenment? I think so.
Web Services is a great integration technology (like a modern EDI). It
provides a "common backplane" for weaving together disparate functions and
allowing them to work together. For the IT department, web services is a
Godsend. In that universe, the endpoints can be managed to ensure true
interoperability. Whether web services is better at this than something else,
say Jini, is a arguable. For example, if there's a degree of dynamic behavior,
if services may come and go, then Jini would be better. If the environment
is static, then web services is great.
Web services is a good tool for exporting non-web services to a web
environment. In the IT world, a web-based SOA has the advantage of utilizing
a browser as the client. This can ease development, but there are still
problems. For example, one must standardize on a set of browser primitives
or require a baseline browser. Furthermore, the client is fairly limited
in what it can do computationally. With Jini, the proxy and the UI are
actually written by the service provider and dynamically downloaded to the
client as needed. There is
a base JVM requirement, but in practice, this tends to be easier to manage
than the browser problem. Furthermore, the proxy can contain significant
sophistication that goes beyond what a web service application
can provide.
Web services are not good for complex systems including service
ecologies (SOA). For very simple service interactions, web services may be
sufficient, but they may not be justified due to the cost of implementation
and deployment. The bottom line is that there are too many important
characteristics lost due to the design assumptions of hiding remoteness and
providing language-independence. If you are considering employing SOA, then
consider what's been written here, and consider a pure Java and Jini
approach over Web Services for building your Service Oriented Architecture.
Have an opinion?
Readers have already posted
3
comments
about this weblog entry. Why not
add yours?
If you'd like to be notified whenever Sean Landis adds a new entry to his weblog, subscribe to his RSS feed.
RemoteEventListener
class has the semantics of
the Remote
object. Additionally, objects are serializable
(or not) for a semantic reason, e.g., Socket
can't be serialized
and the language enforces it.
An Example
A simple example compares interface languages and their consequences. The
Java interface is straightforward:
public interface Cookie {
String getCookie(int select) throws java.rmi.RemoteException;
}
<message name='CookieService_getCookie_Response_Soap'>
<part name='response' type='xsd:string'/>
</message>
<message name='CookieService_getCookie__Request_Soap'>
<part name='p0' type='xsd:int'/>
</message>
...
<operation name='getCookie' parameterOrder='p0'>
<input message='tns:CookieService_getCookie__Request_Soap'/>
<output message='tns:CookieService_getCookie_Response_Soap'/>
<fault name='RemoteException' message='tns:RemoteException'/>
</operation>
int
will actually be sent and
recieved. Both service end-points are Java so the protocol is irrelevant and
the "mapping" is always consistent via Java object serialization. If a
malicious client sends a bogus message, the service still throws
IllegalArgumentException
or RemoteException
.
By contrast, WSDL end-points are undefined, so the protocol is all we've got.
We are ensured of the formatting on the wire, but we have no idea what
happens if type='xsd:int'
is incorrectly mapped or unmapped.
Stories We've Heard
Why do people base their SOA on Web Services? We've heard many stories.
Pedagogical Grid Computing Example
I had to look it up: "pedagogical" means for teaching purposes.
This isn't a real world grid solution but it demonstrates some reasons
why web services is not an ideal grid computing technology. In fact,
Grid computing is a perfect Jini application, but somehow it got hijacked as
The Web Services Killer App.
public interface Grid {
public JobId submit(JobSpecification jobSpec,
UserSpecification userSpec,
RemoteEventListener callback)
throws RemoteException, GridException;
// other methods ...
public interface Task {
public void prepare(Object o) throws Exception;
public void setRunnable(Runnable runnable);
public void addListener(RemoteEventListener
listener);
// other methods ...
}
Some Miscellaneous Ranting
If you believe in the power of objects, then you probably realize that
although it has "methods," WSDL is more like a data type (in the C struct
sense) than an object. Much though I dislike CORBA, Web Services is a step
backward. There is no polymorphism or class inheritance. Web Services breaks
the Einstein Simplicity Doctrine: "Everything should be made as simple as
possible, but not simpler." Web services is less simple than CORBA but
weaker in many respects, and we all know CORBA is not simple!
Some Conclusions
I'd venture a guess that web services was the dominant topic at the last
two JavaOne conferences. If you measured the number of sessions or the
number of attendees, I bet web services would win hands down. Clearly the
technology is enjoying widespread interest, but I saw no indication that
there was widespread understanding or satisfaction. As developers are getting
familiar with web services, they seem to be experiencing a degree of
dissatisfaction and even disillusionment. This is a part of the normal
emerging technology hype cycle as defined by the Gartner Group.
The hype after introduction reaches a crescendo at the Peak of Inflated
Expectations and
then drops into the Trough of Disillusionment as reality sets in.
The early adopters
share their painful experiences and drive the interest level back down with
their tales of caution. If the technology has merit, it will find its true
niches and gain mainstream acceptance on the Slope of Enlightenment.
Eventually it will be supplanted with
some new and better technology after reaching its Plateau of
Productivity.
Talk Back!
RSS Feed
About the Blogger
Sean Landis is a technologist and programmer interested in, among other things, mobile and distributed sytems, location-based services, and skiing.
Sponsored Links
|