Swagger-ui with Websphere Application Server

To deploy the swagger-ui on WebSphere Application Server get the source code from github first. Create a Simple Web Project in Eclipse and copy the content of the ‘dist’ folder from the zip archive into WebContent folder. Make sure you have the WebSphere Development Tools plugin installed in Eclipse. You can find it in the Eclipse Marketplace.

Now set the root context to /swagger in ibm-web-ext.xml. Export the project as WAR and deploy on the Application Server.

 

To point by default to your own RESTful API with swagger annotations change the url in the index.html file.

Review: WebSphere Application Server Administration Using Jython

Recently, I was asked to review the book WebSphere Application Server Administration Using Jython.

First impressions are excellent – the book is thorough, first introducing the Jython language itself (which is essentially Python running on a Java Virtual Machine – and very easy to learn), then moving to talk about the wsadmin tool, which is used to execute administrative scripts or command in Jython with WebSphere. It’s worth pointing out that WebSphere currently supports two scripting languages – Jython and JACL, and Jython is the strategic direction forward for WebSphere, so it’s good that the book focuses on this (also, in my humble opinion, Jython is much easier to learn).

The book then moves on to the meat of the subject, discussing each of the four primary WebSphere administrative objects in turn. There are dedicated chapters for various important and frequently-used topics, such as security, databases, and messaging. In general, these are thorough and of high quality.

The only minor point against the book is that it covers only WebSphere Application Server, not any of the stack products that build on top of it (such as WebSphere ESB and Process Server, which is the primary focus of this blog). However, this is expected – it’s in the title – so is hardly a criticism.

Generally speaking, this is a thorough and useful technical book for anyone wanting to do scripting with WebSphere Application Server.

Disclosure: I recieved a free copy of the book in exchange for this review – that’s all.

WebSphere Application Server 7.0 Administration Guide: Review

I was recently asked to review the new book WebSphere Application Server 7.0 Administration Guide by Steve Robinson. First impressions are good; the book looks professional and comprehensive. Steve starts from the basics, installing WebSphere Application Server from scratch. He walks through some administration tasks that I might expect an experienced system administrator or developer to be able to do without trouble (details on un-taring a file, for example), and a little more information at various points would be welcome: for example, although Chapter 1 describes creation of a profile, it doesn’t really explain what a profile is or why it would be needed, referring only to an “application server definition”.

Nevertheless, taken as a whole, the book is generally thorough, and certainly covers the basics for someone with little WebSphere Application Server expertise or exposure. Steve looks at administrative security, scripting, messaging via the System Integration Bus, and so on. As the title implies, the book doesn’t talk much about application development, but that’s fine. There’s nothing here you wouldn’t find elsewhere, but Steve does a good job of collecting it all together, and presenting WebSphere administration topics in a coherent and logical manner.

It’s a good book for WebSphere Application Server administrators who are just getting started – and it would also be useful for those learning to administrate products that use it as a base, such as WebSphere Enterprise Service Bus or WebSphere Process Server.

Changing a SOAP Endpoint on an Outgoing Message using JAX-WS

This tip comes from Arancha Ocana Diaz-Ufano, who did all the hard work to figure it out!

In WebSphere ESB, there are many ways of changing the endpoint of a SOAP message outbound from a mediation flow, and the normal way is to use the dynamic endpoint support.  To be clear, this is recommended way.

However, there is another technique, and that’s to use a JAX-WS handler (assuming you’re using a JAX-WS Web Services binding) on the outbound message. This might be useful if, for example, you absolutely cannot modify a mediation flow that’s been given to you, you cannot modify the endpoint at administration time (for example, from the administration console), or you want to do the override in a generic fashion across a large number of mediation flows.

The key is knowing the magic incantation to put in your JAX-WS handler. And here it is:

mySOAPMessageContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://myhost:9080/MyEndPoint");

Thanks again to Arancha for allowing us to publish this tip.

WebSphere Application Server 7 Internals

Sorry that there haven’t been many posts here recently. To whet your appetite, I’m currently preparing a series of articles with a working title of ‘Mediation Flow Creation Guidelines’, which will aim to provide some guidance on well-worn ways to develop mediation flows efficiently.

In the meantime, I’d just like to mention a new book coming out soon called WebSphere Application Server 7 Internals. I’ve been lucky enough to take a look at some preview chapters, and I have to say the content is set to be excellent; Colin has done a great job of explaining many of the more detailed and nitty-gritty topics involved in WebSphere Application Server, which underpins several IBM products, including the one I specialise in, WebSphere ESB. I’m sure it’s set to be a handy tome.

Auto Starting Applications with WebSphere

There is a handy feature of WebSphere Application Server which allows you to control whether applications start automatically when the server is (re)started. By default, all applications (which are Mediation Modules or Modules in WebSphere ESB and Process Server terminology) start automatically when the server starts, but you can turn this off on an application-by-application basis. This is particularly useful to speed up server startup time, or if the applications consume resources as soon as they are started.

You can enable or disable Auto Start using the admin console – simply navigate to Applications / Enterprise Applications / Your application / Target specific application status:

