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
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.
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.
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?
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 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.
Hey, do you use BEA WebLogic Server
? Wish you had a better IDE than BEA WebLogic Workshop
? Wish you could use IBM's Rational Application Developer
with WebLogic? Now you can.
The "IBM Rational Deployment Toolkit for WebLogic feature" (Reference #4009830
; Reference #4010123
) enables you to develop, test, and deploy your J2EE
application for WebLogic using RAD 6.
See also: "IBM Rational Developer products: Powerful support for rapid Java and J2EE development
" by IBM's Stephanie Parkin.
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.
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.
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.
Web 2.0 is a new approach to how the World Wide Web should work: In addition to connecting users to enterprises via web browsers browsing web sites, client computers should also be able to connect to enterprise computers via web services.Web 2.0
is actually the third iteration of the web:
- Static web pages -- It's difficult to remember now, but the reason CERN originally developed the Cello web browser was so that any scientist with Internet access could view the results of particle collisions and decay from the center's particle accelerator. The pages contained both text descriptions of the experiments and pictures of the results. This was a huge step forward in making the data convenient to access.
The site hosting this blog, developerWorks, is mostly (entirely?) static; as are most corporate sites that are just trying to post info for their customers. These pages are like reading a newspaper or highway billboard: What you see is what the other guy viewing the same site sees, and what you see today is the same as what you saw yesterday (unless/until the web master has updated his content). Needless to say, these pages are viewed by humans.
- Dynamic web pages -- These too are viewed by humans, but the content changes depending on the time (without updates by the web master) and the viewer. They're not necessarily very interactive, but are created on demand: Your bank doesn't contain a static web page for every account that the web master updates daily; when you want to see your account, the bank's app creates a web page for you based on today's info. Dynamic pages can also be highly interactive, such as for e-commerce sites, and have effectively become an alternative GUI for applications.
Amazon and eBay (for example) are not merely web sites (in the static sense), they're applications hosted on and exposed as web sites and made accessible through web GUIs. It's gotten to the point now where calling a web GUI an alternative GUI for an application is a bit quaint; traditional thick clients that run outside of web browsers have become the alternative for web-hosted applications.
Likewise today, a client app can interface with a web site by parsing its HTML and invoking the proper URLs, but that's tedious and error-prone. (Interestingly, some web sites prevent you from interacting programmatically using a captcha, that technique where a human user must view and type in a sloppily rendered word that a computer can't read.) The client app needs the web-hosted app to have a programmatic interface. That's web services, and that's the Web 2.0.
So what good does a programmatic web API do you? A simple example is a travel agent app that must interface with the apps for airline, rental car, and hotel companies. The obvious way to do this is via the web, which we humans can do today via the companies' web sites, but which is still tedious and non-standard for a client app to do programmatically.
Taken to its logical extension, Web 2.0 will even change the way we humans use the web. Why does a particular web site have to look the way it does and work the way it does? Say you like Amazon's ability to browse books, but hate the way the web site looks, or hate the limitations of accessing the book catalog using a web browser. No problem. You can use a client app that runs in its own GUI (web browser, thick client, whatever), accesses the data Amazon makes available, and displays it to you the way the client app chooses specifically for you, not the way Amazon chose for everyone. Amazon in fact has web services available, AWS
, which enable you to this; so do eBay
Eventually, thanks to our web client apps, we'll start to lose the concept of web sites. Why should your client app show data from just one web site at a time? Why not have a personal finance app which shows you your bank accounts, mortgage, car loan, and stock portfolio all at once by accessing all those financial companies' web sites simultaneously?
It's the evolution of the information you need when you need it in the form you want it. TV channels mean a lot less with TiVo-style DVRs
. Radio stations mean a lot less with podcasting
. Web sites will mean a lot less with Web 2.0. It's the next iteration of the web.
Some links for more info on Web 2.0:
Also, as for the term "Web 2.0": It's the idea that's important, not the name. As D. Weinberger puts it
: "I haven't been a booster of the "Web 2.0" phrase because it sounded like something a conference organizer desperate for novely came up with." (I guess that desperate conference organizer would be O'Reilly!)
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 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.
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: