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.
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 transferFunds or addToShoppingCart.
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 cart.add(bookID)!
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. [Read More]
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. [Read More]
Resource Representation SOAP Header Block (RRSHB) -- Enables a SOAP message to contain references to external resources. These resources can be cached by the recipient so that they don't need to be transmitted in the message, which saves bandwidth when multiple messages contain the resource.
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.
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.
Aug 11 Update: A reader comments (rather tersely) "Does this mean its the best or just the most expensive?" (This sentiment is similar to some comments made comparing Gartner and Forrester rankings of WebSphere products.) Interesting. Richard, thanks for the comment; but it makes me wonder what your point is exactly.
What do you all think? What does this ranking mean? Is it saying that WebSphere Portal is best? Is it saying that WebSphere Portal is most expensive? Would the most expensive product necessarily rank first? Indeed, if WebSphere Portal is most expensive (and I don't know if that's true), does that somehow invalidate these rankings?
I think rankings like these are rather significant, at least in one certain respect, and I'll explain why in a future posting. But first, I'd like to hear your thoughts. So if you have an opinion, please add a comment.[Read More]
Support for WSAD 5.1 will be withdrawn on September 30, 2006.
This is shown on the W page for the IBM Software Support Lifecycle. It also shows that support for WSAD 5.0 ended on April 30, 2006.
Withdraw from support
WebSphere Studio Application Developer for Linux and Windows, V5.0
10 Jan 2003
30 Apr 2006
WebSphere Studio Application Developer for Linux and Windows, V5.1
29 Aug 2003
30 Sep 2006
So, if you're still using WSAD 5.x, what should you do? Upgrade to RAD 6.0. RAD is the next release of WSAD. It can be used to develop apps for WAS 5.0 and 5.1--just like WSAD--as well as for WAS 6.0, and has newer features than WSAD.
I plan to use the wiki to cover the same topics I discuss on this blog. "So," you might ask, "why have a wiki in addition to a blog?" (I answer the question on the blog wiki, so follow the link.) Does this mean I'm not doing the blog anymore? No, I plan to continue blogging. But I plan to use the wiki as a space to organize reference material that hopefully will be relevant over time, I may need to update over time, and you may wish to browse to get a more complete picture. That's hard to do with a blog, which is chronological. I plan to continue to use the blog to post timely material (stuff that isn't as interesting weeks and months later) and to point you to updates on the wiki.
What has pushed me over the edge to start publishing on a wiki is my DataPower discussion. I started it on the blog, but am now moving the documentation onto the wiki. I plan to continue talking about DataPower on the wiki, and to let you know what I've added here on the blog.
Hopefully this will make it easier for me to document what's going on with IBM, and for you to consume the information. If you have ideas on how this could work better, please let me know.[Read More]
So, bare with us as we learn to blog all over again. In many ways, Roller is better, offers us more editing features that you'll never see but we'll appreciate, and is certainly much more standard than what dW was using before. But like all things worth knowing, there is a learning curve. Should be interesting. [Read More]
Also on top of the ASTK is WebSphere Integration Developer (WID), which adds features for developing SCA components.
Notice that WID is not built on top of RAD; they're seperate and designed for two different types of developers. RAD is for application developers whereas WID is for integration developers, the people who design how apps will fit together and talk to each other. IBM expects these to be different people with different skill sets and thus needing different tooling. For developers with both application and integration skill sets that wish to do both, you can buy both RAD (or RSA) and WID and install them in the same Eclipse install so that you'll have one large IDE with both sets of tooling.
WID is the IDE for developing "applications" (really SCA modules) deployed into WPS and WESB. [Read More]
Business Week has just published an article, "Java? It's So Nineties." It asks: "Can it possibly be that Java--once the hippest of hip software--has become a legacy technology?"
The article talks about competition to Java from LAMP, .NET, and AJAX. It points out that popular sites like Google and Yahoo don't use much Java.
This information may be correct, but it's also missing (a lot of) the point. The question is whether you need business logic in your Web site, or whether your Web site just shows users your database.
The article talks about tasks that don't require much business logic. Google just displays search results, e-mail, and map images. Yahoo is the poster child for portals, aggregating existing info and integrating it on the glass. They both use read-only data that can be highly replicated; users can configure the display. Those tasks require minimal programming logic, so PHP scripting and a simple SQL database be all you need (plus a Web server and OS). Even then, huge sites like Google and Yahoo must be doing much more than just using PHP.
But a lot of sites need more than scripting. Do your users need to: Find airline tickets? Trade stocks? Does your implementation need to: Integrate with EISs? Enforce security? Coordinate multiple users updating the same data concurrently? Good luck with PHP scripts. You're gonna need J2EE or .NET for that. I can tell you that this is what WebSphere (WAS) customers are doing.
This is an old argument. I remember in the early '90s when Smalltalk would compete with tools like PowerBuilder. PB would let you CRUD your data, but not much more. Smalltalk would give you business logic. Which was better? Depends on what you need. If you just need to CRUD your data, PB was easier. For more sophisticated apps, Smalltalk was more sophisticated and capable.
So LAMP may well work if you want open-source everything and just want to display (and CRUD?) your database. But for full-blown applications hosted on the Web, LAMP won't cut it. AJAX is a cool display technology (see Ajax and Java), but it's only a display; you still need a server behind it running something (LAMP, Java, .NET, etc.). .NET is on the same level as J2EE, and c# is very Java-like, so then that comparison is the old Microsoft-only vs. semi-open-standards and write once, run everywhere argument.
The article seems to miss a lot of emerging trends. It fails to distinguish between Java and J2EE (aka Java EE), comparing Java to .NET. It doesn't discuss the biggest trend in IT today, SOA; much less IBM's new SOA programming model, SCA. It seems like Java and J2EE have grown a lot since Peter Yared was an exec at Sun.
So yeah, Java may not be the technology of choice for displaying your database. But hopefully your Web apps are doing a lot more than that. [Read More]
This approach is probably better than using OS commands to copy the files in the profile directory. Those files may contain machine-specific values, like the machine's IP address. Export and import should filter out those specifics.
wsadmin scripts are probably still the best approach, because ultimately you'll need those for deploying your app in test and production. But the export and import approach is simpler in the short run.