Bobby Woolf: WebSphere SOA and JEE in Practice
Bobby Woolf 120000HQ53 637 Views
This is a bit outside the scope of my blog, but interesting news: Carly Fiorina (no longer here), the chairman and CEO of Hewlett-Packard, has resigned. Fiorina has been facing pressure from HP's board and stockholders because the controversial merger with Compaq she spearheaded in 2002 has not produced the increased shareholder value that was promised. HP and IBM are often seen as each others biggest competitors.
See Carly Fiorina steps down as chairman, CEO of Hewlett-Packard and HEWLETT-PACKARD: Why Carly's Big Bet Is Failing.[Read More]
Are cell phones achieving network neutrality?
"How Apple's iPhone Reshaped the Industry" (Business Week) discusses how the usefulness of cell phones is moving from making calls and sending text messages to running applications. Thus the most important aspect of your phone is shifting from who is your service provider (in the US: AT&T, Verizon, Sprint, etc.) to what platform the phone embodies (such as Palm, BlackBerry, or iPhone). This represents a loss of power for the service providers; they're being disintermediated.
Not so fast (it seems to me). You typically (in the US) buy your cell phone from your service provider, and that phone only works on that provider's network. So although AT&T and Sprint sell virtually identical BlackBerry models (to pick an example), a BlackBerry you buy from AT&T won't work on Sprint's network and vice versa. This is partially a technical issue (CDMA vs. GSM, two different standards for cell phone networks and thus the chip in the phone that wirelessly connects the phone to the network), it's also political: The service provides subsidize the cost of the phone when you sign-up for a long-term service agreement and otherwise don't want you using their phone on another network.
Computers don't work this way. If you want a Dell PC, you don't buy it from AOL (to pick an example) and then have a computer that can only connect to the Internet via AOL. No, you buy a computer from your favorite vendor (Dell, Lenovo, Apple, etc.) and then connect via your favorite ISP (AOL, Earthlink, your hotel's wi-fi network, etc.). Any computer works with any Internet provider. Both groups have to constantly compete to provide the best equipment and service to get you to continue to choose them instead of the competition.
The cell phone industry doesn't have this kind of interchangeability, where any phone will work on any service provider's network. Until that's the case, I'd say we're still pretty locked into our service providers. Google was supposedly working towards a cell phone that works with any carrier (see the Open Handset Alliance, such as "Breaking Wireless Wide Open" (Business Week)), but the Google G1 cell phone only works with T-Mobile (in the US); so much for neutrality.
I just learned about a rather surprising change to the way JMS Sessions work in J2EE 1.4.
Section J2EE.6.6: JMS 1.1 Requirements of the J2EE 1.4 specification states:
This means that in a J2EE container (web or EJB), a Connection can only have one Session. The spec doesn't explain why this change has been made, but it has to do with the way JMS is now built on the J2EE Connector Architecture 1.5 (commonly though unofficially called "JCA") and the way its connection model works. In JMS, a Connection represents a connection to the messaging provider and a Session represents a transaction within a connection. In JCA, a Connection represents both a connection and a tranactional context. To make a JMS connection work like a JCA connection, it can only have one session.
As a practical matter, this won't make code less efficient because connections are pooled and reused by the container. But it does affect the way you write your code. (In a J2SE container, a JMS client still has the previous behavior of a JMS Connection being able to support multiple Sessions.)
This change in J2EE 1.4 means that when you port your J2EE 1.3 code (from WAS 5 to WAS 6, for example), you need to review the places in your code that create JMS sessions and make sure they only create one session per connection, or else the code will fail at runtime. It won't affect your MessageDrivenBean (MDB) code because the container creates the connections and sessions for MDBs (for example, in WAS, this is managed by a ListenerPort). Likewise, your J2EE code probably doesn't create MessageConsumers; it should use MDBs instead (unless you have an aversion to EJBs in general). But this change may well be a problem for your sender code.
What you need to search for is code creating MessageProducers (i.e. QueueSenders and TopicPublishers) that does something like this:
(For simplicity, this example shows JMS 1.1 code. Your JMS 1.0.2 code will use the corresponding Queue- or Topic-specific subtypes.)
The problem here is that connection is being used to create both session1 and session2. You will need to change this code for J2EE 1.4 to create two connections, then create a session for each. On the other hand, if you existing code creates a Connection and then uses it to create only one Session, that code will work fine in J2EE 1.4 as is.[Read More]
IBM's Christina Lau has a new blog on developerWorks.
On The Business Process Management Experience, Christina discusses business process management (BPM) and the associated WebSphere BPM products. BPM is becoming a really key area within IBM, a major part of achieving business/IT alignment. Christina has just been promoted to Distinguished Engineer (DE), leading the BPM Architecture and Advanced Technology Team. It's great that she's taking the time to write down her thoughts for our benefit. Check it out.
Say that you're nobody's boss, you're just a cog in the big machine (so to speak). How do you get anything done? A technique IBM (and others?) terms "collaborative influence."
Collaborative influence is another topic discussed in "IBM's Management Makeover" (Nov. 2004) in Fast Company magazine, the same article that discussed how IBM Customers Are Clients:
The 33 leaders [who had been identified as outstanding leaders in the new on-demand era] were also adept at a skill IBM calls "collaborative influence." In a highly complex world, where multiple groups might need to unite to solve a client's problems, old-style siloed thinking just won't cut it, and command-and-control leadership doesn't work. "It's really about winning hearts and minds -- and getting people whose pay you don't control to do stuff," says Mary Fontaine, vice president and general manager of Hay's McClelland Center for Research and Innovation.
So collaborative influence is how you work with people you have no direct control over, yet persuade them to do what you'd like, what is hopefully beneficial for the group.
I wasn't familiar with this term, but as a consultant to some of IBM's WebSphere clients, I often feel like this sort of persuasion is the only real power I have. I can't fire anyone; in fact, if anything, they can "fire" me (from their project, not IBM). Yet I need to convince them to stop doing some of what they're doing, since apparently that's limiting their success with WebSphere products, and start doing things differently, even though they may well not want to.
I'd argue that in our modern workplaces, and in life in general for that matter, the only real power any of us really has is collaborative influence. We all work with lots of people we can't fire, yet whom we need to persuade to take certain actions to help all of our success. Even bosses have pretty limited authority: Yeah, they can fire you; but if you have good skills, you'll just go get another job somewhere else, and now your boss and his/her team are without the benefit of your skills. D'oh! The best bosses, I find, are those who attract the best people they can find to their teams, encourage everybody to work together, and then get out of the way. That's collaborative influence.
I think collaborative influence is an important component of leadership, a quality we all need to get better at. Many of the non-programming books I read are on leadership, teamwork, and that sort of thing; I'd suggest you should too.
I'm pleased to find that IBM has an article on collaborative influence called "Changing Minds":
You can upgrade your IT. You can rewrite your processes. But you won't change your business if you can't change your people--how they think, how they work together and how they use the resources around them.
It's on a section of our web site called "Boost team performance," kind of a developerWorks for workplace skills. It has articles, case studies, and executive guides. (Shockingly enough, we even have some services we'll sell you to help you achieve this.) The theme of boost team performance:
Bring your people, departments and partners together to boost productivity, streamline the workload and sharpen employee training for a constantly changing world.
So not only is your IT on-demand, your whole company and workplace is an On Demand Business. Yeah, this gets kind of hypish, but the focus here is on helping people to work together, and I think that's important.
So, do you have collaborative influence? What can you do to get more? How can you use it to do your job better?
What's with all these blog postings that begin "Re: ..."?
Some of our blog postings are starting to look like e-mail replies, with titles that start "Re:". For example, I have posts today called Re: Cloud - SOA = Zero, Re: NEW RELEASE: IBM Support Assistant v4.1, and Re: SOA for Dummies 2nd IBM Limited Edition Mini eBook. What are those?
These "Re:" posts are a new feature of the My developerWorks blogs. When you're a blogger on MydW and you comment on someone else's MydW blog, you also have an option to cross-post your comment as a posting on your own blog. So when I commented on Doug Tidwell's post, Cloud - SOA = Zero, my comment also appeared on my blog as Re: Cloud - SOA = Zero. Also, where my comment appears on Doug's blog posting, the comment has a Trackback link which connects to the posting of this comment on my blog. And the posting of the comment on my blog has a header with a link to the original post on his blog. It's all interconnected.
So if you're interested in what I have to say about stuff--and presumably you are since you're reading my blog--you can also easily find comments I've made on other people's blogs and easily jump to those original blog postings I commented on. And these links can daisy chain, with a comment on a comment on a posting, showing a conversation between two authors or several.
This is going to be a good way for me to show you postings on other blogs that I think you'll be interested in. For example, I commented on postings about SOA for Dummies and IBM Support Assistant for two reasons:
To my fellow MydW bloggers: Let the comments rip!
SOA breaks a monolithic application into a collection of parts, a composite application.
Loosely Coupled gives a quick definition:
composite application -- An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).
Applications are traditionally monolithic. Two applications may share the same reusable framework or component, but they each contain their own copy of the code and run it separately in their own process. Even an application with an n-tier architecture is a monolithic architecture distributed amongst multiple processes.
What makes SOA different is that applications share running parts--called services or service providers--not just at development time but at runtime as well. If a shared part goes down, the outage affects multiple applications. So an application is made of multiple parts, some of which are shared with other applications. Is such a shared service part of app A or app B? It's part of both. So the "composite application" term not only describes that the application is in multiple parts, but that the parts are shared between applications.
I've talked about The Two Parts of an SOA Application, service coordinators and service providers. The providers are the shared parts. The coordinators tend not to be shared, although they can be composite services that are reusable service providers as well. I expand on these ideas, and how to make use of them, in Streamline SOA development using service mocks.
What is a composite service?
There doesn't seem to be a whole lot of agreement (yet) in the industry, or perhaps even within IBM, on what this term means. But here's my take, at least.
In the tradition of the composite pattern, a composite service is a service whose implementation calls other services. This is as opposed to an atomic service, whose implementation is self-contained and does not invoke any other services.
A composite service acts as both a service provider of the (composite) service and as a service consumer of its child services. The composite can be considered to be aggregating together the child services into a bigger service. A composite service is one kind of what I call a service coordinator, a coordinator that also itself is a service.
In "Service-oriented modeling and architecture," IBM's Ali Arsanjani shows composite and atomic services in the Services layer of an SOA:
The layers of a SOA
You cannot tell from a service's API whether it's composite. In fact, two providers may implement the same service, one in a composite fashion and the other in an atomic fashion. A provider implemented one way might be reimplemented the other way; this change makes no difference to the consumers because the interface is still the same.
Service component architecture (SCA) supports composite service components. Recall that an SCA has a service interface and service references. Those references give the implementation the ability to call the other services referenced. They also serve as a declaration that this component needs these services, much like a Java class importing other Java classes. An SCA with no references is atomic; one with references is composite.
Service Component Architecture overview
A business process is a kind of composite service. A business process can be invoked as a service, a request to perform its functionality. The process contains a sequence of activities implemented as services, so therefore is a service that calls other services. That's a composite service.
In my mind, a business process is a special case of composite service. Usually, a service executes what might be described as synchronously. (The execution can be invoked synchronously or asynchronously.) A service has a return value (or exception); it is returned at the end of execution. The consumer usually waits (but not necessarily with a blocking thread) while the service executes, and does not continue until the service completes and returns its result.
What makes business process a special case is that a caller usually doesn't wait while the process executes. A caller invoking a business process (synchronously or asynchronously) usually waits only while the process starts, to confirm that it starts successfully. But once the process starts, it runs on separate thread(s) "in the background" while the caller proceeds with other work.
Because of this difference, it seems to me, although a business process is just another service and another way to implement a service, a caller usually knows whether or not the service it's invoking is a business process. If it's not, the caller cannot tell whether the service is composite or atomic, but if it waits for a return value, then the service is most likely not a business process.
As of WAS 7.0, you can now connect an MDB to a remote SIBus.
Great, so what does that mean? The Service Integration Bus is the feature as of WAS 6.0 that is a built-in JMS provider. Message-driven beans are EJBs for receiving JMS messages. For an application's MDB to receive messages from a queue in a particular SIBus bus instance, the application must be running in a WAS application server or cluster that is a member of the bus, basically meaning that the bus has one of its messaging engines running in the server/cluster. Thus when an MDB reads messages from a queue, the bus for that queue is essentially local to the application.
An MDB is configured by a JMS activation specification. The JMS activation specification in WAS 7.0 adds a new property, Provider endpoints, which (as the docs explain somewhat subtly) "allow the applications to consume messages from a remote cell." Technically, it will work with any remote bus, but the main reason to connect to a bus remotely is because it's in a different cell; if it were in the same cell, you could just add the application's server/cluster as a bus member of the bus and therefore make the bus local to the app.
With this property, when the MDB pool is activated, the beans will first try to connect to the bus specified in the Bus name property (if any). When that fails, it will then try to connect to the buses specified in the Provider endpoints. These Provider endpoint buses need not be local ones--ones where the server/cluster is a bus member. Because the buses are specified by the host name and port number of their bootstrap server (essentially, the point for connecting to a bus remotely via TCP/IP), the bus can be remote--the server/cluster does not have to be a bus member. A remote bus is sometimes also referred to as a foreign bus.
Normally to connect to a foreign bus, you need to use a service integration bus link to connect one of your server's local buses to the foreign bus. This is still the only way to send messages onto a destination on a foreign bus. But to receive messages from a destination on a foreign bus, you can now configure an MDB to connect to the bus remotely, bypassing the server's local buses (if any).
This new feature is now also available in WAS 6.x, but requires a fixpack. See PK77768: PROVIDER ENDPOINTS PROPERTY ON ACTIVATION SPECIFICATION NOT AVAILABLE WITH WAS V6.0/6.1 for more details.
Thanks to my colleague Rajesh Ramachandran for letting me know about this new feature.
I haven't posted a movie review on this blog before, but I think the movie The Hitchhiker's Guide to the Galaxy is probably of interest to many readers of this blog. I also apologize to any international readers in places where this movie has not been released yet (although, as you'll see, you're not missing much).
I like the five books in the trilogy a lot and I really wanted to like this movie. Unfortunately, the movie is incredibly tedious; not awful or stupid or shockingly bad, like when a movie totally ruins a book, but just very very boring. Stuff which seemed clever and interesting and psudo-scientific in the book(s) repeatedly fell flat in the movie. It was like watching a standup comedian where every time he said the punch line to a joke and paused for laughter, there was none because it wasn't funny. I didn't hate the movie, I certainly didn't love it, I was just bored and wished I'd spent my afternoon doing something else.
For huge fans of the book, go ahead and see it anyway (if you haven't already) just to satisfy your curiosity. But go in with lowered expectations; they still won't be met. Think of it as a friend telling you about the book rather than you reading the book yourself. Remember Dune? Yeah, like that.
To be fair, there were a handful of people in my theater who laughed out loud at key parts and really seemed to be enjoying themselves; I believe they would've liked anything. For the rest of us, don't go see the movie unless you have nothing else to do--or, alas, go with some friends to make fun of it MST3K-style, which is hardly a compliment.
Ah well, like many good books, maybe the Hitchhiker's Guide series should just remain books.
What is it that makes stateless session beans and stateless services, well, stateless? Do they truly have no state?
I discuss this on my wiki in Context-Free Methods.
I prefer the term "context-free" to the term "stateless" because all code has state. ... What makes code "stateless" is that it doesn't know what context it's in ... Any necessary context is passed in from the caller.Hopefully interesting and even a bit educational. Check it out.[Read More]
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?
One issue I see customers get confused on is the purpose of separate but equivalent software environments.
An enterprise should divide its IT servers and software into multiple separate and fairly independent environments. The number and purpose of these can vary somewhat, but a typical separation is these four environments:
These environments are actually four roles than an environment can play. An environment in the Dev role needs development tools and test data, but probably doesn't need monitoring. The environment in the Prod role is the only one that should store confidential customer data and should have monitoring to verify that it's running properly.
The role of an environment is independent of its quality of service (QoS) requirements, a topic I'll discuss in my next posting.