Liberty and Web Services for IBM i
The IBM i operating system has been shipping a web services runtime engine for a while now. We first delivered the Integrated Web Services (IWS) support in late 2009. This web service runtime engine was built on the Integrated Web Application Server (IAS) and the AXIS2 web services container. At that point in time, they were both pretty new and exciting technologies. Well, in the world of web technologies, things change. Often those changes happen quickly. The IWS support is no different, while the technologies that we are using today (IAS built with LWI and AIXS2) are still working and doing a fine job, the technologies in this area has changed dramatically since we delivered the support and its time to make a change. We need to keep heading in the same direction as the industry with this key IBM i support.
Over the past year we have been in the process of updating the IAS server from an LWI base to a Liberty base. Why did we decide to make this change? The existing LWI server, while advanced a few years ago, is no longer as current and is not positioned for the future nearly as well as the Liberty server is. The existing LWI server is currently in maintenance mode and has not undergone any new advancements for a few years now. Because of this it was time to find a new Web container we could ensure that serve the IBM i community well for the coming years. We chose to leverage the WebSphere liberty container as our new integrated application server. This process has gone remarkably smooth and we have thousands of customers using the new Liberty based server already. Now that we have the WebSphere Liberty Core server as the basis of our IAS server that is built into SS1 (ie core operating system code) its time to leverage this new web severing runtime container for our Web services support. In addition to the update to the actual Web server container, we have also updated the Web services engine. We are moving from the AXIS2 engine to the JAX-WS engine.
What does this change mean to you? Really not too much that you will actually notice. The biggest difference is the long term support. With the Liberty and Jax-WS stack we have a well-supported environment. Well supported, what exactly does that mean. With the existing technology stack the web container was created several years ago now and was originally built on a Java 5 base. While it has been updated to leverage Java 6, it has not been transformed to truly leverage some of the key advancements in these newer version of Java. Also, the LWI server will never be updated to run on Java 7 or Java 8. Additionally, there is the entire realm of security. We continue to update the LWI based server for any security vulnerabilities, but this process is going to continue to be increasingly difficult into the future as there is no active development or advancements being made to the LWI based server. This is unlike the Liberty based server that was created run on a Java 6 or Java 7 server and is actively being updated and developed.
When it comes to the industry tools for doing security evaluations, none of these tools actually recognize the LWI based server, so most often it is flagged as non-compliant and you need to do a manual verification. With the Liberty based server, its actually a WebSphere container, to these industry tools will handle this server in a more consistent and friendly manner. This alone for many customers is reason enough to consider this newly updated web services runtime!
The best part of this change to this new technology base is it basically works exactly the same as what you have been using all along. The differences between the two solutions are minimal for sure. The process that you have been using today for creating deploying and managing your web services server will remain unchanged. The only changes that you should notice are a couple of minor differences in how the actual web service is created and leveraged by your caller. Here are a few differences that we have noticed:
- •The WSDL documents are slightly different between the two implementations – the difference is that in liberty but namespace for the schema in WSDL is the same as the WSDL target namespace. This is different than what was previously done, with a schema namespace is the WSDL target namespace appended with “/xsd”.•Only one SOAP version can be specified – in liberty you can indicate whether you want SOAP 1.1 or SOAP 1.2, but not both. Previously both SOA P version could be specified in a single service.•The URL and point is slightly different•The long-term security compliance support is greatly improved•Since we are now leveraging the liberty web container you should also see a slight performance improvement.
When is comes to creating a Web Services environment its still just as simple as ever. The Web Admin GUI interface comes with a set of wizards that allow you to easily create a server and then create Web Services over the top of your ILE based RPG or COBOL programs. Any ILE base RPG or COBOL program or service program that you have (assuming that its stateless) can be transformed into a Web Service. This means that any key piece of business logic can be exposed via a web services call without you having to learn anything about the Web, SOAP, HTML, Java or any other related technologies.
To get started with Web Services, open your favorite browser. Access the Web Admin GUI. The URL for this is http://hostname:2001/HTTPAdmin . The Web admin GUI is part of the Admin servers that are normally running on every machine. Once you have signed into the GUI, click on the ‘Create Web Services Server’ link to create the server environment for running and hosting your own web services. The wizard is very easy, the only value you are asked to enter is a User ID that you want to have used as the user ID for the server runtime. Actually you we even make this step easy as we ship a default USER ID so really all you need to do is click Next a couple of times and then Finish. In a matter of a few seconds your Web Services runtime environment is up and running. Now its time to create your first Web Service.
Click on the Manage Web Services link. You should see one service already deployed and running. We ship and deploy the ConvetTemp service on every server we create. This is a very simple RPG program that just converts Celsius to Fahrenheit. This Web Service is intended to help as a testing tool. You can easily call it using the Web Services Testing tool to see if the Web Services ecosystem is working properly. This can be especially important when you run into an issue and you are not sure if it’s a problem with the back end program or the Web services side of the world. To deploy your own web service, click on the Deploy button to launch the deploy wizard. This wizard will walk you through the process of creating and deploying the web services wrapper over your back end ILE program. There are about 8 steps you need to click through. The reality is though, only need care about two or three of the steps throughout this wizard. The first important step is where you specify the RPG or Cobol program that you like to have converted into a web service. Once you specify this program will then be prompted to specify the name of the web service as well as a list of parameters i.e. the input output values for this particular operation. It’s important that you specify whether each parameter is for input or output as well as to tie the structure values to their designated programmatic sizes. This ensures that the values when passed back-and-forth between the web and your backend RPG are done in a proper and correct manner. The other screen but maybe of interest is the library list field. Since you’re calling a backend ILE RPG or COBOL program, it’s important to have the library list specified properly. Specifying a library list can have a great advantages allowing you to easily switch between test and production data. You can set a test library for your data now and easily change that library list value to the production values at a later point in time. There are number of other advanced parameters that can be set while creating your web service but the reality is, for starters there probably not that important.
All the existing LWI Based Web services support is still there and will continue to be supported for now, there will come a day will when it’ll be time to transition to the new liberty-based server in order to keep up-to-date on the latest updates and security refreshes. The good news is the liberty based web services engine has been moved back to IBM I 6.1 and IBM I 7.1 to give you plenty of time to make this transition before you moved to IBM i 7.2. In IBM i 7.2 the only web services server that will be supported is the new liberty-based server.