There have been a lot of articles about WebSphere published after the Impact conference.
I haven't had much time to blog lately, so I'll try to start catching up next week. Meanwhile, lots has been happening with WebSphere products, as the press has been covering. So if you get bored over this Mother's Day weekend (here in the US), check out these articles.
IBM is merging the System i and System p series into IBM Power Systems.
IBM Power Systems is a new hardware server computer platform that "unifies IBM's highly successful integrated platform, IBM System i, with its fast growing UNIX operating system platform, IBM System p." "Now you can take advantage of a single, energy efficient and easy-to-deploy platform for all of your UNIX, Linux and i applications ..." The IBM Servers division still has System z, its mainframes, and System x, its x86 PC servers.
WebSphere sMash, built on Project Zero, is a development and execution platform for mashup applications. IBM calls these situational applications, meaning they can be developed quickly with relatively simple programming skills. Situational apps aren't meant to be very industrial strength, although the services behind them may be.
sMash supports developing applications with the following (often called Web 2.0) technologies:
WebSphere Enterprise Service Bus (ESB) is a powerful solution for mediating service requests. Based on Service Component Architecture, it provides a set of pre-built and custom mediation capabilities to perform tasks such as routing, transformation, logging, and lookup. This 4-day online workshop provides extensive hands-on lab exercises of all of these features. Additionally this workshop positions WebSphere ESB within the IBM SOA Foundation.
This workshop uses the latest (V6.1) releases of WebSphere Enterprise Service Bus and WebSphere Integration Developer tools. It also integrates WebSphere ESB with WebSphere Service Registry and Repository and WebSphere MQ.
Students will explore and build ESB solutions for deployment to WebSphere ESB. They will use WebSphere Integration Developer to perform the typical tasks of an integration developer including modeling, testing, configuring, and deploying ESB-based applications. They will then deploy and administer these applications to WebSphere ESB.
The class will be held only of there's sufficient interest, so if you are interested, please register.
IBM is making Web 2.0 secure with SMash (secure mashup).
A mashup is a very simple application that takes data and functionality from multiple sources and applications on the Web and combines them together as one source or display of information. The app is very simple because it delegates all of the real work to the existing apps on the Web; therefore mashups can be written very quickly, and when they stop working, you can just throw them away and write new ones. They're a very simple example of how SOA can make behavior easy to reuse. Every mashup example I've ever heard of combines geographical data, such as the location of coffee cafes, with map data to display where the locations are.
The mashup model basically has no security, which limits its use to only public data (like the location of coffee shops). To make it more useful, it needs security, such as the ability to control who can access data, how it can be used and forwarded, where the data is coming from, keeping the data private, and so on.
SMash (secure mashup) is a technology from IBM to enable the development of mashups that are more secure. IBM is donating the technology to the OpenAjax Alliance.
As WebSphere Application Server installations grow to accommodate the growth of business processing, the question "How large can a WebSphere Application Server cell be?" is being asked more often. This IBM Redbook discusses large WebSphere Application Server installations, and as you will see, the answer to the question is not straightforward. Numerous variables play a part in supporting or constraining the size of a WebSphere environment. These variables are most likely different in each WebSphere Application Server installation, resulting in a different answer for each environment.
This Redbook discusses large WebSphere Application Server topologies, focusing specifically on best practices when planning and configuring the high availability manager, core groups, and core group bridging. A review of high availability, core groups, and core group bridging features is followed by extensive coverage of planning, designing, and implementing a large cell migration. The book then covers detailed scenarios of configuring single and multiple core group topologies.
In addition, the scripts, applications, and batch files used to set up and test the scenarios are included as additional material that can be downloaded and modified as required for your specific environment.
This Redbook is intended for WebSphere Application Server administrators and planners who are considering migrating their small to midsize installations to larger topologies.
WAS is quite scalable. This book will show you how.
The support for using Lotus Notes from a cell phone is getting better. "New IBM Software Brings Web 2.0 to Mobile Phones" is an announcement from IBM: "Lotus Expeditor software platform is extending desktop computing and Web 2.0 capabilities to mobile phones."
There's also a rumor that support is coming for iPhones. "Notes e-mail may come to the iPhone" (Computerworld) quotes an IBM spokesman as saying that IBM Lotus Notes developers will be working on a Notes e-mail application for iPhone 2.0.
Securing access to information is important to any business. Security becomes even more critical for implementations structured according to Service-Oriented Architecture (SOA) principles, due to loose coupling of services and applications, and their possible operations across trust boundaries. To enable a business so that its processes and applications are flexible, you must start by expecting changes – both to process and application logic, as well as to the policies associated with them. Merely securing the perimeter is not sufficient for a flexible on demand business.
In this IBM Redbooks publication, security is factored into the SOA life cycle reflecting the fact that security is a business requirement, and not just a technology attribute. We discuss an SOA security model that captures the essence of security services and securing services. These approaches to SOA security are discussed in the context of some scenarios, and observed patterns. We also discuss a reference model to address the requirements, patterns of deployment, and usage, and an approach to an integrated security management for SOA.
This book is a valuable resource to senior security officers, architects, and security administrators.
SOA can add security holes to an architecture, but can also provide the opportunity to enforce security policies more systematically. This book will help show you how.
Don Ferguson (sometimes architecture terrorist) was until recently a fellow at IBM (i.e. one of it's top 50 or so technical people), where he was one of the main people in charge of IBM's SOA approach. So he knows a thing or two about it, so when he says a book about IBM SOA is good, that's petty significant. When he contacted me out of the blue to tell me that he'd seen my book and liked it, I was pretty excited. (I didn't even know he knew it existed.) Now his review lets everyone know, which is awesome.
How should an architect get the developers to do what he/she wants?
Don Ferguson says he has at times become an "architecture terrorist" to get development teams and managers to do what he asked. As he points out, it's difficult to get new features into products and other applications. Sometimes as an architect you have to threaten to do it yourself, often badly because you're an architect and not/no longer a developer; that can scare the team into hurrying up and adding the feature before you can, a sort of preemptive attack for program design.
You can order it from the following locations: Maximum Press (the publisher), Amazon, Barnes and Noble, and Borders. (IBM employees: You can also order it through the IBM Bookstore. See my internal blog for details.)
Continuing with the theme of "What is a service?", I'm thinking it's best to think of it in terms of a "service contract."
The notion of a service is kind of squishy. It's a repeatable business task, hopefully well encapsulated so that it can be requested in a simple interaction and performed in a unit of work. That makes sense to business people and can be gathered as requirements, but is rather vague for us technical people (especially when trying to achieve business/it alignment). So we tend to fall back on a service interface as being the technical definition of a service. But as I discussed in service behavior, a service is a lot more than just its interface.
So how can we describe a service with some rigor? I'm coming to think of that as a service contract (which I discuss more on my wiki). In short, a service contract captures a service's behavior, interface, policies, and service level agreement (SLA). It's everything that a requestor and provider of a service must agree on so that the requestor knows what it can depend on and a provider knows what it must do.
For us technical people, I think that thinking of a service (a task) as a contract (an agreement that describes the task) will help us be a lot more specific and make good use of the ideals of SOA.
Lately I'm thinking more about "What is a service?" and deciding that one of the most important aspects is what I'll call "service behavior."
When we talk about services (as in the parts of an SOA), we tend to talk about interfaces a lot. But it doesn't take long to decide that a service is a lot more than an interface. We care more about what a service does than its interface for interacting with it.
So why the focus on interface? Because, I think, an interface is more quantifiable; you can make it machine readable, describing it with a programming construct such as WSDL or a Java or .NET interface. A code compiler can then check code against that declaration for correctness. Inheritance creates rules for how one interface is allowed to extend another. Like I talked about in declared interfaces, interfaces are definite--either they match or they don't. That's easier for us technology types to deal with.
Behavior--what a service does--is more fleeting, which I think explains why us technology types deal with it less. But it's what the users care about most; the business people in an enterprise probably don't care much about the interfaces that services have, but they certainly care about what the services do and whether they do it correctly.
As I discussed in What Is Behavior?, behavior is a bit like dark matter--it can't be measured directly, only indirectly. We measure behavior indirectly through testing--providing known inputs and measuring the outputs to confirm that they meet expectations. There's been some efforts to describe behavior directly the way we do interfaces--declared behavior--but that doesn't really seem to have taken hold thus far. For the time being, behavior can't be described and measured directly like interfaces, only indirectly via testing. (And it doesn't help that testing tends to be treated as computer science backwater.)
So a service is both interface and behavior (and probably more). The technical people focus on the interface while the business people focus on the behavior. To do a good job with services and SOA, we technical people are going to need to focus on behavior as well.
IBM has started a blog about the Impact 2008 conference.
I've talked about IBM Impact 2008, our big SOA conference that will be in Las Vegas, Nevada, USA on April 6-11, 2008. Mary Hall, one of IBM's marketing managers, has now started a blog on what's coming up: IBM Impact SOA.
The blog so far only has one posting, but it's a good one: If you attend Impact, you can also receive "20% off the public price of selected eligible IBM WebSphere education courses." So if you want to learn about SOA, the combination of the Impact conference and the education classes should be a pretty good way to go.
I don't think the book is very good. I don't think it's awful, but I doubt that many readers are going to find it to be super helpful. The biggest problems that I see are that a lot of the information it contains is already documented elsewhere, and the way it's documented in this book doesn't seem particularly helpful to any specific audience (architects or developers). In my review, I describe the topics the book covers and my opinion of how well they're covered. If those topics seem interesting to you and other books on those topics seem inadequate, then maybe you'll find this one to be helpful.
My Amazon review:
This is a mediocre book that provides basic information but little of the insight that creates knowledge. As the title implies, it doesn't teach SOA in general, just how to approach application integration using SOA. Even in that, its treatment of the topic is reasonably accurate but superficial.
The book's six chapters are a reasonably logical overview of basic SOA and integration topics that finally culminates in the discussion promised by the book title.
Chapter 1 explains why integration is important, a topic that goes back at least as far as David Linthicum's Enterprise Application Integration. It lists numerous aspects of application integration without giving particular insight into any of them nor comparing them--a theme with this book's material.
Chapter 2 explains what SOA is. Its treatment of SOA is very superficial, little more than a technology that can be used for integration, and so should not be read as a thorough overview of why SOA is important. To understand SOA's importance, see Service Oriented Architecture For Dummies (yes, a Dummies book, but helpful!). One of the main advantages of SOA is its improved ability (as compared to other architectural approaches) to align IT and business, that is to make a company's applications and its business work in a more similar fashion. For a good discussion of business/IT alignment, see The New Language of Business: SOA & Web 2.0.
Chapter 3 is an XML primer, which seems pretty low-level for an architectural book. It explains a lot through XML and schema code examples, and even gets into an explaining and comparing SAX, DOM, and StAX. This chapter would better serve the book if it had focused more on the architectural decisions for XML and the implications of those decisions.
Chapter 4 is a primer on Web services and again gets fairly low-level for an architectural book. It explains the need to integrate heterogeneous systems, often connected via Internet technologies, and eventually discusses WSDL (but not SOAP!), WS-I profiles, and interoperability between Java EE and .NET. In between, however, it discusses patterns for integration by lifting material wholesale from IBM's Patterns for e-business and subsequent Redbooks on the topic. The diagrams in this book are straight out of the IBM materials, to the point of (what seems like) copyright violation.
Chapter 5 focuses on BPEL and what the book calls "process-oriented architecture." This is an interesting turn, since business process is not so much integration using services as it is a useful abstraction for implementing services--especially long-running ones--using other services. So whether this is integration of business functionality or composability of business functionality is debatable. In any event, the book then dives deep on BPEL features and code examples. Other books on BPEL may be more helpful.
Chapter 6, the last chapter, finally gets to the book's topic, application integration using SOA, POA, and Web services. Here, the book finally starts to explore the enterprise service bus (ESB), although for some reason considers the ESB to be not just a means for connecting to service providers, but a hosting environment for service providers as well! A lot of the material here is a rehash of Enterprise Integration Patterns; although this book's authors don't seem to have read that book, they discuss a lot of the same topics in terms of implementing Web services. Curiously, one section covers Java Business Integration (JBI), which only applies to Java, and yet the book never discusses a similar and more interoperable programming model, service component architecture (SCA).
In conclusion, what material this book covers, other books cover better. The advantage of this book is providing brief overviews of the material and tying it together better than separate books can. Yet this book's coverage of these topics is too low-level for architects, too brief for developers, and too superficial to teach the topics to readers who don't already know them. Other books on SOA and on application integration are better.
Disclaimer/qualifications: I am a coauthor of Enterprise Integration Patterns and work for IBM. The publisher (Packt) sent me a copy of this book and asked me to review it.
Microsoft has produced a funny, star-studded video depicting Bill Gates' last day at Microsoft.
Bill Gates has announced that he's stepping down from his day-to-day roll as CTO at Microsoft so that he can focus full time on this philanthropic foundation. Last week at his keynote at the Consumer Electronics Show (CES) 2008, he showed a video of what that day will be like. It's pretty funny.
Unfortunately, no sooner does a release come out than so too do fixes for the release, but at least the known problems are getting fixed. After installing WPS 6.1 or WESB 6.1, you should then install these fixes:
The feature pack is a full implementation of EJB 3.0, including the Java Persistence API (JPA) that's replacing entity beans, and is a significant step towards supporting Java Enterprise Edition 5 (Java EE 5), the next version of J2EE. (WAS 6.1 implements J2EE 1.4.)
Message-driven beans (MDBs) on the service integration bus (SIBus) can now be stopped and restarted.
I've talked about The Message Consumer Rollback Pattern, which says that if a message is valid but cannot be processed, you should roll back the transaction to put the message back on the destination. But then won't this cause the message to be read and rolled back forever?
Yes, unfortunately messages will tend to retry forever, at least until the problem processing the messages is resolved. To prevent this, you need a way to detect this circumstance and respond by stopping the consumers. The idea is that if they can't process messages successfully anyway, they should stop consuming messages until the problem is resolved and processing will be successful.
In WAS 5.x, the listener port could detect a message that rolled back too many times and would stop. We lost this capability in WAS 6.x when we use activation specs to configure the connection between an MDB class and a JMS destination in the service integration bus (SIBus).
Technology has a tendency to get over-hyped and then crash (see Dot-com bubble). (A non-technology one in the US is crashing right now; see Real estate bubble.) What with all the hype these days around Web 2.0, social networking, etc., is another tech bubble inflating again?
These guys think so; see "Here Comes Another Bubble" (on YouTube):
Several of IBM's messaging products developers have now started a blog.
The full name of the effort is "A bunch of bloggers from IBM software Labs working on WebSphere MQ, WebSphere Message Broker, WebSphere MQ Everyplace, IBM Lotus Expeditor micro broker," a group that calls themselves the IBM-Messaging-Evangelists. These guys are from the groups that develop some of IBM's various messaging products. They're doing a nice job of announcing new releases and linking to relevant materials so you can learn more.
I was wondering if Tuscany is part of the implmentation of the SCA features in websphere process server 6.1. And if so, whicht version of the spec (1.0?) and tuscany implementation (1.01?) will be used.
Since the SOA Feature Pack is still Beta and WPS 6.1 is final, WPS 6.1 does not incorporate the SOA Feature Pack (but does incorporate WAS 6.1). The plan is still to have a release of WPS that will incorporate the SOA Feature Pack and therefore Tuscany and therefore a standardized impl of SCA and SDO, but this is all taking longer than planned and therefore is not part of WPS 6.1. Therefore WPS 6.1 contains the same proprietary impl of SCA and SDO in WPS 6.0.x, which will make backwards compatibility and therefore migration of your existing code easier.
I haven't really tried to understand the source code in this post; I just like the title: C++ is the spawn of satan. Also check out the comment from Keith; turns out it's actually C that's the spawn of Satan.[Read More]
Do laypeople understand what scientists mean when they describe an idea as a theory?
A scientific theory is "a hypothesis that is widely accepted by the scientific community." The qualities of a scientific theory include: "A scientific theory must be testable. It must be possible in principle to prove it wrong. Experiments are the sole judge of scientific truth."
In "Why Science Will Triumph Only When Theory Becomes Law," Clive Thompson contends that many people don't understand this. He points out that "in science the word theory means an explanation of how the world works that has stood up to repeated, rigorous testing. ... But for most people, theory means a haphazard guess you've pulled out of your, uh, hat."
We also use "theory" in a way that is far from the everyday usage (where a theory is pretty much a hunch), particularly when we talk of "the theory of . . ."; examples are relativity, electromagnetism, evolution, plate tectonics, the standard model of particle physics. ... These theories are far from guesses; they will survive no matter what new evidence is accumulated. They are complex constructs that incorporate and explain a significant body of evidence. They have demonstrated predictive power as well as descriptive power.
So if laypeople don't understand what a scientific theory is, then what should such a profound understanding be called? Thompson and Quinn propose that, for the purposes of the public at large, scientists should describe such well-established science as "law." People understand laws--like the law of gravity--and understand that they're always true, are not going to change, and are silly to debate. Since that's what scientists mean when they describe these well-tested theories, then they should describe them the way the public will understand, as laws.
So are people really this stupid, that they don't understand what a scientific theory is? If so, how are we supposed to have any sort of intelligent discussion about anything remotely based on science? Guess that explains the kind of public discourse we have these days that passes for "discussion." This really seems like more Idiocracy and Truthiness and the Triumph of Opinion over Expertise. [Read More]
What if everyone graded your boss and everyone knew what grade he got?
"The Employee Is Always Right" (Business Week) talks about India's HCL Technologies, which pretty much does this. They not only do they have 360-degree reviews, where an employee is evaluated not only by his managers but also his peers and those whom he manages. They also post those results where everyone who evaluated an employee can see his evaluation. The idea is to make the employee responsive to everyone he works with. The CEO, Vineet Nayar, is using this as a technique to attract and retain top talent.
Some quotes I like:
"In our day and age, it's the employee who sucks up to the boss," says Nayar. "We are trying, as much as possible, to get the manager to suck up to the employee."
"We're seeing more innovative methods coming from [emerging markets]...on how to structure and lead organizations," says Linda A. Hill [a Harvard Business School professor]
How do the Sametime instant messaging software and the Sametime Unyte meeting software go together?
I talked about the new Lotus Sametime Unyte product, a result of IBM's acquisition of WebDialogs. A reader (Michael Fitzpatrick) asks: "Does the integration with Unyte imply the old Sametime solution is being replaced, or will this be additive?" I have no particular IBM insider info about Sametime Unyte (and if I did, I wouldn't be able to talk about it here!), but here's what I've been able to find out from public sources.
It looks like the current version of Sametime instant messenger, 7.5, and the new Sametime Unyte meeting service from WebDialogs are currently related in name only. However, the plan (and it's only a plan, which can change) is for Sametime 8.0 to expand into a family of products, where one of the family members will include Unyte. I assume this means that you'll have functionality like being able to select several Sametime contacts and start a Unyte meeting with them.
How do you write a business case to justify your SOA project to your executives?
"Best practices for a quality SOA business case" (SearchWebServices.com) has some tips. The gist is to not focus on SOA, but to focus on the benefits the approach (which happens to be SOA) will have on the project. Explain to the executive what's in it for him/her, which is not SOA, but the business value and ROI of using SOA.
IT gets a lot of benefits from using SOA, such as greater reuse and faster development via reusable services. The #1 business benefit is business/it alignment. A book that explains the business benefits of SOA well is The New Language of Business.
You can now download a personal SOA assistant from IBM.
The IBM SOA Widget is a GUI you install on your computer that gives you access to IBM's latest materials on SOA. It uses RSS feeds, so whenever you run it, it lists the latest documents and displays the latest versions. You configure it for your job duties, so it delivers materials at the right level of technical depth for you and what you do.
The materials are listed in categories like these:
So, for example, hopefully it'll be good at letting you know when there's a new Webcast coming up.
This should make it much easier to find our SOA materials and to make sure you have the latest. Enjoy.
Note: IBMers, check my internal blog for additional details.
I've talked about how SOA can help achieve business/IT alignment. In fact, that's one of SOA's major selling points, that SOA can be applied to both the business and the IT department, making both composed of reusable services so that the IT systems look like the business.
One of my colleagues, Jorge Diaz, mentions this advantage as well: SOA helps align the development team with the operations team. In many companies, these teams don't work together well, with unfortunate consequences. The developers produce apps that require runtimes that operations doesn't support, or want to, or know how to. Operations deploys and runs apps differently than what development had in mind, such that they don't really run the way they ought to. The two groups don't coordinate to make sure that the running apps have the great quality of service (aka -ility) advantages like scalability, reliability, etc. The apps aren't written such that they can be managed and monitored effectively. These two groups need to work together, but often they do not.
SOA can help being development and operations together. SOA usually requires a runtime infrastructure; agreeing on what that infrastructure is goes a long way. Development creates apps to be deployed in that infrastructure; operations learns how to manage apps in that infrastructure. Development creates apps which not only have the desired functionality, but can be more easily and reliably tested, deployed, configured, monitored, managed, and diagnosed, which can make operation's job a lot easier and therefore more effective.
I think this development/operations alignment isn't as big a deal for those of us who come from a Java EE background. Java (esp. EE) provides a well-defined runtime and clear seperation between development and deployment into the runtime (mainly the EAR file with JNDI references to resources). SOA brings this seperation and alignment to a broader platform.
Not only is ESB an important part of any but the most trivial SOA, but also SOA is necessary to achieve value from an ESB. That's why the article talks about using an ESB to expose existing services, creating an ESB that new services then use for connectivity, and making an ESB part of a roadmap for adopting SOA that includes developing services which use the ESB. An ESB is part of an SOA, so they require each other. It's a bit chicken or the egg to specify which comes first, but establishing an ESB should quickly be followed by using the ESB to connect some services, whether the sevices came before or after the ESB.
Like I've now gotten in the habit of telling people: SOA puts the S in ESB.
Rational Software Comes to You brings the best of the Rational Software Development Conference 2007 to a city – or computer – near you. Delivered by or with our Business Partners, you’ll find half-day, full-day and virtual events focused on the latest development technologies, techniques and market trends.
There are events now through November in cities around the United States, including multiple "virtual events," i.e. Webcasts that anyone can attend. It looks like they're free.
WebSphere MQ provides your company with a powerful onramp to SOA through a scalable, transactional, high performance messaging backbone that supports your mission critical business needs and meets the latest standards. Your ideal entry point for SOA, WebSphere MQ supports future business growth and technology trends such as Web 2.0.
The speakers are Mark Simmonds, WorldWide Product Marketing for IBM WebSphere MQ, and Ben Mann, Worldwide Product Manager for IBM WebSphere MQ.
SCO is the company suing Linux vendors (such as IBM) for patent infringement. According to this CNet article, SCO lost a lawsuit to Novell a month ago, and another trial "was scheduled to begin Monday to determine how much SCO owed Novell as a result of last month's ruling, according to Groklaw ..."
IBM appears to not have made any comment today. This September 4th article by CBR Online (after the Novell ruling last month but before today's bankruptcy filing) gives lots of details on (reportedly) IBM's stance and its own evaluation of SCO's status. It concludes "... as far as SCO's core claims against Linux are concerned, the game appears to be over."
IBM has reiterated our support for the enterprise service bus (ESB).
I've talked about my latest article, ESB-Oriented Architecture, and some of the reaction it's gotten (ESB-OA on InfoQ, ESB-OA on InfoWorld, ESB-OA on ZDNet, and ESB-OA on TSS). Speculation in the blogosphere included that I, or worse all of IBM, was saying that we no longer think ESBs are necessary. That lead me to try to provide clarifications, statements like "ESBs good; ESB-only projects bad," which hopefully wouldn't be too confusing.
Several people in the blogosphere have misinterpreted this article as suggesting that IBM is now saying that you don't need an ESB--nothing could be further from the truth. The article actually suggests (and IBM's position is) that ESBs are useful and a necessary technical infrastructure, but that they should be adopted as part of adopting an SOA.
So if there was any confusion, hopefully that clarifies things. I and IBM think ESBs are good. Just do them as part of an SOA.
It's not what you say, it's how you say it. Well actually it's both.
In Words Don't Mean What They Mean, I discuss an article on a new book explaing that a sentence has two purposes: to convey meaning and also to negotiate a relationship with the listener. That's why the way we word things often makes no literal sense, and literal wording often seems overly frank and rude. Interesting stuff.
I believe that the RTP is one of the great American success stories, certainly for the state of North Carolina and probably for the American high-tech industry in general. Whereas the Silicon Valley in California developed more organically, RTP was deliberately planned through cooperation between government and industry to create a business environment that would lure high-tech companies to the area. The companies in turn offered students with advanced degrees from the area's universities to find jobs and stay in the area, and has attracted well-educated and highly-paid tech professionals to move to the area (like me). These companies and workers are definitely beneficial to the area's tax base and standard of living. I don't know how much that has helped the natives and others locals that don't have advanced educations, although professionals with disposable income generally help an area's service industries, construction, transportation, etc.
RTP has been much more successful than similar efforts like Boston's Route 128 and Austin's Silicon Gulch. Silicon Valley tends to be more entrepreneurial and fueled by venture capital, whereas RTP is populated predominately by large, established corporations with significant R&D efforts that they locate in the Park for the tax breaks and workforce. RTP is also becoming a good place for Silicon Valley companies to create an East Coast presence; Cisco Systems has its second largest set of offices in RTP; Sun Microsystems, Google, and Microsoft also have offices in RTP; IBM has its largest software lab and generally large number of offices in RTP. RTP has also become an unofficial capitol for the drug develelopment industry (Glaxo, Quintiles, etc.).
The folks who started RTP 50 years ago were quite visionary. North Carolina, the US, and the high-tech industry in general have benefited greatly.
I discuss this all in Truthiness and the Triumph of Opinion over Expertise. My general theme is that experts should be respected as experts, something that seems to be happening less over time or at least less often and to a lesser extent than it should be. As Matt describes, "becoming a genuine expert [is becoming] less attractive." I agree with that concern, and the trend shouldn't be the case.
Who are you listening to? Are they really an expert? Or are they just spouting uninformed opinions?
Let's hope I'm wrong. More specifically, we should hope that Mike Judge's film Idiocracy isn't prophetic. It is however, a good (not great, but interesting) movie, so check it out.
For me, the term "idiocracy" is now becoming an indictment I use to label any event or trend that seems to be bringing civilized society to ruin. Let's give it a try: Lindsay Lohan gets arrested for DUI again, and it's front page news? That's idiocracy. Try it yourself, it's fun (though depressing, too).
The e-book provides a concise and consistent overview of IBM's approach to SOA--our methods, architectures, and products for being successful with SOA. It compiles together all of IBM's various SOA materials in one place and gives it a consistent narrative that ties all of the pieces together.
The main topics in the e-book are:
Getting started with SOA -- including goals, challenges, and how to select a good project
Regarding your "ESB-Oriented Architecture" article: If you replaced the words "ESB" with "Process Server", would you still agree with the central premise of the article?
A project based on WebSphere Process Server would tend to be more successful (as judged by the criteria described in my article) than one based on an ESB product (such as WebSphere ESB, WebSphere Message Broker, the DataPower XI50, etc.). This is because Process Server has capabilities for implementing and hosting service providers, wrappering the functionality in external (aka legacy) applications as services, implementing business processes that orchestrate services, and so on. These capabilities, focused on services, tend to produce applications with functionality that users need, functionality that thereby produces business value. To draw on an analogy from my article, Process Server focuses on the faucets and drains that give the user access to water, instead of the pipes that covey the water. Just as (working) faucets also have pipes, Process Server has an ESB (WESB is built in, and you can augment it with WMB, DataPower, WMQ, etc.) which provides connectivity to the services, but the services (not the ESB) are what provides value to the users.
Just to make sure I'm being clear: I'm not saying, "Process Server good, ESB bad." I am saying, "Services good, ESB for connecting services good, services (and ESB) in Process Server good." And as the article said, "ESB with no services bad." I hope that removes any ambiguity.
Continuing trying to be clear: I'm not saying Process Server (or any other product, really) is some magic bullet that will automatically make a project successful. I'm sure one could come up with a project that uses Process Server to implement services that somehow have no value to the business. Such an application, despite running in Process Server, would still be a vestigial organ within the IT department, providing no value (only cost) to the business. I'm just saying that Process Server (and more so than any ESB product) lends itself to implementing services, ones which are somehow hopefully driven by some sort of requirements that hopefully are influenced at least in part by what would be helpful and valuable to the business.
Thus far, in describing Process Server and services, I've said "business value" several times. And that should point out that the question is kind of asking the wrong thing. The question isn't really, "Will Product X make an SOA project successful?" As I described in Business/IT Alignment, what makes a project successful is that it aligns with the busienss and produces business value. This business value produces ROI (see ROI from SOA), whereby the project which had cost to produce creates business value; the business value hopefully is sufficient to make the project pay for itself, and the quicker the better.
So if there's any magic bullet here, it's business value: The project (namely its results, such as a running application) should produce business value. SOA is one way (a very good way) to help make sure IT projects produce business value. Business services in an SOA that perform functions the business needs produce business value. SOA application server products (like Process Server), ESB products (WESB, WMB, DataPower, etc.), and SOA IDEs (like WebSphere Integration Developer) help code and execute business services in SOAs that produce business value.
So you need all of it--products implementing functionality in an architecture that produces business value. Like my article said, an ESB by itself won't get you business value. Process Server won't guarantee business value either, but by focusing on services, it'll get you a lot closer. In the end, regardless of product or technology, the goal is to produce business value--and that's something only you and your organization can judge.
Jean-Jacques generally gives the article a positive review: "Bobby's article expresses, with humor, the frustration of consultants facing some IT organization which has little or no knowledge about SOA and is pressed to show progress within unreasonable timelines in any way shape or form." Thanks.
I would like to clarify one of Jean-Jacques' statements: He says my article "questions the legitimacy of an ESB as the foundation of a Service Oriented Architecture." That makes it sound like he's saying that I'm saying that ESBs are bad. Where do I say that?! Actually, ESBs are good and are an important part of an SOA (maybe not the foundation, necessarily, but an important part). What's bad is a project who's only goal is to produce an ESB, defers on creating SOA apps to use the ESB, and thus tries to develop an ESB without any idea who'll use it or how. Instead, the project should develop the ESB as part of developing the SOA apps, not independently of and before them.
In a nutshell: ESBs good; ESB-only projects bad. Orient the architecture around the services, not the bus. Is that clear enough?! :-)
As I seem to keep saying: I just don't want my statements to be interpreted too broadly! :-)
The main comment I have is to caution that I don't necessarily speak for all of IBM. (I'm not sure any one person does, at least on matters like how to best use various technologies.) But I do stand by my opinions about what approaches I think work best.
I like the question-mark in his title because, no, I didn't say an ESB is as useless as a human appendix (although the title is catchy). The quote from the article in context actually says "ESB-oriented architecture is inherently flawed in that it builds connectivity no one might ever want to use. ... [Which can lead to the ESB becoming] the equivalent of a human appendix for the IT department, a vestigial organ within the topology of deployed applications." An ESB needs to be part of an SOA of services providing business value; without the SOA, the ESB is as useless as a human appendix. An ESB does provide value to the business, but not directly, only by providing access to the services that actually provide the business value.
I just don't want my statements to be interpreted too broadly! :-)
Sep. 6 Update: Brian O'Neill has posted a very helpful discussion of Joe's posting and my article (on his personal blog and his Java.net blog). Brian says "I completely agree with Bobby's statement and just (IMHO) believe Joe made an incorrect inference." Thank you, Brian.
A lot of the discussion wonders off into issues like "is SOA just Web services?", but some of the discussion is on target. James Watson makes (what I find to be) the most useful comments:
"Services can exist with out the web." -- Good point. I'm surprised this debate is still occurring.
"One of the reasons I don't like to talk about SOA and prefer the term service orientation is that it's not completely clear what qualifies as SOA and what does not. Service orientation is easy to understand and probably more crucial." -- Another good point. Service orientation is easier to understand and is the main goal. Exactly what makes it into an architecture, and how SOA co-exists with other architectures, gets a bit more vague and debatable.
"It's actually surprising to see someone from IBM writing the above. IBM tends to over-complicate everything. I always thought it was to get more consulting and support dollars." -- I agree, our products can be complex and difficult to use; we're working on improving that (see IBM Software Strategy and Product Overview and Jerry Cuomo on Project Zero). I also believe you usually need sophisticated tools to tackle difficult problems--a butter knife is no substitute when you need a chainsaw, a rowboat is no substitute for a submarine--and that IBM's product suite provides an unmatched level of support for tackling today's most difficult and most prevalent IT problems. Also, being in the services organization for the flagship set of middleware products (the WebSphere brand), I can assure you that our goal is to make our products both more powerful and easier to use so that we can help our clients increase their business value. IBM Software Group wants to make money from products, not services; we provide services to sell more product.
"What I got from the article was not that ESBs are bad but that you should focus on building services first and foremost. If you are focusing on the ESB and not on the services it's like building a highway to nowhere." -- Yes, James gets it! (Making him what Stephen Colbert calls an "it getter"! :-) Note that I'm not saying I push ESBs, but rather that I find my clients asking me to focus on ESBs more than I think is a good idea. I'm obviously a huge proponent of ESBs (read my blog! read my book!), but they're a tool to enable integration and SOA; ESBs are not a business goal unto themselves.
I like Eugene's and James' intelligent discussion. Let's hope for more like it on the TSS thread.
A reader comments: "I guess I have never quite understood how 'alignment' has anything to do with SOA as a technical architecture."
This comment was made by Matt M. on ESB-Oriented Architecture, in response to the statement in my article, "The primary goal of SOA is to align the business world with the IT world in a way that makes both more effective."
Matt, thanks for sharing your reaction. I think this topic--does SOA align business and IT?--is very interesting and worth discussing.
IBM feels that business/IT alignment is very important to SOA. I actually didn't author that statement in my article; it's a quote from IBM SOA Foundation. The action involved is sometimes expressed as aligning IT to the business, but I prefer the perspective of aligning them to each other so that both business and IT are active participants. (See Service Oriented Business.)
This alignment idea is not completely new. My COBOL programmer brethren can probably talk about writing business-oriented code back in the 1970's and even '60's. I know that back in the early 1990's (when object-oriented programming was really gaining momentum), Booch wrote books about developing OO domain models that simulate the business; so did Rumbaugh (and Grady and Jim are now both with IBM via Rational), as did Jacobson with use cases. Services perform the same sort of simulation, but at a coarser-grained level; services also add support for defined interfaces, context-free (aka stateless) invocation, and dynamically discoverable providers. Reusable SOA services are an evolution of reusable domain objects and use cases, not some completely new concept. (I even talk about "service use cases"; see Streamline SOA development using service mocks.)
What is new (or at least newer) is thinking of business in terms of reusable services that IT can then implement as reusable services. A lot of this thinking comes from business process modeling (BPM, aka workflow) (these days coded as BPEL), which models the business as reusable processes composed of repeatable actions. With SOA, the overall process and each of the actions are services. (I call these the service coordinator and service providers; see The Two Parts of an SOA Application.)
We also often distinguish between business services and technical services. The former have meaning to business people, such as process an order or check inventory. The latter do not, but are needed as part of a technical architecture, such as verify authorization or perform data transformation. The thing to realize is that while technical services are often (always?) necessary and valuable for implementing a working application, because they are not business services, they have no value to the business. Or to be more precise: The value of technical services is indirect in that they support business services which do have direct value to the business.
The focus of business applications needs to be on creating business value. That's how the business pays for the applications and the IT to develop and operate them. By modeling the business itself as a bunch of business services, those services embody the value that the business generates. By implementing those business services in IT applications, the applications create the value for the business. By supporting the business services, technical services create value for the business indirectly.
Just remember: It's the business that drives the business services that drive the technical services, not the other way around.
Are the companies using SOA to develop applications getting ROI?
According to "Companies still seeking ROI from SOA" (Computerworld), "only 37% of companies using service-oriented architecture (SOA) technology have seen it result in a positive return on investment." Also, "only 32% of published services are reused."
Want to make sure your project is one that benefits? The article makes some concrete suggestions:
The clencher is: "some departments in IT organizations are hesitant to invest in SOA because the ROI would likely be felt in other parts of the organization that aren't spending on the technology."
To me, more than anything else, I think this article makes the case for SOA governance. Governance makes sure that you get the most bang for your buck from SOA. It's the best way to help make sure that your project sees ROI.
I'll also point out that the book talks about development of business applications (whereas the original book mostly talks about frameworks). So if you're looking to apply the original design patterns in business applications or using dynamically typed languages, The Smalltalk Companion may help.
Rachel Reinitz talks about how to develop SOA skills.
"Developing skills for the SOA world" is an interview with Rachel Reinitz, a Distinguished Engineer in ISSW. This article is actually from back in May, but is very useful; I forgot to mention it before, but here it is now.
There are several feature packs available for WAS 6.1.
I've talked about the WebSphere Software Early Programs. Those are for all WebSphere products, including stuff like our Java 6 SDK, but only for feature packs that are in early release (alpha, beta, etc.). There are feature packs that aren't one of the programs any more because they're now GA (generally available).
The beauty of these feature packs is that they give you functionality that's newer than WAS 6.1 without having to wait for the next release of WAS. For example, WAS now has support for MTOM and XOP, which is newer than WAS 6.1 and normally otherwise wouldn't be available until the next release. Also, by making them available as betas/previews, you're able to try them out, report bugs, and request enhancements while there's still time for development to fix and improve them. Who knew IBM could be so responsive?
The Web Services feature pack adds support for MTOM and XOP (as explained in the info center). The package is WS-I compliant. It implements the WS-I Basic Profile 1.1. However, BP 1.1 is older than MTOM/XOP and so doesn't include them. WS-I BP 1.2 does include XOP 1.0 and SOAP 1.1 Binding for MTOM 1.0, but it's not final yet. The MTOM/XOP support in the WAS feature pack is compliant with latest draft of WS-I BP 1.2 (March 2007), which is about as close to standard as we have right now.
There was also a question about interoperability with Microsoft products. I can't speak for Microsoft (or IBM for that matter!), but Microsoft generally claims that their products are WS-I compliant. If so, then their products should eventually support WS-I BP 1.2 and therefore support MTOM and XOP. WS-I compliance also means that products from different vendors (such as those from IBM and Microsoft) are supposed to be interoperable. (See Interoperability vs. Integration and More on Interoperability vs. Integration.)
So: Yes, WebSphere now supports MTOM and XOP. To get it, install the WAS 6.1 feature pack for Web Services.
Update (Aug. 15): Note the comment from IBM's Billy Lo: He gave a presentation at Impact 2007 that demonstrated MTOM interoperability between WebSphere and Microsoft products.
IBM is characterizing Microsoft's SOA strategy as Windows-only.
This according to "IBM chides Microsoft over SOA" (CNet). Basically, IBM supports all platforms, whereas Microsoft (IBM claims) only supports the Windows platform.
This distinction is important because a big part of the promise of SOA is to enable and simplify integration of services and applications running on multiple platforms so that they all work together as what appears to the user to be one (composite) application. SOA should integrate programs on all platforms, not just on any one platform like Windows.[Read More]
The TRS-80, one of the first home computers, has turned 30 years old.
Tandy Corporation introduced the Radio Shack TRS-80 Microcomputer on August 3, 1977, which is thirty years ago last week. It was one of the first personal/home computers; the IBM PC didn't come along until 1982 (Wikipedia says August 12, 1981). Hard to believe now, but the idea that individuals could afford to own their own computer was a big deal. ("Only six electronic digital computers would be required to satisfy the computing needs of the entire United States." (Howard Aiken, 1947))
The first TRS-80 didn't even have a diskette drive; programs loaded off of casette tape, and slowly. I remember my middle school had one and a couple of friends of mine and I would play around with it to try to figure out what it could do. It had BASIC, so you could actually program it yourself; a good thing since there wasn't much software. So BASIC became the first programming language I learned--something else I learned in school that I don't use in work/life! Well, look at me now.[Read More]
Can it be that beauty is not just in the eye of the beholder, but that in fact it's a mathematical ratio?
I'd never heard of this before, but there's a so-called "golden number," aka Phi, which is 1.618 (or perhaps it's irrational: 1.6180339887...). What we humans consider to be properly proportioned often contains this ratio. Among other things, it's the basis for a grid of the human face; the better someone's face fits this grid, the more likely he or she is to be considered beautiful. Beauty, it seems, is somewhat universally agreed upon, in terms of a face being symmetrical and properly proportioned.
This seems far fetched to me, but there's a lot of discussion dating back hundreds if not thousands of years. It may or may not simply be a myth, but it is interesting. To learn more:
WebSphere ESB class by IBM; Raleigh NC, USA; October 9-11, 2007.
"Building WebSphere ESB Solutions within the IBM SOA Foundation" is not yet open for enrollment. If you're interested, register for notification; IBM will use the number of registrations to gage interest and decide whether to actually hold the class. There's no cost listed, but I believe these typically cost $1500/person.
This class is a RedBook Workshop. The sight currently lists 178 workshops total in the next several months at sites all around the world.[Read More]
I have created a Facebook profile for myself. I have to admit, it's not entirely clear to me what Facebook is for, but it seems to be the next great thing (since whatever the last great thing was), so I'm giving it a try. It supposedly is (or is becoming) a platform for social networking applications, which sounds interesting, but I don't know what that really means.
The best use I can think of for this stuff is helping me connect to my IBM co-workers and to customers I've worked with or at least who are interested in what I have to say. Then again, isn't that what this blog is for? But this blog is very one-way; maybe social networking will be more two-way. Which would be good, except I don't need to get pinged every time someone I know (or at least who knows me) does something that may (or may not) be vaguely interesting to somebody; I already get more status updates like this than I can grok, thanks. And really, IBM already has an internal directory of employees, so I'd rather extend that with descriptive symbolic links to my co-workers than go do that separately outside IBM's site. But non-IBMers can participate on Facebook, so maybe I need Facebook network that extends into IBM for my co-workers but outside for non-co-workers. Hmm.
Anyway, if you're in Facebook and you'd like to add me as a friend, please do so. Then we can see what all of this is good for.[Read More]
The IBM SOA Newsletter is published monthly on-line. It is focused more on business users than technical ones, but its content is relevant to both (unless all you want to do is design Web services!). Many of the articles are elsewhere on IBM's Web site, such as in developerWorks, but the newsletter gathers them together and highlights them. The main page has links to subscribe and to read past issues.
Jerry talks about Zero being about "radical simplification," the idea of an environment that makes programming as simple as possible, yet also powerful enough for writing real apps. Zero really is a new project from the ground up, separate from the other WebSphere products. Rather than try to simplify existing products--although efforts are always continuing to try to make our products easier to use--Zero starts over with the goal of trying to make things as simple as possibe, yet still powerful and useful.
Want to see how we're doing? Check it out at ProjectZero.org and let us know how we can make it better and more useful for the work you do.[Read More]
The authors are Russell Butek, a member of the same department I'm in and formerly a member of the Web Services Development team for WebSphere Application Server, which Nick Gallardo is a member of.[Read More]
IBM has launched a new incubator project: Project Zero.
Project Zero (FAQ) is producing a set of tooling and runtimes to produce Web applications and Web service providers using agile development techniques. Its programming model leverages Web 2.0 technologies: REST, ATOM, JSON, XML, Ajax, etc. The resulting apps will tend to be not so much enterprise apps per se, but mashups and that sort of thing; apps that are quickly produced, perhaps with limited usage and lifetimes.
It endeavors to be low overhead (practically zero!), with a simple programming model and lightweight runtime that make development and deployment quick and easy. IBM (and other middleware vendors, J2EE/Java EE and .NET in general, etc.) has gotten some criticism that its products are too heavyweight, too complex, don't support agile development, etc.; to the extent this may be true, Project Zero supports development at the opposite end of the spectrum.
A lot of initial criticism has focused on the assumption that Project Zero is or should be open source, which it is not. Project Zero intends to develop and sell commercial products, and so does not want to just give the source code away. But in a new model for IBM (and perhaps the industry), Project Zero is following what it calls a Community Driven Commercial Development process. While this process doesn't make the source code available, it does make the proto-products available sooner so perspective customers can try it out and offer feedback. The project hopes to use this feedback to be able to build the products customers want more quickly and accurately than IBM (and other vendors) have been able to do so in the past. The alternative to this approach is a new version of WAS or WMQ that takes a year or two to produce and that customers don't see until it's finished and too late for changes.
I see an opportunity for synergy between the traditional IBM software middleware products and the products that will come from Project Zero. Products like WAS and Process Server will still be great for hosting service providers that give access to enterprise resources in a reliable, scalable, and secure environment. Then Project Zero products can be used to quickly and easily produce service coordinator apps that mash up the services. This is Kent Beck's vision of abstractors and elaborators coming true.
I've updated my list of WebSphere conferences, including some new ones in Asia.
See WebSphere Learning Resources (on my wiki) for a list of WebSphere conferences. We've recently announced four in Asia: Bangalore, India; Singapore; Sydney, Australia (technically not is Asia; eh); and Beijing, China. We've also set the dates for IBM WebSphere Portal Technical Conference in the US and in Europe.
I get to go to a lot of our conferences and find that they're really a good way to get an overview of what IBM considers important (SOA!!), how we recommend that you make use of our products to derive business value, and where we're going with our products. They won't teach you everything you need to know about an individual product, although you can get some brief but meaningful depth on individual products; but they will teach you about what's going on with IBM in general. For example, see my notes from WebSphere Technical Exchange 2006.[Read More]
Search Google for images of WebSphere and what do you find?
My colleague Matt Rollo points out: If you search for "WebSphere" in Google image search, besides the usual pictures of IBM marketing materials and screen shots, picture #43 (or so) is a person. A familiar looking person. In fact, it's my picture. So, like Matt says, you can call me "Mr. WebSphere."
How do you declaratively specify the behavior of a service?
It's easy, or at least possible, to specify the declared interface for a service. A service's interface captures the signatures for invoking it and defines the data formats for exchanging parameters and return types between the service consumer and service provider. Such well-defined interfaces make integration between components (objects, services, applications) much less error-prone and problem determination much more definitive. But as the name "interface" implies, this only captures how to invoke a service; it does not provide an objective description of what the service does.
Right now, the best way I know to capture intended behavior for a service is using use cases and unit tests. In "Streamline SOA development using service mocks," I call these service use cases and service tests. Service use cases are a human-language description of a service that people understand. Service tests are a programmatic equivalent of the observable effects of those use cases; tests measure the behavior of a service and judge whether it conforms correctly to the intentions described in the use cases.
However, specifying behavior really needs to be more declarative than use cases and unit tests can be. An interface is declarative; either an implementation fulfills the contract or it doesn't. There seems to be no similarly declarative way to specify the behavior of a service. I think that business semantic modeling may be very helpful for capturing the behavior of an SOA service.
"Business semantic model" is a term getting tossed around in SOA circles these days. Unfortunately, I can't find a simple definition that says exactly what it is. The best source I've found for it is a paper that seems to be from 2004, "Unifying Data, Documents, and Processes." Yup, those sound like good things to unify. The business semantic model develops a uniform data model for the enterprise and captures the meaning of the data objects. What seems to be the key is the meaning of the objects (hence the word "semantic").
A similar term is "business process semantic model" (BPSM), which is being developed by the BPMI part of the OMG. According to Essential Business Process Modeling, BPSM is a metamodel for business process definition model (BPDM), a common model for all business process models. A Google book excerpt shows BPMI's recommended BPM stack. This is all very interesting; but will it lead to being able to declaratively describe the behavior expected of a service?[Read More]
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.
In the "all the interfaces are the same" case, surely the provider still has to give you the same information? You need to know what information to send and you need to know what it will give back and you need to know how to tell it that you want it to perform a specific service for you.
In the absence of WSDL (which, to my mind, is the important thing), how to you describe the services you're providing? Can you feed it into a tool?
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.
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.
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]