Learn about the SOA entry points at a presentation (that may be) near you.
I've talked about IBM's Entry points into SOA. Now Get started on SOA with WebSphere's proven, flexible entry points is a day-long event to teach you all about them. It's being held on nine dates in June in locations all around the world, including New York, NY and Seattle, WA in the US. I think the cost is free.
Can't attend one? You can still go to the page and download the presentations.[Read More]
Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: May 2007 X
Does REST need declared interfaces?
I (and commenters on my blog) have discussed REST vs. SOAP/WSDL a fair bit. My Interoperability vs. Integration post somehow turned into a long comparison of the two approaches.
A lot of what it boils down to for me is that independently-declared and strongly-typed interfaces are a good thing. As I discussed in declared interfaces, WSDL creates a declared interface for a Web service. Back in a February 9, 2006 comment, Richard G Brown explained why a Web services interface is important:
In the SOAP/WSDL/WS-* case, a provider says: "I can do X. If you want me to do it, here's how you get in touch with me. This is the information you must give me. This is what I'll give in return". One of the great advantages of WSDL is that you can feed a WSDL to a tool and it can take care of all the gunk - you just need to populate the appropriate fields in some object somewhere, for example.Now, in typing rest, my collegue Patrick Mueller contemplates that he "wants some typing [i.e. contracts] in the REST world" and, among other things, discusses WADL (Web Application Description Language). Sadly, he's already gotten some backlash, which he's responded to in not doing REST.
So I (and Richard, and others?) think that the major advantage of WSDL over REST is the declared interface. Now some of the REST guys seem to be coming around to this way of thinking and are thinking about declared interfaces for REST. I then wonder if and how REST with declared interfaces would be significantly different from WSDL (w/SOAP). Patrick and others seem to believe that WADL is much simpler than WSDL, so I assume they're correct although don't know enough about it to understand why WADL is simpler than WSDL. REST is all about simplicity, so a simpler WSDL (e.g. WADL) would be appealing. Since a lot of the REST vs. WSDL discussion has been about declared interfaces, I wonder how WADL/REST and WSDL/SOAP would differ, and if that would bring the two sides together or better clarify why the two sides disagree.
I've Googled around for a WADL-WSDL comparison, but haven't found one. Even Wikipedia failed me, with a really brief and weak Web Application Description Language entry. For now, the best discussion on what the heck WADL is and what it means to Java is Marc Hadley's Blog: see Introducing WADL and Mapping WADL to Java.[Read More]
IBM's getting ready to announce their newest SOA offerings.
The root page for these announcements is SOA Launch; the theme is "Creating Enduring Impact." As I talked about in Service Oriented Business, IBM's focusing more on applying SOA to the business. It's still important to apply SOA to IT; but an additional focus is using SOA to once again make IT the heart that drives the business and enables its success.
There's going to be a Webcast, "Enduring Impact through SOA," on Tuesday, June 5, 2007 at 11 AM EDT. The speakers will be the head of IBM Software Group and two General Managers. Attendees "will receive complimentary access to Video Podcasts from the IMPACT 2007 Conference."[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]
Service oriented architecture (SOA) isn't enough. What we also need is service oriented business.
We talk about how SOA enables IT to align with the business, but that assumes that there's a business model for IT to align to. A significant concern I have on a lot of projects is that us technical people are going to go to the business people and say, "Please tell us about the repeatable business processes composed of reusable business tasks you use to operate your business (so that we can develop corresponding services to model the business as an SOA)" and the business people are going to reply, "Our what?" Business people often make their business look to us IT people like a random series of events they make up as they go along, and that's difficult to model as SOA or anything else.
So for a while now, IBM has been saying that SOA isn't just an IT thing. In the whitepaper "IBM’s SOA Foundation," which is a year-and-a-half old now, we talk about the premise that all businesses have a business design, that "describes how that business works." It also says: "The primary goal of Service Oriented Architecture (SOA) is to align the business world with the world of information technology (IT) in a way that makes both more effective." So for SOA to be effective, the business needs a design for IT to align with. And it's not just a matter of IT aligning with the business; it's a matter of business and IT aligning with each other. IT uses SOA, but it can't make SOA successful by itself; business has to help, and in fact has an equally important role.
Applying SOA to the business (not (just) IT) is the central theme of Sandy Carter's new book, The New Language of Business. That book doesn't really talk about technology, much less products; and yet it's an SOA book. How's that? Because it talks about using SOA to make business work better, primarily by organizing a business into a service oriented design. This design can be modeled by IT; it's something IT can align with. I'm thinking of this as a service oriented business; Sandy says this makes your business more "flex-pon-sive*."
This is a theme IBM execs are talking about more and more. In the webcast "My CEO thought Flexibility & SOA were just an IT issue until I told him this...," which I discussed in SOA: It's not just for IT anymore, Sandy talks about how "making the business more agile and successful through IT systems ... is a business issue that directly affects [your CEO and Line of Business executives]." Steve Mills, in his Impact 2007 keynote, calls SOA "business-driven computing."
SOA may be somewhat effective in isolation as a pure IT effort, but to be much more effective, not only should IT be service oriented, but also the business should be service oriented. We not only need service oriented architecture (in IT), we also need service oriented business.[Read More]
"Why do reason, logic and truth seem to play a diminished role in the way America now makes important decisions?"
That's a quote from a new book, The Assault on Reason by Al Gore. There's a long exceprt from the book in Time magazine, and a New York Times review.
I haven't read it, but it sounds interesting.[Read More]
One of the new developerWorks Spaces is on SOA.
I've talked about developerWorks Spaces in general. One of the community topics that I'm particularly interested in is SOA development and best practices. It lists the latest SOA-related stuff: articles, podcasts, events, briefings, etc. Makes it much easier to figure out what's new on dW concerning SOA.
One thing I'm not clear on is how this is going to differ from the dW SOA and Web services zone home page; the spaces page appears to be part of the zone. I guess the zone page will focus on what's in the zone, whereas the spaces page will pick stuff from all the zones and other parts of the IBM web site, and maybe even related sites.
In any event, check it out, it's a good place to find our SOA materials.[Read More]
IBM developerWorks has created a new way for readers to find materials and even each other.
developerWorks Spaces initially consists of thirteen community topics. These topics serve as portals for finding materials and resources on these topics; you can also create your own. For more details, see "Introducing developerWorks spaces." There's also a developerWorks Spaces FAQ. Rawn Shah discusses the approach in developerWorks spaces preview and webcast.[Read More]
Steve Mills says, "with SOA there is a connection to real business issue and real business problems. ... We're in an era of business-driven computing."
This quote comes from "IBM views SOA as "business-driven computing"." (SearchWebServices.com) It is part of the keynote Steve gave today at the opening of Impact 2007. This sentiment is consistent with the webcast described in SOA: It's not just for IT anymore.
The article also says "IBM announced a slew of new products and enhancements to it's already massive SOA product set." Expect to hear more about those in the coming days.[Read More]
A phrase we might all think about more is "It just works!"
I'm reminded of this phrase by the interview "Why Software Sucks" on IT Conversations (a great little gem of a site). The interviewee is David Platt, who apparently worked for Microsoft and wrote a book, Why Software Sucks...and What You Can Do About It. The interview is mostly a long whine that makes whatever point it makes in the first five minutes, and takes 49 minutes to finally get around to the "what you can do about it" part, but it does have some interesting tidbits.
One tidbit is David's description of how the UPS web site works, especially when he was in Sweeden. With a lot of major web sites, if you are located outside of the US and enter the URL "amazon.com" or "yahoo.com," you automatically get redirected to the sister site for that country (like www.amazon.co.uk). With UPS's site, the home page makes you choose the country you're in; there's nothing else you can do on the site--not track a package, not log into your account, not view the annual report--without first selecting your country. And apparently if you're in Sweden, this takes 30 mouse clicks and key presses (David counted). This, even though 90% of UPS's packages are shipped in the US. David describes this as a barrier to using UPS's web site (and I agree). The site could at least detect what country your browser and its Internet connection is in, and default to that country--that is, assuming that the site even really needs to know what country you're in.
By comparison, you can enter a UPS tracking number in the Google search field; Google recognizes the string as a UPS tracking number, gets the package status from UPS, and displays it. Google doesn't need to know what country you're in (or figures it out without bothering you). Google just works.
In fact, a general theme for Google is that it has the world's simplest search syntax, which is no syntax. You type it a search string, it tries to figure out what you mean, and generally does a pretty good job. To get an idea of what all Google can do with one simple search box, check out Google Web Search Features. For example, if you misspell a search term, Google will often suggest the correct term. How does it do this? Some amazing AI cognitive learning computer? Not really. It watches searches that don't return much, and then the next search from the same browser for a term spelled slightly differently, which returns a rich set of matches, where the user follows a match and doesn't search again for a while. When Google sees this several times, it figures out that the second term is the correct spelling for the first term and subsequently suggests it as a correction. It's not figuring out what the current user meant, it's just watching what past users did and how they corrected mistakes and assuming that the current user may need the same correction. ("Database Requirements in the Age of Scalable Services" by Adam Bosworth) I use this Google feature as a spelling checker; type in a misspelled word, the result screen suggests the proper spelling. It's easier that firing up Word and opening a blank document, has no pop-up adds like the dictionary web sites, and is certainly much easier than opening the dictionary book on my bookshelf. Google just works.
So how does Google know that a search string is a UPS tracking number? I think it doesn't. I think it runs many queries concurrently, judges which are the best matches, and merges the result lists with the most promising matches first. So if a string looks like it might be a tracking number, Google probably runs it on all of the major package delivery sites; most don't match, UPS does, so then Goolgle infers that this is a UPS package tracking number. If a package ever had "paris hilton" or "amanda beard" (popular searches, according to Google Zeitgeist) for a tracking number, Google would probably be stumped.
So the point is that Google just works, and UPS doesn't. Google is a better interface to UPS than UPS's own web site is. The UPS web designers could have designed a better interface, but chose not to. But they should have.
Another example is a dishwasher where you put in soap once a month. Each time you run it, it uses the proper amount of soap. It just works.
In Microsoft Word, two examples are the red squiglies under misspelled words and the auto-correct so that when you type "hte" it inserts "the." These are good features; they just work. They're also several years old and point to the lack of useful innovation in the latest versions of Word.
On the flip side, a lot of things don't just work, no matter how easy it may be. Why does Quicken 2007 display ads telling me I should upgrade to Quicken 2007?!
Lest you assume I think that IBM is somehow faultless in this regard, let me clarify that I (and many inside of IBM) believe that our products are too had to use. They're very sophisticated, but they make simple stuff hard. We want to make our products easier to use; it's an effort we call "consumability." Our products too often don't just work; we're trying to make that easier and more common.
One galling example for me is IBM's internal employee directory. The amazingly good news is that we have a single list of all 300,000+ employees, who their management is, how to contact them, and some fuzzy description of what they do as employees of IBM. This is an amazing feat of database federation. The bad news is that search is a pain; it needs Google. As a simple example, with the main search field, you can chose to specify that you're looking for a name, Internet address, Notes address, phone number, etc. I frequently put in someone's Internet or Notes e-mail address, but get no matches because the default search type is name. I have to change the search to the proper type, run the search again, and this time get the match. Why not look at the string and infer what the type seems to be? @ means Internet address, /IBM means Notes address, digits and dashes mean phone number (even internationally), etc.? Why not run several searches concurrently, then merge the one that worked with the others that matched nothing? That would mean more work for the computer, but less work for me, and that's a trade-off I'm willing to make!
Getting back to David's interview: He believes that us programmers focus too much on what programming language we use, whether the code is object-oriented, whether the architecture is service oriented, etc. The users don't care, they just want software that works. I think David's blame is a bit misdirected--programmers ought to know what languages make them productive for various tasks, and architects ought to care about architecture. But someone ought to also care about user experience, and that should be driving the use cases that drive not how the product is implemented but how well it helps the user do their job. OO or not, SOA or not, you want an experience where the user says, "It just works!"
So what kind of software have you written lately? Created any interfaces like the UPS web site? What can you do in your software so that the users will say, "It just works!"[Read More]