The DataPower products are network appliances. Like an IP router or hub, it's a box; the entire interface is four Eathernet ports and a serial port (and a power cable). It's rack-mountable; its size is 1U, or about the size of a large pizza box. The software is all firmware, with flash memory for configuration settings. There's really nothing to install; you unpack it from the shipping container, plug it into the network, and start using it. You do need to enable it, and you need to configure it, which is a little like programming, but much simpler than a traditional software server like a database or a J2EE app server.
DataPower XI50 XML Integration Appliance
Interestingly, even though DataPower is effectively a hardware device, it's grouped as part of IBM's WebSphere brand. This is kind of an odd choice, since Systems Group is the part of IBM that makes hardware. Software Group's products come on CDs or can be downloaded, and are installed on host computers. But DataPower was added to Software Group, and specifically the WebSphere brand, because the appliances have really great synergy with our enterprise service bus (ESB) products.
As I get time, I'll talk more about what the DataPower products do and how cool and useful they are.[Read More]
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]
Also on top of the ASTK is WebSphere Integration Developer (WID), which adds features for developing SCA components.
Notice that WID is not built on top of RAD; they're seperate and designed for two different types of developers. RAD is for application developers whereas WID is for integration developers, the people who design how apps will fit together and talk to each other. IBM expects these to be different people with different skill sets and thus needing different tooling. For developers with both application and integration skill sets that wish to do both, you can buy both RAD (or RSA) and WID and install them in the same Eclipse install so that you'll have one large IDE with both sets of tooling.
WID is the IDE for developing "applications" (really SCA modules) deployed into WPS and WESB. [Read More]
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.
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
[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.
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.
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)
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.