If you have the application installed on multiple servers in a Network Deployment topology, you can select a different Auto Start status for each server.

Thanks to Victoria Amor for the help with this tip.

OutOfMemoryError

From time-to-time, you might see OutOfMemoryErrors in the SystemOut.log file for your WebSphere Application Server-based product (which includes WebSphere ESB and WebSphere Process Server). This normally happens when you’re putting the system under a large load (perhaps you have many applications running or are processing a lot of messages). This technote will help you resolve the problem, by explaining how to increase the maximum heap size used by the Java Virtual Machine running your server.

Interactively Update the JVM Maximum Heap Size

If you’re using a product based on WebSphere Application Server, such as WebSphere Enterprise Service Bus or WebSphere Process Server, you might sometimes find that you run into problems relating to ‘OutOfMemoryErrors’ – these might appear in your SystemErr.log, or perhaps as an FFDC. They are likely to be caused by the Java Virtual Machine (JVM) heap running out of memory, and are more likely to happen if you have a lot of applications installed or you are stressing the server in some other way.

There are two values used by the JVM that runs your Application Server to control its heap size – the initial size and the maximum size. Most likely, you want to increase the maximum size. You’ll probably find that the default is 256MB, but to be sure, run:

startServer.bat server1 -script C:\temp\heapSize.bat

Replace server1 with the name of your server, and c:\temp with the name of any scratch directory. If you’re using a UNIX-based platform, replace .bat with .sh as appropriate. Now look at the generated batch file and search for -Xmx. It might look like -Xmx256m. This indicates your current maximum heap size is 256MB.

To increase this, let’s work with wsadmin interactively.

Run wsadmin.bat or wsadmin.sh:

wsadmin.bat -lang jython

-lang jython means that we want to use jython as the scripting language, rather than the default of JACL. jython is based on Python, which is simpler to learn and use than JACL. If your server is stopped, you should add -conntype none to ensure wsadmin can reach it. You’ll see a bunch of startup messages, then the wsadmin> prompt. Type the following command all on one line:

jvm = AdminConfig.list("JavaVirtualMachine").
split("\r\n")[0]

(use .split(“\n”)[0] on Linux/UNIX)

AdminConfig.list(“JavaVirtualMachine”) returns a list of JVMs, separated by newlines. If you’re using a standalone server, there probably will be only one, so you can omit the rest of the command. However, I’m using a clustered configuration, so I wanted to alter the heap size of only the first JVM in the list, which was a cluster member (I actually carried out these steps for each member of the cluster). Thus, I added the split method and the array subscript, which got me just the first JVM in the list. You can verify the JVM you’re using by typing:

print jvm

You should see something like this:

(cells/YOURCELLNAME/nodes/YOURNODENAME/servers/
YOURSERVERNAME|server.xml#
JavaVirtualMachine_1160406483174)

Next, type:

AdminConfig.modify(jvm, '[[maximumHeapSize 1024]]')

This will set the maximum heap size to 1024MB. Obviously, you can use a different value. As always, you must save your changes to the AdminConfig object:

AdminConfig.save()

You can now exit wsadmin by typing exit. Restart your server and you’re done. This entire procedure could be scripted instead (you can use the -f parameter to wsadmin to pass in a script), and that’s worth doing if you have to apply this change to a lot of servers.

WebSphere Transaction and Messaging and WebSphere Technical Conference

Next week the WebSphere Technical Conference and WebSphere Transaction and Messaging Technical Conference are running in parallel in Salzburg. This is a great opportunity to find out more about the whole range of  IBM SOA related products given by some of the top people in IBM. I will be giving a couple of talks on WebSphere ESB on “Developing custom mediations” and “Connecting WebSphere ESB and WebSphere MQ”. I look forward to seeing you there.

The WebSphere SOA Runtime Stack

In a service oriented architecture approach there are a number of different types of services involved:

Simple services – the web services, or messaging applications exposed as services.

Mediation services – allow you to perform simple message mediation between services.

Business services – allow you to choreograph services.

Each of these services require a runtime with specific capabilities to be able to run.

The WebSphere platform supports these 3 types of service through 3 different runtimes: WebSphere Process Server, WebSphere ESB and WebSphere Application Server. The differences between these are described in the table below:

Runtime	Can host simple services	Can host mediation services	Can host business services
WebSphere Process Server	Yes	Yes	Yes
WebSphere Enterprise Service Bus	Yes	Yes	No
WebSphere Application Server	Yes	No	No

It won’t suprise you to learn that WebSphere Process Server is built on top of WebSphere ESB, and WebSphere ESB is built on top of WebSphere Application Server (I like to think of it like a Russian Doll – open up WebSphere Process Server and you will find WebSphere ESB, open up WebSphere ESB and you will find WebSphere Application Server). Consequently moving from one runtime to another is relatively simple as many of the concepts are the same, e.g. administration, clustering, configuration, install etc, etc. Plus, any of the things you could do at the lower level you can do at the higher level too if you choose to do so (i.e. you can host a simple service on WebSphere Process Server if you choose to do so).

These set of products effectively form the WebSphere SOA Runtime stack.