I'm starting to do more work with RAD 6. As with any new release of an IDE, new features have been added and existing ones have been improved (and changed around), so I'm running into some surprises. As I learn how to do little tricks in RAD 6, I'll try to document them here.
RAD 6, officially Rational Application Developer for WebSphere Software, is the successor to WebSphere Studio Application Developer. RAD 6.0 is basically WSAD 6.0. Whereas WSAD 5 is for developing apps for WAS 5 (and WAS 4), RAD 6 is for developing apps for WAS 6 (and WAS 5, and I think WAS 4). Whereas WSAD 5 is built on Eclipse 2, RAD 6 is built on Eclipse 3.
If you don't already have it, you can download a trial copy of RAD 6 to try it out. DeveloperWorks also has a zone to learn more about RAD 6.
Bobby Woolf: WebSphere SOA and JEE in Practice
What's the difference between interoperability and integration?
I found this question in "Outstanding questions regarding BPEL and ESB" on the Richard Brown's Gendal World blog. Richard Brown is an ISSW coworker of mine in the UK and, from what I hear, quite smart. (Then again, he says he reads my blog. But maybe he's still smart anyway!) His blog is really good, BTW. Richard gets the question from James McGovern in a post with the same title, "Outstanding questions regarding BPEL and ESB."
So, what's the difference? Wikipedia says "Interoperability: the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols" and "Integration allows data from one device or software to be read or manipulated by another, resulting in ease of use." Yuck, those aren't much help.
To me, interoperability means that two (or more) systems work together unchanged even though they weren't necessarily designed to work together. Integration means that you've written some custom code to connect two (or more) systems together. So integrating two systems which are already interoperable is trivial; you just configure them to know about each other. Integrating non-interoperable systems takes more work.
The beauty of interoperability is that two systems developed completely independently can still work together. Magic? No, standards (or at least specifications, open or otherwise); see Open Standards in Everyday Life. Consider a Web services consumer that wants to invoke a particular WSDL, and a provider that implements the same WSDL; they'll work together, even if they were implemented independently. Why? Because they agree on the same WSDL (which may have come from a third party) and a protocol (such as SOAP over HTTP) discovered in the binding. How does the consumer discover the provider? Some registry, perhaps one that implements UDDI (which sucks, BTW). So SOAP, HTTP, WSDL, UDDI--all that good WS-I stuff--make Web services interoperable.
Another example I like is the "X/Open Distributed Transaction Processing (DTP) model" (aka the XA spec); see "Configuring and using XA distributed transactions in WebSphere Studio." With it, a transaction manager by one vendor can use resource managers by other vendors. Even though they weren't all written for each other, they still work together because they follow the same spec. They're interoperable.
Now consider two systems that weren't designed to be interoperable, or perhaps interoperable but with different specs. This requires integration. The integration code--could be Java, Message Broker, etc.; I co-authored a whole book on this--takes the interface one system expects and converts it to the one the other system provides. This is why WPS has stuff like Interface Maps and Business Object Maps.
So, you want interoperable systems; integrating them is simple. Otherwise, you have to integrate them yourself.
I'm documenting tricks in RAD 6 and WAS 6. Let me clarify the relationship between the two.
RAD is a development environment (an IDE) from Rational for developing J2EE applications. WAS, from WebSphere, is an implementation of the app server part of the J2EE specification, which you use to deploy and run J2EE applications. You don't need one product to use the other, but they work great together.
RAD includes a test server environment for deploying and testing your applications while you develop them (instead of waiting for your customers to do it!). This test server is a full-blown WAS server. It's not licensed for production use, but it works just like WAS because it is WAS. Whereas WAS is installed in the
This also answers Bill's question: If you have RAD installed is there any reason to also install WAS? (Bill knows the answer; he's just reminding me to give you the answer.) RAD contains a full WAS install for testing purposes, so about the only thing you really need a separate WAS install for is production. To perform load testing and failure scenarios, you really need a set of server computers and software (web and application servers, database servers, LDAP, firewalls, etc.) that mirror your production environment as closely as possible, so RAD (or any single WAS Base install) is definitely inadequate for that. But RAD is perfectly adequate for unit, function, and end-user testing.
The main place where RAD meets WAS is the Servers view in RAD that let's you start and stop servers, etc. Those servers, as long as they're of type "WebSphere v6.0 Server," are WAS 6 servers. The key connecting point is that you can add a RAD Enterprise Application project (an EAR file) to a test server. This way, when you change the code in the project, the new code is automatically deployed to the server (although you usually have to restart the project or the server for the changes to take effect).
Notice that in RAD 6, you can also create a WAS 5.0 or 5.1 test server. This lets you replace WSAD 5 with RAD 6 and start using the latest tooling even if your team is still deploying on an older version of WAS.
The test server in RAD is WAS Base. RAD also has some support for testing WAS ND (Network Deployment), the clustered configuration of WAS which is what most customers actually use.
So for the most part, when I (or anyone else) explain how to do something using a RAD test server, you can also do the same thing from the command line using a WAS install, and vise versa.
I'm documenting RAD 6 issues. There's a new version available, 184.108.40.206, and some interim fixes for it.
RAD has a feature called the Product Updater which finds and installs the latest patches. To run it, from the main menu, select Help > Software Updates > IBM Rational Product Updater. It runs in a separate window and JVM. The first tab, Installed Products, shows what you've got now. The second tab, Updates, shows what's available to install. For example, mine shows that 220.127.116.11 and Interim Fix 002 are available. If you select an update, the Detailed Information pane shows what's in the update.
IBM Rational Product Updater
You can also download and install patches manually, which is necessary if you're running RAD on a machine that doesn't have an Internet connection. Unfortunately, there doesn't seem to be a master "Recommended Updates" document for RAD like there is for WebSphere Application Server, so it's a little more of a challenge to keep up with the latest patches. Two good places to look are the RAD support page and the Rational Developer V6 products page on developerWorks.
Here are the latest patches (currently):
I'm documenting tricks in RAD 6. In Part 1, I explained how Activation Spec is replacing Listener Port for configuring MDBs, and gave some J2EE-spec-based guidance on which approach to use when. Here is some additional advice that is more specific to WAS 6.
In the WAS 6 docs, "Creating a new listener port" recommends that you should upgrade your EJB 2.0 MDBs that use Listener Ports to EJB 2.1 MDBs that use JCA adapters (and therefore Activation Specs). It strikes me that this advice is a little bit empty because your EJB 2.0 MDBs are using a JMS provider, so you can't update to Activation Specs until your messaging system vendor updates their JMS implementation to use JCA. Nevertheless, the advice still holds that if you can update your MDBs to 2.1 and Activation Specs, you should do so and quit configuring your WAS servers with Listener Ports.
Also in the WAS 6 docs, "Administering support for message-driven beans" explains what type of configuration to use with the supported JMS provider types:
It goes on to say that Activation Specs must be used with any MDBs that use JCA adapters. So, the JMS API implementation for (V6) Default messaging is apparently implemented using JCA and therefore requires Activation Specs. The JMS impls for the other providers apparently do not use JCA and therefore require Listener Ports. If and when those other providers are upgraded to JCA, then you'll be able to use Activation Specs.
Which brings to mind another question:
If a JMS provider is implemented using JCA, then you can configure the MDB connection as JCA using an Activation Spec, or as JMS using a Listener Port. Which should you use?
Just for fun, I implemented an EJB 2.1 MDB in RAD 6 to use (V6) Default messaging, but instead of using an Activation Spec, I configured its connection using a Listener Port (which specified a connection factory and destination that were configured in the default messaging provider). When I tried to run this configuration, the server started with no errors. But when I deployed the app and the server tried to start the EJB jar, I got this
WMSG0063E: Unable to start message-driven bean (MDB) MyExampleMDB against listener port MyExampleQueuePort. It is not valid to specify a default messaging Java Message Service (JMS) resource for a listener port; the MDB must be redeployed against a default messaging JMS activation specification.
So when configuring an MDB that listens for messages from the default messaging provider, there's nothing to stop you from using a Listener Port instead of an Activation Spec. But WAS will refuse to run the app. So I guess that's how you'll know when you need to convert your Listener Ports to Activation Specs.
This presents a bit of a dilemma, though. When you're developing an MDB, you're not supposed to know where the messages/events are really coming from. The configuration of the Activation Spec or Listener Port effectively hides this from you and makes it part of the deployment configuration. You just have to know that there'll be a resource in the deployment server with the expected resource name. But now you also have to know whether or not the source will be accessed through a JCA adapter, and therefore whether to configure it with a Listener Port or an Activation Spec. This makes your code, or at least its configuration, a bit less flexible.
For example, if you design your MDB to use WMQ, then you'll need to specify a Listener Port that the deployer will provide to map your MDB to its WMQ queue. But then if the deployer decides to use WAS 6's Default messaging instead, now he'll provide an Activation Spec to map your MDB to its queue. But your MDB isn't configured to use an Activation Spec, it's configured to use a Listener Port. The deployer will need to go modify the
I'm documenting tricks in RAD 6. Something that's changed since WSAD 5 is the concept of a test server and how to create one.
WSAD had the Server perspective. That has been simplified in RAD 6 to the Servers view. The single item in the list of servers is the default WAS 6 test server called "WebSphere Application Server v6.0." New > Server gives you a dialog that creates a new item in the server list. However: Whereas in WSAD this was a separate server that could be started and stopped independently of other servers, in RAD this new server is really just an alias to the server you already had (assuming both servers are for the same type (WAS 6) and profile (default)). Because the two "servers" in the list are aliases to the same server instance, they start together, share the same configuration, etc.
Here's how to create a new separate sever (not just an alias): First, you need to create a new profile. In a file browser (on Windows), find this file and run it:
Once you've created the profile, go back to RAD and open the New Server dialog again. Select the same server type (WAS 6) but specify your new profile (MyProfile) and its SOAP connector port (8881).
When you're done, you'll have a new server (not just an alias) that you can start and stop separately from the other servers, config independently, etc. Since each profile has different ports, you can even run two servers at the same time.
Thanks to Roland Barcia for his help in figuring out how to do this.
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 on JavaRanch, 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, 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 site.
A reader asked: Is IBM going to release Rational Application Developer 6.1? Is RAD 6.1 available now?
The question appears as a comment on WebSphere Application Server V6.1 Announced. IBM_RAD_Customer asks:
I can't use RAD 6.0 to build applications for Websphere Application Server 6.1
Yes, RAD 6.0 does not know how to develop code for the new features in WAS 6.1, such as the new Java language features in J2SE 5.0. To develop code for those features, you'll need to use the Application Server Toolkit (InfoCenter), which is included with the WAS 6.1 install.
The latest version of RAD is
My personal opinion (because I use our products too): I wish we (IBM) would have a corresponding WSAD/RAD release for each new WAS release. We had that for 5.0, 5.1, and 6.0, which really helped development teams upgrade their environments and hit the ground running with the latest releases. But there is apparently no RAD 6.1 to go with WAS 6.1. If you wish we had RAD 6.1 so you could buy it, that's a missed sales opportunity for us, one that you might want to communicate to your IBM WebSphere/Rational salesperson, whom I'm sure will be glad to communicate this back to Rational's marketing along with actual customer names and estimates of missed sales.[Read More]
Why are declared interfaces important?
Declared interfaces, like clean air and clean underwear, are easy to take for granted until you don't have them. I used to do my OO programming in Smalltalk, which is a great language; but one deficiency I always felt (and this is heresy for a Smalltalker to say, but I'm saying it anyway) is the runtime binding--what I came to think of as extremely weak typing. Smalltalk variables had no declared type/class, so practically any code with correct syntax would compile. It wasn't until runtime, when a client invoked a message on an object, that the environment determined the variable's object's class and looked at the class to see if it implemented a method with that signature. So you didn't really know if your code worked until you ran it, and you got lots of runtime errors that finally uncovered your simple programming mistakes.
I always thought there had to be a better way, and I discovered one in Java: interfaces. An interface is a contract between an object and a client using the object. The object promises to implement methods with these signatures, and the client promises to only invoke messages with these signatures; the object's class can implement those methods any way it wants to, and the client can depend on the signatures not changing even if/when the implementation does. New classes that didn't exist when the client was written can nevertheless work properly for the existing client simply by implementing the agreed-upon interface. Different implementations (classes) are interchangeable not because they coincidentally happen to implement some common set of signatures, but because they declare that they implement the same interface. (This interface vs. implementation thing also makes the distinction between abstract and concrete classes much more meaningful.)
Data can also suffer from weak typing. For the generator and consumer of some data to exchange it successfully, they have to agree on the format. When they don't agree, either the consumer derails with parsing errors, or worse yet proceeds (seemingly successfully) with incorrect data. When data exchange problems are detected, the developers fall into a blame game: "Your generator code is producing incorrectly formatted data." "No, your parser code can't parse the correctly formatted data." Resolving this dispute can be difficult.
XML does for data what Java interfaces do for code: It strongly types the data by declaring its schema (much like the DDL for a relational database schema). XML data has to be well formed to be parsed. It can also be valid, meaning that it fits the agreed-upon data structure. That structure is declared in an XML schema which the XML data is validated against. So when the consumer of some XML data can't consume it successfully, the development teams have a much more objective and less political means to determine where the problem is: a validating parser. Either the XML data validates against the schema--in which case the consumer has a bug--or it doesn't--in which case the generator has a bug (or the data validates yet the consumer finds flaws in it, in which case the schema needs to be improved). The schema is definitive (at least to the limits of a schema's ability to capture a program's intent), and is declarative so that it can be used by a variety of parser implementations. I like this idea so much that I tend to believe that almost all XML data should be validated before or as part of being consumed, or better yet, before even being sent (no use taking up bandwidth transmitting invalid data). (For example, see Validating XML in WAS and The Message Validator Pattern.)
I see SOAP and WSDL as making Web services strongly typed. A SOAP message is an envelope whose payload is an XML document, and that document should have a schema it can be/is validated against. WSDL declares an interface the way a Java interface does, and (usually) declares the incoming parameters and outgoing return types as XML documents with schemas the messages can be/are validated against. This helps ensure that a consumer and provider implemented independently still work together. And when there's a problem, it helps narrow down where the problem is: either the consumer invoking the service isn't conforming to the WSDL properly, or the provider implementing the service isn't. That doesn't fix the problem, but it tells you who needs to fix it.
So declared interfaces are a good thing, both for code and data. Can we agree on that?[Read More]
The latest version of WebSphere Application Server, v6.1, is now available.
Check out the press release from the announcement back in April, "IBM WebSphere Application Server V6.1 delivers flexible, secure infrastructure to provide a reliable foundation for your Service Oriented Architecture." For details of the announcement, see WebSphere Application Server V6.1 Announced. One of the main differences is that WAS v6.1 runs in Java SE 5 (see IBM Java Developer Kits: Java 5 SE) whereas WAS v6.0 runs on J2SE 1.4; both WAS v6.0 and v6.1 implement J2EE 1.4.
There are the usual Base, ND, and z/OS editions. (How many J2EE app servers run on mainframes?!) There's now v6.1 documentation, including the v6.1 InfoCenter.
If you're a Passport Advantage member and licensed for the latest releases, you should be able to download WAS 6.1 now. (If you're a WAS customer/client, can you confirm that WAS 6.1 is now available for download? Please add a comment.)[Read More]
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
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?
I kinda thought everybody knew this already, but it's come up a couple of times in the past few weeks, so maybe this is a question that still needs answering: What's the best way to serialize an object, binary or XML?
First, what's the difference?
Serialization usually means binary serialization, a Java facility for writing an object to a byte stream. The object's class must implement
Java objects can also be serialized to XML, a text (character) format. O/X mapping libraries like JDOM (JSR 102), dom4j, Transformation API For XML (TrAX), JSR 173: Streaming API for XML (StAX), etc. can make this easier. JAXB was supposed to facilitate declarative tools for mapping XML schemas to Java object structures, but it doesn't ever seem to have gotten off the ground. (See JAX-WS Improves JAX-RPC with Better O/X Mapping.) What has stuck better is SAAJ, an object model for SOAP messages, whose implementation usually contains something JAXB-like. (Keep in mind that SOAP is just one kind of XML, a specific XML schema.)
In theory, XML serialization can be built right into Java the way binary serialization is. This is why binary serialization is implemented as a specific set of classes separate from the rest of Java; so that you can substitute another set of classes that implement another serialization scheme. Instead of
So which should you use, binary or XML serialization?
Binary serialization is much more efficient than XML and easier to get working. Writing out an object in binary form is a little faster than text/XML form. Binary form is much more compact and so saves memory and bandwidth. And binary form is much faster and easier to parse than XML.
So why would anyone use XML instead of binary serialization?
Flexibility. Binary serialization requires the serializer and the deserializer be Java (but see the comments for details), and both Java program(s) must have the classes in their classpaths for the objects being serialized. There are also class version issues. XML is not Java-specific and so works with any language. Its text data can more easily be displayed and read by people.
I like to say this: If you find that your apps are too efficient and don't burden your hardware enough, use more XML. There is no code so inefficient that it can't be made even more inefficient using XML. As a keynote speaker said at OOPSLA a couple of years ago (I think it was Alfred Spector): "We just never thought that the programming community would be so accepting of a format as inefficient as XML."
There are ways to make XML more efficient. Don't include whitespace. Use short element names and shallow namespace trees with short names. There's even a move afoot for "binary XML" (practically an oxymoron); see Better Web Services Performance.
So bottom line, if all your apps writing and reading your data are implemented in Java, use binary serialization. Compared to XML, it's easier to get working and has better performance. If and when you need interoperability with other languages or better support for people reading the serialized data, then go through the extra effort to implement the code for XML marshalling and demarshalling.
A few references for more detail:
Wayne and Bill are having a good conversation on their respective blogs, and they're making some important points, so I want to bring them to your attention.
First Wayne pointed out that when your code opens a connection, it needs to close it again, so that your program doesn't run out of connections. Wayne points out that you should do the opening and the closing right there in the same method, so that you can't possibly forget to do both. Very good advice.
Then Bill pointed out that Wayne missed a second, related point that's also important. In Java, it isn't sufficient to just do this:
You actually need to open the connection in a try block and close it in a finally block, like this:
This way, whether the block exits at the end successfully or exits in the middle because and exception is thrown, the finally block ensures that the connection will get closed no matter what.
So these are both good points that all Java programmers should follow.
I'd like your feedback: How do you like my wiki?
I started my wiki three months ago. Why have a wiki in addition to a blog? Because hopefully the wiki is a better way to browse info I build up over time. Meanwhile, I still announce the major additions and changes on my blog, so you can check them out incrementally, a few minutes each day.
So how is this working? When you see a blog posting that points to a wiki page, do you follow the link and check out the info on the wiki? Do you find it helpful the way that page links to other pages? When a page is especially useful, do you bookmark to return later?
I can keep doing the wiki, or drop it, depending on what people are getting out of it. So if you like it and want to see more, please say so. If you have opinions, positive (supportive) or negative (constructive), please add a comment and let me know. Thanks.[Read More]
I've had the chance to learn a lot more about our new DataPower products. The more I learn, the more impressed I get.
DataPower is a company IBM acquired last year. We're still getting them integrated, including our web sites. We list them on our site, but most of the product information is still on DataPower's site.
The DataPower products are network appliances. Like an IP router or hub, it's a box; the entire interface is four Eathernet ports and a serial port (and a power cable). It's rack-mountable; its size is 1U, or about the size of a large pizza box. The software is all firmware, with flash memory for configuration settings. There's really nothing to install; you unpack it from the shipping container, plug it into the network, and start using it. You do need to enable it, and you need to configure it, which is a little like programming, but much simpler than a traditional software server like a database or a J2EE app server.
Interestingly, even though DataPower is effectively a hardware device, it's grouped as part of IBM's WebSphere brand. This is kind of an odd choice, since Systems Group is the part of IBM that makes hardware. Software Group's products come on CDs or can be downloaded, and are installed on host computers. But DataPower was added to Software Group, and specifically the WebSphere brand, because the appliances have really great synergy with our enterprise service bus (ESB) products.
As I get time, I'll talk more about what the DataPower products do and how cool and useful they are.[Read More]
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
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, RAD, 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.
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:
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.
I'm documenting tricks in RAD 6. Something that's changed since WSAD 5 is that test servers are now shared by workspaces.
Thanks to Wayner for reminding me of this.
In WSAD 5, each new workspace had its own servers. So if you wanted to have two servers with very different configurations, one way to accomplish this was to setup each server in a different workspace.
In RAD 6, the workspaces share the servers. So even if you start a new workspace, you still have the same servers. Combined with the fact that New > Server really just creates an alias to the same server (if it has the same profile), this makes it really difficult to create another server: New > Server doesn't work, a new workspace doesn't work, etc. For how to create a new server that's actually independent and separate from the ones you already have, see How to Create a Server.
So just keep in mind that workspaces share servers. When you change the configuration of a server in one workspace, or delete a server, or create a new one (a truely independent one or an alias), you're doing so in all other workspaces as well.
The World Wide Web Consortium (W3C)--keepers of the pivotal Web specifications like HTTP, HTML, XML, and SOAP--has announced a new initiative to make SOAP more efficient and therefore make Web services faster. (Web services that are SOAP-based, anyway.) This comes out of an effort called SOAP Optimized Serialization Use Cases and Requirements, part of the SOAP 1.2 effort. Optimized SOAP consists of three parts:
Do you want to know more?
Now you can build communications enabled applications in WebSphere Application Server.
The IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications, one of the WebSphere Software Early Programs for WAS 7.0, enables you to make your WAS JEE application into a communications enabled application.
So what the heck is a communications enabled application (CSA)? Imagine your user is browsing your Web site and has a question. The user can call a customer service representative, but then the CSR has no idea what Web pages the user is looking at and can't help the user browse to find what they're looking for. With CSA, the user can click a button on the Web page to contact the CSR, which then opens up a connection like an IM chat, a VoIP discussion, or the user enters their phone number and the CSR calls it (aka click to call). Not only does this make it easy for the user and CSR to have a conversation, but the button can also enable the CSR to share the user's browser screen, looking at the same Web page the user is seeing, and together they can collaboratively browse the Web site (aka cobrowsing). This enables the CSR to help the user find what they're looking for and even fill out orders and other forms. A similar button can enable a user to share a Web page with another user so the two can then browse the same site together from two different computers (aka peer-to-peer cobrowsing). This would, for example, enable two users to jointly browse for a gift for a third person without having to be at the same computer.
There are non-WebSphere, third-party packages for CSA, but all they really enable is click to call. The CSA is not built into the app, so the CSR can call the user and know something about the user's context when they clicked the button, but can't cobrowse. The app developer also has to learn how to program the CSA package which doesn't necessarily have a well-defined Java API like the features in WAS. Because the third-party CSA is a separate app, it has to be installed and administered separately in the runtime environment and may not have WAS's QoS features for scalability and failover. WAS CSA is a better approach because it integrates the CSA features into the WAS app, supports a single integrated Java programming environment, and runs on the WAS platform your app is already using.
WebSphere CSA is also JSR 289 SIP Servlet 1.1 compliant.
The WebSphere development team that created the CSA has their own blog, appropriately titled Communications Enabled Applications. This blog is a good place to get the straight dope on how WebSphere CSA works and how to use it. It includes several YouTube videos that show how it works. For example, here's one where Erik Burckart, the chief architect for CEA, explains how cobrowsing works:
As the video shows, the two peer-to-peer cobrowsing users can chat about what they're browsing using an IM built into the Web site.