The Artima Developer Community
Sponsored Link

Weblogs Forum
Service Oriented Architectures - Separating Hype From Reality

3 replies on 1 page. Most recent reply: Dec 17, 2004 5:30 PM by Ruth Stento

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Service Oriented Architectures - Separating Hype From Reality (View in Weblogs)
Posted: Jul 12, 2004 4:01 PM
Reply to this message Reply
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.

A Simple Definition

There are a lot of 'definitions' for web services ranging from simple to complex. I like to keep things simple and I believe complexity is often introduced to justify the approach being used. About the simplest definition I have seen for Service Oriented Architecture is an architecture based on services, where a service is a distributed resource that is accessed in accordance with its interface. The keys are the distributed nature, the importance of the interface, and the hiddeness of the resource, whether it be data or program, or both.

Review of Services

A service exposes its behavior (resources) via its interface. The service can be accessed via request-reply or asynchronous messaging, it can have autonomous behavior (e.g., events), and it can be a client to other services. A key point is that the interface is a contract for the service's semantics: A service with this interface behaves like this. The implementation is, well, an implementation detail. You don't know how it was implemented or what language was used, as long as it satisfies the service's contract. So, are all services that follow this pattern equal?

Implementation

All the hype about Java Web Services is just that. It's irrelevant whether Java is used in the implementation. The very name, "Java Web Services," is absurd. True, just as with CORBA, using Java makes implementation almost possible. And mostly thanks to Java, some of the tools are possibly quite good. But the point remains: That a service happens to be implemented in Java is merely an implementation detail.

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.

Interfaces

Web services defines service interfaces using WSDL, an XML-based language. CORBA uses OMG IDL to define its interfaces. Jini defines interfaces using Java. (Jini can be thought of as the "native" Java SOA.) So all three use some form of IDL. Does that mean they are all the same?

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.

Java Interfaces

A Java interface is part of a type system, so 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.

WSDL and OMG IDL

Both OMG IDL and WSDL use language bindings and naming conventions to simulate strong-typing. Thanks to this, all CORBA services and clients are interoperable. That is, except when using different ORBs, or different IDL compilers. Then all bets are off. Why should Web Services be any different? Meta-language-based middleware cannot, by definition, agree on the language at the end-points, therefore it must agree on the protocol. Protocol-based middleware can not be protocol-independent, so you must ask yourself this fundamental question. Which is better: language-independence or protocol-independence? How you answer will define the nature of the SOA you build.

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. In Java you can make use of semantically meaningful design patterns. For example, the event pattern is based on sources and listeners. The 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.

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.

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;
}

But (a small part of) the WSDL reveals problems:

<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>

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 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.

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.

Stories We've Heard

Why do people base their SOA on Web Services? We've heard many stories.

"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.

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.

A grid needs a point of entry:

public interface Grid {
    public JobId submit(JobSpecification jobSpec,
                        UserSpecification userSpec,
                        RemoteEventListener callback)
        throws RemoteException, GridException;
    // other methods ...

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:

public interface Task {
    public void prepare(Object o) throws Exception;
    public void setRunnable(Runnable runnable);
    public void addListener(RemoteEventListener
                            listener);
    // other methods ...
}

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.

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!

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!

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.

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.


Jonathan Harley

Posts: 3
Nickname: jdharley
Registered: Aug, 2003

Re: Service Oriented Architectures - Separating Hype From Reality Posted: Jul 13, 2004 5:43 AM
Reply to this message Reply
You take the position that SOA means 'Services Object Architecture' whereas it is actually about the Services, not the objects.

How one constructs a service is, as you point out, an implementation detail: It could be object-based, but equally, it could be COBOL on a mainframe. You shouldn't care.

If you are in control of both ends of the protocol, you can dictate which protocol is appropriate as well as the semantics of any objects you may wish to pass as part of that protocol.

Many of us however are living in worlds where we control only one side of the protocol and therefore must take the 'lowest common denominator' approach which WSDL based services provide.

I've written custom TCP/IP-based ASCII protocols and while simpler and effective, I still had to write them. With WSDL-based protocols at least there is a standard set of behaviors and tools available. Buy, not build.

SOA over Web Services are not a panacea but then neither is SOA, but it sure makes process-oriented solutions easier to realize.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Service Oriented Architectures - Separating Hype From Reality Posted: Jul 22, 2004 12:38 PM
Reply to this message Reply
> You take the position that SOA means 'Services Object
> Architecture' whereas it is actually about the Services,
> not the objects.

Actually, 'Service Oriented Architecture' is what I take it to be. My focus is on services that are defined by an interface and an implementation. I don't mention objects in the definition I use. Java and Jini are object oriented, and that's important to my position.

> How one constructs a service is, as you point out, an
> implementation detail: It could be object-based, but
> equally, it could be COBOL on a mainframe. You shouldn't
> care.

Correct, but the interface you expose need not be absent of objects.

> Many of us however are living in worlds where we control
> only one side of the protocol and therefore must take the
> 'lowest common denominator' approach which WSDL based
> services provide.

Which is an interface definition. An object-based one at that.

> I've written custom TCP/IP-based ASCII protocols and while
> simpler and effective, I still had to write them. With
> WSDL-based protocols at least there is a standard set of
> behaviors and tools available. Buy, not build.

I'm not sure what your point is. I don't argue to build your own protocol. I argue to avoid standardizing on a protocol. If you use Jini, you can use any protocol you like. You can write it, change it, buy it, or just use a free one. The service writer determines the protocol to use and it is an implementation detail hidden from clients. The agreement is on the interface. We agree it is good to hide the service implementation. Jini extends that concept to protocols.

> SOA over Web Services are not a panacea but then neither
> is SOA, but it sure makes process-oriented solutions
> easier to realize.

Only if you are forced to interact with a web service. If so, you have no option but the least common denominator. Not a very robust way of doing things. My main point is that web services are not well-suited for SOA despite the fact they've gained a strong lead as the implementation of choice. I argue that Jini/Java is a much better solution. BTW, it's straightforward for Jini/Java to interact with web services because protocol is not imposed upon the developer.

Ruth Stento

Posts: 1
Nickname: rstento
Registered: Dec, 2004

Re: Service Oriented Architectures - Separating Hype From Reality Posted: Dec 17, 2004 5:30 PM
Reply to this message Reply
SOA discussions have become as ubiquitous as reality shows. Newsletters and journals must publish at least one article including "SOA" in the title every edition. Every software company simplifies or enables SOA development--of course each uses a different approach. Thank you Sean for applying a purer standard to this overused label!

Flat View: This topic has 3 replies on 1 page
Topic: Comp. Sci. 101: Definition of Type Previous Topic   Next Topic Topic: New Jini Wiki

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use