James Governor of RedMonk
commented on What is a Web Service?
, quibbling with my statement that SOAP is the "most common" technology for implementing Web services. He makes a good point; at the same time, I stand by my statement.
As I've already noted in REST vs. SOAP/WSDL
, Amazon claims (according to Tim O'Reilly) that its AWS traffic is 85% REST, 15% SOAP. So REST proponents claim anecdotal evidence
like this means REST is more popular.
They may be right--if SOAP and REST went up against each other in the People's Choice Awards
(or their technical equivalent, the JDJ Reader's Choice Awards
), REST might win the popular vote. Hobbyists seem to prefer REST.
But I'm interested in the enterprise application
market, not the hobbyist market, and enterprise applications that use Web services use SOAP. I consult with customers using IBM J2EE products (WAS
, etc.), and they're using SOAP. JAX-RPC
, support for SOAP over HTTP and WSDL Web services, is part of J2EE
. J2EE doesn't have any support for REST, unless you count servlets
(which is kind of all you need for REST).
So the logic is kind of circular--J2EE supports SOAP, not REST; so that's what J2EE apps use--but nevertheless, that's how I see enterprise applications implementing Web services these days. SOAP is the established standard, REST is the opponent fighting SOAP for mindshare and trying to gain supremacy. Maybe it will; we'll see.
But for now at least, SOAP is the "most common" Web services technology.
As I've discussed previously, the Web 2.0 approach
gives Web apps a Web services API so that the app's functionality can be invoked programmatically. Which then raises the question: What's a Web service?
In the Web 2.0 sense, a Web service is just some technology for invoking an application's service across the Web. The most common approach today is SOAP
. However, many people believe that SOAP is too complex; they tend to prefer REST
instead. Some diehards still use XML-RPC
, the predecessor to SOAP which also came before REST. Amazon's AWS supports
both SOAP and REST.
Wikipedia's list of Web service markup languages
(which I updated
) lists these and others, such as BEEP
. It also lists a bunch of related XML schemas used with Web services that aren't actually for invoking Web services, like WSDL
(for describing interfaces), UDDI
(for locating service providers), and BPEL
(for programming sequences of service invocations).
The point is, when I talk about Web 2.0 and giving Web apps a services API, not just an HTML GUI, I'm using the term "Web services" loosely to mean programatically invoking an application's service across the Web
. (Google has a similar definition
.) The format may be SOAP or just XML-RPC. The whole approach could be REST, which is more format independent. The transport is presumably HTTP, because that's what the Web runs on today, but perhaps even that will change someday.
The important trend of Web 2.0 is Web applications making their services available for direct, programatic invocation. The technology may change over time, but the need will probably only grow.
In a comment to ESB for Architects Article
, a reader asks: Could you clarify how to actually use DNS Endpoint Discovery, as advocated in the last paragraph, to find the right entry point with WAS 6 SIB?
I'll let James handle the DNS Endpoint Discovery part of the question, since he's the big advocate of that. In the meantime, see DNS Endpoint Discovery
, UDDI and DNS-EPD
, and More on DNS Endpoint Discovery
As for the SIB, and application doesn't really need to discover a bus instance. If you want an app to be able to access a bus instance, you deploy that app in an app server/cluster that is a bus member of that bus. Then the app simply has access to the bus by using a JMS connection factory configured for that bus. See pub/sub in the SIB
article and "Deploying message-driven beans and JMS applications into the Service Integration Bus
."Service Integration Bus
There's still the issue of "how does the app know what queues are available?" In JMS, this is hard coded through resource references
and JNDI bindings
. However, I believe apps will need to be able to bind to these resources more dynamically; see ESB vs. Message Bus
. I envision an ESB with a UDDI-like service; an app wanting to invoke a service passes its description (WSDL, perhaps) into the ESB's UDDI, which returns the bindings for the JMS/messaging channels for invoking the service. The app then uses those channels to make the request and receive the response. How would you find the ESB and its UDDI service? For that, you might need DNS Endpoint Discovery, or you might be able to just use pre-configured connection factory.
has released a new tool, the Performance Harness for Java Message Service
From the description:
It provides a complete set of JMS functionality as well as many other features such as throttled operation (a fixed rate and/or number of messages), multiple destinations, live performance reporting, JNDI, and multiple vendor plug-ins.
The author, Marc Carter, is on the WebSphere MQ
development team and wrote the performance harness to analyze WMQ. He has also authored the JMS Performance with WebSphere MQ for Windows V6.0
and JMS Performance with WebSphere MQ V5.3 on Windows 2000
In the August IBM WebSphere Developer Technical Journal
, there's a new article, "Deploying publish and subscribe applications into the Service Integration Bus
What's so interesting about this article? For one thing, it's by me and a co-author, Roland Barcia
. For another, it's on a rather interesting topic: How to do JMS publish/subscribe
messaging using the Service Integration Bus
in WAS 6
. So, check it out.
It's been awhile (since June/July
(PDF), actually), but the August edition of the IBM WebSphere Developer Technical Journal
is now online.
In The EJB Advocate
, Geoff Hambrick documents a discussion he had with some really smart young fellow about where to implement the code for producing DTOs. Scott Johnson talks about how to be a happy programmer
. Roland Barcia is this month's Meet the Experts on developing apps on RAD 6
Scott Simmons introduces the WebSphere Integration Reference Architecture
, which among other things shows how an ESB fits into your apps. Several of my fellow ISSWers have an article on advanced authentication in WAS
(they're in favor of it!). Rachel and Andre continue their building an ESB
series, and there's an article on custom portal code performance
And there's an article on doing pub/sub in the SIB that I'll talk about next.
I've discussed how REST and SOAP/WSDL
compare, and sidestepped the issue of which alternative is necessarily better. But I think I have a simple litmus test
you might want to apply.
It seems to me that REST is not object-oriented.
Here's why I think REST is not OO. Recall that the best way to implement a service in J2EE
is with a stateless session bean. A SSB is one object that provides a group of related services/operations, such as everything you might want to do with your bank or bookstore. A client looks up an SSB, invokes services to its heart's content, then discards it. The services are meaningful domain operations, such as
REST doesn't work this way. You'd have a URL for the shopping cart and another URL for the book. Which do you use? You could tell the cart "add book X" or tell the book "add to my cart," but REST doesn't have operations like that, it just has GET and PUT. So I suppose you do something like this:
- GET the book from its URL to get its UID
- GET your shopping cart from its URL
- modify the shopping cart document to add the book
- PUT the shopping cart back to its URL
Who thinks that's fun?! Is there a better way to do this in REST? That's definitely not simpler than
So I don't necessarily want to say that SOAP and WSDL are the most OO protocol imaginable for Web services, but they seem a lot better than REST. The more OO web services are, the better, and SOAP/WSDL seems like the better of the two approaches.
Which is the simpler approach for implementing web services, REST or SOAP/WSDL? I've been thinking about how they compare.
Supporters of the REST approach claim that it's simpler than SOAP. (By SOAP, we really mean SOAP and WSDL, since SOAP is just a data format, not a service.) Amazon Web Services
implements both, and there are claims
that 85% of the AWS traffic is REST (therefore only 15% SOAP). I have no idea if these numbers are accurate, or how they change over time, but let's suppose they're accurate. This is the main REST drumbeat, that REST is simpler than SOAP.
So is REST simpler? Hmmm, from who's perspective?
REST leads to lots of little URLs--one per remotely-accessible object, plus URLs for listing objects and creating new instances. For example,
could provide access to the
instance whose ID is #12345. No non-trivial app can nor should have that many static URLs or HTML/XML/whatever pages, so the way REST works is to map lots of logical URLs to objects/resources in the app. This puts complexity on the client to figure out which of a seemingly endless list of URLs to invoke for the desired behavior, and puts complexity on the host to map this vast set of URLs to useful behavior or objects. SOAP has fewer URLs, basically one per port type defined in WSDL.
Thanks to all the URLs in REST, each URL's behavior is pretty darn simple. There are only four operations: GET, PUT, POST, and DELETE (although it appears that POST can be overloaded to do lots of things depending on the request document; see What is REST?
). So assuming the operations' behavior is truly as intuitively obvious as it's supposed to be, once you've got the URL, invoking the behavior should be simple. A SOAP/WSDL service has fewer URLs, basicly one per port type, but lots of operations, as listed in the WSDL.
SOAP and REST seem to agree on XML as the data format of choice. But a SOAP/WSDL format requires a particular XML schema for the SOAP body (a schema for the request and another for the reply). A REST service, in theory, can support multiple formats; the client and provider negotiate which format to use for a particular invocation. Will these negotiations really make REST simpler? Or will a typical REST service maintain simplicity by only supporting a single format?
These are points upon which learned men can disagree. Do you prefer lots of URLs and a small, constant set of fine-grained operations (REST)? Or fewer URLs, each hosting a larger, application/service-specific set of potentially course-grained operations (SOAP/WSDL)? Do you want to support one set of XML data formats (SOAP/WSDL) or potentially negotiate the data format every time (REST)? Which do you think is simpler?
Some other thoughts along these lines:
A reader recently asked: Which web sites (if any) do you frequent to keep up with Java goings-on?
Hmm, that's a good question. Here are a couple you might want to check out.
I do a lot of my learning by reading books, so one of my very first blog postings was What You Should Be Reading
. This is a theme that has come up a number of times in my blog, so Google for that
. Likewise, check out a frequent recommendation of mine, the ISSW Recommended Reading List
, which is mostly articles and web sites, not books, so that they're freely and immediately accessible.
The reader proposed one possibility for a good web site to learn about Java: The Server Side
. I tend to find The Server Side to be kind of a super market tabloid of a Java news site; more interested in shocking than educating. There, I've said it, let the hate mail begin. (sigh) When I peruse The Server Side, what I find is lots of announcements for new versions of frameworks I've never heard of, which doesn't make me feel more knowledgeable about how to use Java. To anyone who wants to defend The Server Side: What would be useful is for you to highlight sections of the web site for learning about Java, and thereby prove what a good educational site it is; I'd like to know.
There are other Java web sites which tend to be educational and helpful. My collegue Kyle Brown publishes and comments occasionally
, which seems to actually have informative articles. Along the same lines, jGuru
seems good. A performance-specific site is Java Performance Tuning
; a similar site is Precise Java
. (Also in the Google list of Java performance sites
is one called Nawa Shibari
, but judging from the root page, I'd say it seems to be something very different! Is this where Java performance enthusiasts go when they're not tuning Java?!)OnJava
is O'Reilly's take on things. Javalobby
is kind of the closest thing Java has to a political action committee
. And finally, at the risk of simply endorsing my own employer, there are lots of good articles in the developerWorks
' zones on Java
, WebSphere Application Server
, IBM WebSphere Developer Technical Journal
, Rational Application Developer
(and the older WebSphere Studio zone
), and so on.
That should give you some stuff to browse for a while. Hope you find it helpful.
Aug 23 Update:
Another helpful site is java.net
, run by Sun as a newsie addition to the main Java Technology
I've talked about the REST
approach for web services. Does REST work with WSDL?
Individual web services are typically described with Web Services Description Language
(WSDL) documents. WSDL describes a web service in four parts:
- Port type -- The service and its ports/operations
- Messages -- The format of the requests and responses
- Types -- Custom data types beyond the standard primitives defined by the WSDL spec
- Bindings -- The address of the host providing the service
WSDL is independent of SOAP
, but closely related to it, since the request and response messages are usually assumed to be formatted as SOAP.
So do WSDL and REST get along? Some say sure, some say "no way," and others say "why bother?" It seems to depend on how deeply you drink the Kool-Aid
on REST. Seems to me that the port type section doesn't do much for REST, since the operations are always GET, PUT, POST, and DELETE. The port type would just specify which of those four verbs are supported. The bindings section might be useful for finding the hosts of REST services, but that pre-supposes those services are described by WSDL and can be looked up in something like UDDI
Which leaves the messages and types sections of WSDL. Here there's a fair bit of disagreement between the SOAP and REST philosophies. SOAP is more strongly-typed, saying "Here's the format; take it or leave it." REST is looser; a single service might support multiple formats; the client and host negotiate which format to use for each transaction. The REST message formats are assumed to be XML, but even that's an implementation decision. The SOAP body is an XML document (specifically, the root element). So SOAP and REST agree on XML, but SOAP specifies only one XML schema whereas a REST service may support many. WSDL for a REST service would specify only one XML schema, therefore limiting its flexibility.
So, does a REST service even need the flexibility to support multiple XML schemas? If it can settle on one request/response format pair for a particular operation (GET, PUT, or POST; DELETE doesn't need data), then it seems to me that the REST service can be described with WSDL.
Web services are generally thought of as SOAP over HTTP. Another approach is XML-RPC.XML-RPC
is an alternate web services technology, a simple technique for invoking an application's method or procedure by sending XML documents in HTTP packets. Sound kind of like SOAP? Well, XML-RPC is the predecessor of SOAP. Apparently Microsoft thought XML-RPC was too simple, added more functionality, and gave the more complex technology the perhaps misleading name/description: Simple Object Access Protocol (SOAP).
XML-RPC has gone out of favor. People seem to prefer either SOAP
For more info:
Web services are generally thought of as SOAP
over HTTP. Another approach is REST.
An alternative web services technology is Representational State Transfer (REST)
, an approach that tries to be much simpler than SOAP. The idea is that HTTP isn't just the transport for a web service, it is the web service. By this definition, the web itself is a REST system.
With REST, each resource/object exposed to the web has its own logical URL for accessing it. (The web server maps the URL to the object so that each object doesn't need its own static page or predefined URL.) The services are the HTTP verbs GET, PUT, and DELETE, for viewing, updating, and destroying the object. (There's also POST, which is a heck of a lot like PUT.)
I haven't programmed in REST (yet), but from what I've read, a REST web service for browsing and ordering products might work like this:
The HTTP request and response can contain any HTTP data. It's usually XML (MIME type
), using schemas defined by the services provider (
in this example). A service may support multiple data representations, then negotiate with the client to determine which to use for that particular client.
A common debate theme within the REST community is how the HTTP verbs (GET, PUT, POST, and DELETE) are supposed to work in a web services context. People describe their services as "I think this is RESTful," meaning that the URLs represent resources and the service implements the verbs properly/as expected. But the developers often seem uncertain of themselves, debate the tradeoffs, and sometimes disagree.
There is no formal Java API for using REST. It's so much like good ol' HTTP, perhaps you don't need a new API or library, just a servlet that performs GET, PUT, POST, and DELETE as defined in REST. (I don't think you can necessarily assume that the average Java servlet is automatically REST compatible!) There's support for REST in Apache Axis 2.0
and an article on implementing REST in Java, "The REST of the Web
For more info:
Aug 18 Update:
On advice from my commenters (see below; thanks for the comments, guys!), an HTTP GET should have no side effects (makes sense). Creating an order so that it can be returned is obviously a side effect, so GET is not appropriate. Seems like if you wanted your web site/web services to be read-only, you'd only support the GET verb.
Accordingly, I've changed the single GET command that I imagined would create and return an order to two commands: a POST to create the order, which returns the URL for the order, and then a GET to retrieve the order. Two commands instead of one seems like more work, and is definitely more round trips across the network, but apparently this is the way REST (and HTTP) works.
I'm still not clear on the difference between PUT and POST. Notice that I now POST to create an order and PUT to update it. Is this correct?
Not to get grouchy here, but REST is supposed to be simpler than SOAP. Seems like when the verbs are somewhat unclear like this, and when it takes multiple commands and round trips to perform one logical action, it takes away from the simplicity.
Aug 20 Update:
Again, thanks to my commenters for helping me understand REST better.
OK, so PUT is like a setter method (and GET is like a getter method; duh). POST is like "perform an action." This is a true service method, where the service can be anything. It's like document-style SOAP (not RPC-style), where you don't tell the receiver what to do, you just pass the receiver some data and say "process this," and the receiver figures out how to process it.
So GET, PUT, and DELETE are pretty straightforward, actions performed on the resource/object specified by the URI. POST is the miscellaneous verb, telling the resource to do whatever processing it thinks is appropriate.
Where is this stuff documented (besides trying to decipher the HTTP spec)? Seems like there ought to be a simple "REST Style" guide that explains this pretty briefly, but I haven't found one.
I appreciate both commenters' insights, but I found this suggestion a bit concerning: Use the HTTP 201 (created) response
, put the URI for the new order in the response's Location response-header field
, and put the order XML doc in the response's entity-body
. I'm kinda impressed by how creative this approach is, but again it confuses me even more as to why proponents seem to think that REST is so much simpler and easier than SOAP. You need to not only understand these HTTP verbs, but also status codes and header fields? Seems to me that any particular provider's REST services are going to need a lot of documentation, not unlike SOAP or Java or any other programming. How's this simpler?
Web services are generally thought of as SOAP over HTTP. So just what is SOAP?
The most common web services approach right now is SOAP
, where request and reply messages
formatted in the SOAP schema for XML
are passed between computers using the HTTP transport. The overall specifications for how this web services technology works is defined as the WS-I Basic Profile
, which defines more clearly how the World Wide Web Consortium
(W3C) specs go together.
Java has web services APIs
specifically for supporting SOAP processing: JAX-RPC
support using SOAP RPC to invoke Java methods. SAAJ
supports sending XML documents over the web (document-style SOAP
Some places to learn about SOAP:
IBM has announced
the availability of WebSphere Extended Deployment V6.0, WXD for WebSphere Application Server 6.0
. The announcement letter
) contains more details.
I've previously talked about what WXD is
(and is not
). The WXD 6.0 product page
is online, with links to the WXD 6.0 library
and the WXD 6.0 InfoCenter
. The WXD 6.0 new features
page lists these additional capabilities:
- Long-running workloads -- batch processing in J2EE
- Object grid -- data sharing between apps
- Application edition manager -- rolling deployment of new app versions
- Flexible goals-directed workload management
- Enhanced visual operational and health monitoring
- Mixed server environment support -- works with non-WAS J2EE app servers!
Here are a bunch of articles about WXD 6.0:
What can an ESB
do for you?
Bob Sutor has a great blog posting, The Eight Defining Concepts of an Enterprise Service Bus
, incremental integration
, qualities of service
, event orientation
, and service orientation
. (That's eight; you can count them.) In ESB vs. Message Bus
, I've pointed out two qualities that Web services have that services in an ESB need: the services should be self-describing
. I've even said that an ESB is like a network of roadways
OK, that's all great. But what does an ESB actually do for you? What features can an application using an ESB, or applications integrated by an ESB, or parts of an SOA integrated by an ESB--what features does an ESB have that those app(s) (parts) can make use of?I believe an ESB provides apps with four main capabilities
- Synchronous service invocation -- Like how SOAP over HTTP, JAX-RPC-style Web services work
- Asynchronous service invocation -- Messaging, like how JMS request-reply works when the request is a command message
- Data transport -- One-way transportation of a data structure from one process to another; see document message
- Event notification -- One-way transportation of an event notification from the process where the event occurred to other processes that are interested; see observer, publish/subscribe channel, and event message
So with an ESB, applications can invoke services synchronously and asynchronously, transport data, and perform event notification.
Also check out IBM Info on ESBs
and What is wrong with UDDI?
There's a new article on the developerWorks SOA and Web services
section, "Simplify integration architectures with an Enterprise Service Bus
" by fellow blogger James Snell
and yours truly. It discusses how an ESB fits into your architecture and can simplify the rest of your architecture, making analogies to similar Java programming techniques. It even has pictures. Check it out.
This probably isn't any new info, but let's make sure we're on the same page here, especially since I haven't seen this discussed extensively anywhere; it's just assumed. The way you implement a service in J2EE is with a stateless-session bean.
A stateless session bean
(SSB) is a kind of EJB
that manages a user's access to an app's domain model
. As an EJB, an SSB manages overhead issues like sharing of instances, thread reuse, transactions, and security; this lets the SSB developer focus on implementing code for business logic. Because an SSB is stateless, a user only cares about using an instance from a pool of the same type; since all instances are the same, which one a particular user gets makes no difference.
For example, a banking SSB might have methods like
. Each method is stateless, so it needs appropriate arguments like account IDs and payment info.
Services are also considered stateless; all state must be passed in as parameters. Web services are stateless, HTTP itself is a stateless transport.
So in J2EE, it makes sense to implement a service, such as a web service, as an SSB. If the service transport is HTTP, it's easy to add access to an SSB by implementing a service activator (EIP
), which in J2EE for HTTP is a servlet
. If the transport is JMS
, use the service activator pattern again, but this time implement it as an MDB
. A J2EE 1.4 container can expose an SSB as a JAX-RPC web service directly
; the container acts as the servlet.
Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.
Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean
. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.
So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.
I've been talking about
what Web 2.0 is (or at least what I think it is). I think it's going to have a significant impact on another area of computing, pervasive computing.Pervasive computing
is the idea of lots of little computers--PDAs
, dashboard systems, Dick Tracy
wristwatches, etc.--that make computing and data available anywhere, anytime, conceivably embedded into any appliance or accessory. A problem with pervasive devices is the seemingly endless variety of UIs needed--based on screen size, resolution, whether there even is a screen, etc. The approach so far has been either for the device to display a standard web page (and require a lot of scrolling on a small screen) or for web sites to be designed to support small screens and limited bandwidth with alternate GUIs just for pervasive devices. Each approach puts the burden on either the user or the site developer.
Web sites with APIs--Web 2.0--should help resolve this problem. The site makes the data available but lets the device--which knows its screen size, resolution, etc.--decide how to display it. The device can even detect its bandwidth and adjust its data requests, graphics requests, etc. accordingly. The device can even choose a non-visual UI, such as an auditory UI for a car dashboard. The site concentrates on one API, Web 2.0; the user gets a UI that makes sense; the device's client app, which can more easily be different for each different device, makes up the difference.
One catch is that for a particular device to be able to display most any web site, the sites will need standard APIs so that the device knows what to expect. (As usual, as much as we're actually solving the problem, we're also kind of just moving it around.) Another catch is that the device will need the processing power to apply an XSLT stylesheet
to the XML data to display it. But this probably isn't much more CPU intensive than parsing HTML and displaying it.
So, you heard it here first (or has this already been said elsewhere?): This whole Web 2.0 thing is finally going to help make this whole pervasive computing thing really work.
I've talked about
how Web 2.0 makes web sites available through web services APIs. Another way of looking at all this is in terms of the MVC paradigm/pattern.
(MVC) approach separates an application's model from its view. The model is the app's data wrapped by the functions/services it performs. The view is a UI for displaying the model to the user. An app should use MVC to separate its view(s) from its model, so that the model can support multiple views, can run without any views (headless), and so that changes to the model's implementation don't affect the views' impls and vise versa.
As I've described previously, the only interface (most) web applications have is an HTML web GUI. The app should also have a programmatic API that can be invoked across the web via web services. In fact, the web GUI should be built upon the services. In practice, the web GUI probably won't use the web services APIs and instead will use something much more efficient such as simple/local or remote Java calls. Also, the web GUI may need access to services/functionality in the app that is not made publicly available via web services. Nevertheless, the idea is to apply the MVC approach to web apps, to separate the web GUI view from the app model; then the app model's services can be exposed as web services, so that Web 2.0 client apps can invoke the services programmatically.
I've used Wikipedia
a lot, but only for reading. I've never edited any of the pages, until now.
What did I edit? I changed the List of Web service markup languages
page to add a reference to the REST
page. I also updated the REST page to link to the pages on Web service, List of Web service markup languages, and Comparison of Web service markup languages. Wow, think of all the value I've created!
I hope this experience will be better than Bob Sutor's
, where his changes got taken back out again. Wikipedia users have a reputation
for policing the site, and it sounds like they sometimes overdo it. My changes are still on the site right now, but if they're not by the time you look for them, you'll know what happened.
BTW: Why was I reading the Wikipedia page on REST? Stay tuned.