Bobby Woolf: WebSphere SOA and JEE in Practice
What's the difference between interoperability and integration?
I found this question in "Outstanding questions regarding BPEL and ESB" on the Richard Brown's Gendal World blog. Richard Brown is an ISSW coworker of mine in the UK and, from what I hear, quite smart. (Then again, he says he reads my blog. But maybe he's still smart anyway!) His blog is really good, BTW. Richard gets the question from James McGovern in a post with the same title, "Outstanding questions regarding BPEL and ESB."
So, what's the difference? Wikipedia says "Interoperability: the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols" and "Integration allows data from one device or software to be read or manipulated by another, resulting in ease of use." Yuck, those aren't much help.
To me, interoperability means that two (or more) systems work together unchanged even though they weren't necessarily designed to work together. Integration means that you've written some custom code to connect two (or more) systems together. So integrating two systems which are already interoperable is trivial; you just configure them to know about each other. Integrating non-interoperable systems takes more work.
The beauty of interoperability is that two systems developed completely independently can still work together. Magic? No, standards (or at least specifications, open or otherwise); see Open Standards in Everyday Life. Consider a Web services consumer that wants to invoke a particular WSDL, and a provider that implements the same WSDL; they'll work together, even if they were implemented independently. Why? Because they agree on the same WSDL (which may have come from a third party) and a protocol (such as SOAP over HTTP) discovered in the binding. How does the consumer discover the provider? Some registry, perhaps one that implements UDDI (which sucks, BTW). So SOAP, HTTP, WSDL, UDDI--all that good WS-I stuff--make Web services interoperable.
Another example I like is the "X/Open Distributed Transaction Processing (DTP) model" (aka the XA spec); see "Configuring and using XA distributed transactions in WebSphere Studio." With it, a transaction manager by one vendor can use resource managers by other vendors. Even though they weren't all written for each other, they still work together because they follow the same spec. They're interoperable.
Now consider two systems that weren't designed to be interoperable, or perhaps interoperable but with different specs. This requires integration. The integration code--could be Java, Message Broker, etc.; I co-authored a whole book on this--takes the interface one system expects and converts it to the one the other system provides. This is why WPS has stuff like Interface Maps and Business Object Maps.
So, you want interoperable systems; integrating them is simple. Otherwise, you have to integrate them yourself.
The latest version of WebSphere Application Server, WAS 6, has a new feature called "Service Integration Bus" (WAS benefits talks about "a new pure-Java JMS engine"). The SIB is implemented as a group of messaging engines running in application servers (usually one-to-one engine-to-server) in a cell. As a service in WAS 6, SIB is a complete JMS v1.1 provider implementation. (Not just the API; a working messaging system.) The JMS provider is a pure Java implementation that runs completely within the application server's JVM process. (For persistant messaging, WAS also requires a JDBC database such as DB2.) Thus JMS messaging is built into WAS and easily available to any J2EE application deployed in WAS.
Why Service Integration Bus? IBM's software customers over the past few years have divided into two overlapping but still distinct markets with different needs:
For a customer that finds itself in both groups--you have lots of WAS apps communicating, but you also need to communicate with other non-WAS apps--you will still need full WebSphere MQ. Embedded Messaging and Service Integration Bus only support WAS apps, so if any of the apps are not WAS apps, you need full WMQ. WAS 6 has a feature called MQ Link for connecting SIB and WMQ.
So here's the basic breakdown of WebSphere JMS options:
Feb 23, 2005
Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 1 -- The first in a series of articles on the SIB in WAS 6. Also see my blog posting, IBM Info on ESBs.
WMQ v7.0.1 and WMB v7 have a new feature for standby processes that make the products more highly available.
The feature in WebSphere MQ, introduced in v7.0.1, is called multi-instance queue managers. The corresponding feature in WebSphere Message Broker, introduced in v7, is called multi-instance brokers. In both cases, the queue manager or broker runs in two processes, one active and the other on standby. If the active one fails, the product automatically fails over to the standby, with virtually no service interruption. Note that any resources the processes use, such as a database, must have their own high availability capabilities.
Multi-instance queue manager
In prior versions, to make WMQ or WMB highly available, one had to use hardware clustering (such as PowerHA (formerly known as HACMP) or Veritas). Hardware clustering may still be the gold standard for HA, but for environments that don't quite need the gold standard, software clustering via multi-instances may be good enough.
This new design reminds me of how the service integration bus in WebSphere Application Server works. An SIB bus is a collection of messaging engines managed by the WAS HA manager. By default, it runs two copies of each messaging engine, an active and a standby. If (parts of) the cluster lose communication with the messaging engine, the HA manager switches them to use the standby. Only one copy of the messaging engine can be active and only that one can maintain a lock on the external storage for the persistent messages. Multi-instance queue managers work in much the same way.
The new Redbook High Availability in WebSphere Messaging Solutions contains a section on multi-instance queue managers and brokers. To quote:
WebSphere MQ V7.0.1 introduced the ability to configure multi-instance queue managers. This capability allows you to configure multiple instances of a queue manager on separate machines, providing a highly available active-standby solution.
So if you needed a reason to upgrade to WMQ and WMB 7, now you have it.
Thanks to my colleague Guy Hochstetler who made me aware of this new feature.
We've updated the Recommended Reading List for JEE and WebSphere Application Server.
I've talked about our Recommended Reading Lists, compilations of what we think are the best articles for getting started in a topic area. We update them from time to time to add the latest articles.
We have just updated the Java EE (fka J2EE) reading list: "Recommended reading list: Java EE and WebSphere Application Server." Thanks to ISSW's Sree Ratnasinghe for making the updates. Check out the list, I think you'll find it helpful.
I find that customers often confuse the role of an environment with its quality of service.
I previously discussed Data Center Environments, specifically the typical environment roles of Dev, Test, Stage, and Prod. These separate environments keep code under development (Dev) away from code the enterprise's users use to do their work (Prod). They also create a reliable, controlled environment for performing testing (Test) and for practicing installation and migration procedures (Stage).
These are environment roles, which describe who should be able to access an environment, what it is used for, and therefore what it should and shouldn't contain. For example, only the Prod environment should be able to access and change real customer data. Stage may contain a separate copy of the production data. Dev and Test shouldn't even have a copy of the production data, which is probably confidential and should be protected, but instead should conatin a representative set of fake data. (Use a Data Obfuscator to produce test data from a set of production data.)
The role of an environment is often confused with the quality of service (QoS) an environment should support to meet its requirements. One common example is availability. The applications running in Prod are typically assumed to need to be available 24x7 (aka always). Test and Stage are understood to be unreliable, that they may be taken down or crash at any time as testing needs dictate. The Dev environment is typically assumed to be fairly reliable, but with the understanding that outages are acceptable.
These assumptions about the availability of different environments can become a problem for repository products like Rational Asset Manager (RAM) and WebSphere Services Registry and Repository (WSRR). Dev environments are typically not managed for reliability, yet products like RAM and WSRR (used in development to manage SOA governance) need to be reliably available. This is likewise true for the source code management system, but somehow the reliability requirements of RAM and WSRR are seen as being much more complex.
Long story short, customers often decide to install RAM and WSRR in their Prod environment simply because that has people prepared to manage WebSphere Application Server (WAS) servers (which is what RAM and WSRR run in) and make those WAS servers highly available. This, in my mind, is kind of crazy. RAM and WSRR store development artifacts, which are not used by production applications any more than source code is, and so should not be stored in Prod.
Customers often insist on installing RAM and WSRR in Prod because it's set up to make them highly available. I think the far better approach is to set up a couple of WAS servers in Dev for reasonable (maybe high) availability and install RAM and WSRR there, and assign personnel (who perhaps normally work in Prod) to manage those servers in Dev.
I'd be interested to hear from customers using RAM and/or WAS: What environment do you have them installed in?
IBM developerWorks Author Achievement Recognition Program
In Impact 2009 roadshow series - Impact Comes to You, Travis Walker has linked to the info for Impact Comes to You 2009 (this year's version of Impact Comes to You 2007).
Want to learn more about IBM's take on cloud computing?
IBM has launched a new channel on YouTube, IBMCloud. It's a collection of videos that further explain cloud computing.
The main video is Introducing Smart Business Development and Test on the IBM Cloud:
One I like in particular is IBMers on How Cloud Computing Will Make IT Easier:
One way they explain that cloud computing makes things easier is setting up test environments and making sure your development environment is set up the same as your test environment. This is one of the strengths of the WebSphere CloudBurst Appliance, described further in IBM CloudBurst: Simplifying the IT environment for better productivity:
IBM has posted some other videos about cloud computing that for some reason aren't listed on this channel. (Probably because they were posted before the channel was created.)
There are a couple of dW blogs on cloud computing:
Thanks to my fellow ISSW consultant Sreekanth Iyer for pointing out the YouTube channel to me.
In response to: Sample application using WPF - part 1Sami, thanks for making available these videos showing how to build a simple demo application using WebSphere Portlet Factory (WPF).
In response to: SOA for Dummies 2nd IBM Limited Edition Mini eBookThanks for letting us know how we can download the new edition of the SOA for Dummies Book IBM Edition mini book, now in e-book form.
In response to: Cloud - SOA = ZeroI think you've made a very good point here. A lot of the focus of cloud computing is deploying an entire app on a public cloud so that it can be accessed from anywhere on the Internet/Web and so that the app owner doesn't have to host it on his own equipment. Even in this scenario, I think it makes sense to design the app as an SOA for all the reasons that SOA generally makes for better business apps than a traditional monolithic layered architecture (a.k.a. enterprise application architecture) has. But an equally important approach which I think is a lot less recognized is that individual SOA services can be deployed to public and private clouds, making them easy to host and easy to access with consumer applications and composite services. When an app or composite service aggregates several services, those services don't have to be deployed in the same data center or cloud as the app, they can be deployed in various other clouds. Like I said in Intro to Cloud Computing, "cloud computing sounds like SOA and ESBs to me."
I've posted a review of the IBM SOA governance book.
I've talked about the IBM SOA Governance Book. I've been reading it an found it quite educational. I've now posted a review on Amazon: Make SOA Projects Predictable and Productive. In the review, I gave the book five stars. Here's the review:
Make SOA Projects Predictable and Productive
SOA Governance: Achieving and Sustaining Business and IT Agility is a fantastic book which shows how any service-oriented architecture project can be run more predictably and productively, decreasing cost and increasing ROI. The architects and project managers in charge of any significant SOA project should know the material in this book.
No book is perfect, nor is this one. Chapter 6 on managing the lifecycle is not as strong and badly needs more copyediting. For example, after doing a nice job of distinguishing between processes and tasks (p. 268), other parts of the chapter start distinguishing between tasks and what are sometimes called processes but sometimes called services. I’d also quibble that they focus overly much on whether operations can be automated since it’s also valid for a task in a process to be a human task. Nevertheless, these complaints are minor in what overall is a collection of very useful information.
(Disclaimer: I, like the authors of this book, am employed by IBM.)
How would you like to learn about the latest set of WebSphere BPM products?
IBM Business Process Management Journal is an e-magazine dedicated to WebSphere's SOA/BMP products--like Process Server, Business Modeler, etc.--namely the latest release, version 6.2 (InfoCenters).
Note: The e-mag was published in December, when these new versions were brand-spanking new. It was very timely, which is more than I can say for this blog posting. My only complaint is that I was waiting for them to publish another issue, but it looks like it's just a one-time thing.
Now you can build communications enabled applications in WebSphere Application Server.
The IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications, one of the WebSphere Software Early Programs for WAS 7.0, enables you to make your WAS JEE application into a communications enabled application.
So what the heck is a communications enabled application (CSA)? Imagine your user is browsing your Web site and has a question. The user can call a customer service representative, but then the CSR has no idea what Web pages the user is looking at and can't help the user browse to find what they're looking for. With CSA, the user can click a button on the Web page to contact the CSR, which then opens up a connection like an IM chat, a VoIP discussion, or the user enters their phone number and the CSR calls it (aka click to call). Not only does this make it easy for the user and CSR to have a conversation, but the button can also enable the CSR to share the user's browser screen, looking at the same Web page the user is seeing, and together they can collaboratively browse the Web site (aka cobrowsing). This enables the CSR to help the user find what they're looking for and even fill out orders and other forms. A similar button can enable a user to share a Web page with another user so the two can then browse the same site together from two different computers (aka peer-to-peer cobrowsing). This would, for example, enable two users to jointly browse for a gift for a third person without having to be at the same computer.
There are non-WebSphere, third-party packages for CSA, but all they really enable is click to call. The CSA is not built into the app, so the CSR can call the user and know something about the user's context when they clicked the button, but can't cobrowse. The app developer also has to learn how to program the CSA package which doesn't necessarily have a well-defined Java API like the features in WAS. Because the third-party CSA is a separate app, it has to be installed and administered separately in the runtime environment and may not have WAS's QoS features for scalability and failover. WAS CSA is a better approach because it integrates the CSA features into the WAS app, supports a single integrated Java programming environment, and runs on the WAS platform your app is already using.
WebSphere CSA is also JSR 289 SIP Servlet 1.1 compliant.
The WebSphere development team that created the CSA has their own blog, appropriately titled Communications Enabled Applications. This blog is a good place to get the straight dope on how WebSphere CSA works and how to use it. It includes several YouTube videos that show how it works. For example, here's one where Erik Burckart, the chief architect for CEA, explains how cobrowsing works:
As the video shows, the two peer-to-peer cobrowsing users can chat about what they're browsing using an IM built into the Web site.