How should you set up WebSphere Process Server in your production environment?
I've talked about WebSphere Process Server (WPS) and the latest version 6.2. The simplest way to install a WPS runtime is a single server on a single node in a single cell, which is perfectly adequate for unit testing (and in fact is the topology for the WPS test server in WebSphere Integration Developer (WID)). However, this is not the best set-up for production. In production, you usually want a basic amount of high availability (HA) so that your users still get service even when part of your infrastructure goes down.
Let's take a quick look at what's in the golden topology. Two details to observe are that the cell contains two nodes and three clusters. Why is that?
Nodes -- The cell contains two nodes which should be installed on two different host machines (or perhaps two LPARs on the same host machine). This way, if one node crashes or has to be taken down for maintenance, the work will fail over to the other node and the users will still be able to do their work. During normal operation, workload management (WLM) will distribute requests across both nodes (and in fact also handles the failover when one node fails). An even better topology might have three or four nodes for increased redundancy.
Clusters -- Since the cell contains multiple nodes, the application should be deployed not in a single server running on a single node, but in a cluster with cluster members (aka application servers) on multiple nodes. In WPS, it's helpful to actually use three clusters, one for the business logic parts of the application and two for some of the main WPS infrastructure.
Business logic cluster -- This is where you deploy your SCA modules, including business process modules that run in the Business Flow Manager and Human Task Manager.
SIBus engine cluster -- This is for WPS to host messaging engines that are part of the service integration bus. A separate cluster is the easiest way to enable all of the business logic app instances to access the messaging engines even if/when they fail over.
CEI engine cluster -- This is for WPS to report what's going on for monitoring by products like Tivoli Composite Application Manager (ITCAM) (for IT monitoring) and WebSphere Business Monitor (for business monitoring). The separate CEI cluster helps lessen monitoring's interference with the business application.
So when deciding how to install WPS in production, the golden topology is at least a good start.
[BPM BlueWorks is] a cloud-based set of strategy and business process tools. BPM BlueWorks provides business users with the collateral they need to implement business strategies within their organizations based on industry-proven business process management techniques.
I don't find that description very helpful. It seems to be a lot of things to a lot of people: A tool for creating business processes; a cloud hosting that tool; a cloud hosting reusable process components which can be used by the processes developed with the tool; a community for developing these business processes. According to Michael Vizard:
The idea is that IT people and business executives can collaboratively model a business process and then export that model to a set of IBM Websphere Business Events software to execute it. The model serves to configure the Websphere software to match the business process. Because the model essentially represents a higher level of abstraction above the core middleware software, it also allows customers to update the business process as often as required, which for the first time allows IT to be responsive to the rapidly changing needs of the business.
I'm not sure what Websphere Business Events has to do with BPM. According to Sandy, BlueWorks is for creating "dynamic processes," which is interesting because processes usually contain a centralized plan (e.g. orchestration); dynamic implies the collaboration is more like choreography. If so, then WBE makes sense because it supports choreography, which is to say that it creates very dynamic connections between components.
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.
The book covers the DataPower products (announcement, background), network appliances with software built in that you just plug into your network, configure, and get ESB-style SOA connectivity.
IBM WebSphere DataPower SOA Appliance Handbook begins by introducing the rationale for SOA appliances and explaining how DataPower appliances work from network, security, and Enterprise Service Bus perspectives. Next, the authors walk through DataPower installation and configuration; then they present deep detail on DataPower’s role and use as a network device. Using many real-world examples, the authors systematically introduce the services available on DataPower devices, especially the "big three": XML Firewall, Web Service Proxy, and Multi-Protocol Gateway. They also present thorough and practical guidance on day-to-day DataPower management, including, monitoring, configuration build and deploy techniques.
The book is 960 pages long, so it should answer any questions you may have and then some.
So if you'd like to learn more, check out the book.
I plan to use the wiki to cover the same topics I discuss on this blog. "So," you might ask, "why have a wiki in addition to a blog?" (I answer the question on the blog wiki, so follow the link.) Does this mean I'm not doing the blog anymore? No, I plan to continue blogging. But I plan to use the wiki as a space to organize reference material that hopefully will be relevant over time, I may need to update over time, and you may wish to browse to get a more complete picture. That's hard to do with a blog, which is chronological. I plan to continue to use the blog to post timely material (stuff that isn't as interesting weeks and months later) and to point you to updates on the wiki.
What has pushed me over the edge to start publishing on a wiki is my DataPower discussion. I started it on the blog, but am now moving the documentation onto the wiki. I plan to continue talking about DataPower on the wiki, and to let you know what I've added here on the blog.
Hopefully this will make it easier for me to document what's going on with IBM, and for you to consume the information. If you have ideas on how this could work better, please let me know.[Read More]
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
What are some good articles for best practices for designing and implementing Web services?
A colleague recently asked me, "I'm actually looking for a Best Practices document regarding developing WebServices (not necessary in the context of SOA)." Here's a non-exhaustive and somewhat unscientific but hopefully helpful list:
"Best practices for Web services" series: Part 1 through Part 12 (developerWorks)
Use the createVersionedSCAModule command to create a new instance of a versioned SCA module when you want to deploy the same versioned module across multiple clusters in a cell. You must use this command once for each additional instance of the module you want to deploy. The new instance is created in a new EAR file; the new EAR file name contains the module version value and the specified unique cell ID.
This is useful because two SCA modules with the same name cannot be deployed to the same cell (because then some of the generated resources would have the same name and collide). So if you want to deploy the same module twice (say one for your internal employees to use and one for your external customers), you would previously have to deploy them in two separate cells. Now you can deploy them in the same cell as long as they're two different versions. The create version command doesn't change any of the code, so the new module runs the same as the old one, but it changes some of the component identifiers so that they don't have the same name.
Thanks to my fellow ISSW colleague David Currie for pointing out this command to me.