+

Search Tips   |   Advanced Search


WebSphere Application Server Network Deployment V9 - What's new


Features


Liberty applications for the cloud

We can generate Liberty applications for the cloud through IBM Cloud Developer tools or IBM Cloud UI.

We can create microservices based on Java using different technologies, such as Spring MVC and Spring Boot, REST, WebSockets, Servlet, Java Persistence, and Watson. We can then deploy the resulting project locally or on Bluemix.


Game On!

Game On ! is a microservices adventure application we can use to create and extend a microservices application. In doing so, we can explore basic and advanced microservices concepts. Game On ! now includes support for Logmet, LogStash, and apiDiscovery.


Application portability with Docker containers

Docker containers bundle application binary files, middleware, the JDK, and operating system settings into a single artifact, providing deployment consistency and portability from development to test to production. IBM makes several WebSphere Liberty containers available on the Docker hub, including a Java EE 6 and Java EE 7 web profile and full Java EE 7, each building on a common Liberty kernel layer. We can then build a fully customized Java EE Docker container by starting with just the Liberty kernel and the specific list of features in a server.xml configuration.

We can also use Docker files available on GitHub to build custom images that run WAS with customized license entitlements. WAS Developer Tools V9 adds support so that we can code and test the applications locally or remotely in Docker while we develop in their Eclipse environment. We can choose to deploy these containers to the IBM Container Service, Docker Datacenter, and other container services. This way, we can move applications anywhere, in any way, decreasing development and deployment time and cost.


Management of Java applications and Node.js with the Liberty Collective Controller

In V8.5.5.0, WAS introduced the Liberty Collective Controller. Now, in WAS V9, we can manage more than just WAS Liberty servers. We can specify deploy rules to define specific commands for lifecycle management of Node.js servers and Liberty Docker containers. You activate the rules by inserting or including a deployRule configuration element into the server.xml file of the collective controller. By using this approach, we can deploy a Liberty Collective as shown in the following figure. Intelligent Management is also available in a Liberty ND collective, and as of second quarter 2016, autoscaling and health policies are available for Docker containers and Liberty cluster members.


Optimize costs for application infrastructure

With IBM WAS V9, we can provision applications as needed on different infrastructures.


Intelligent Management in WAS ND for workload optimization and placement

Intelligent Management was introduced in traditional WAS ND in V8.5. With Intelligent Management, we can achieve significant cost savings by employing dynamic clusters or autoscaling to increase and decrease the number of running servers based on workload. Rather than overprovisioning the number of servers in a cluster for the worst case, we can run a smaller minimum number of servers, for example one or two, across the server estate. Similarly, we can employ health policies to provide server resiliency only when needed, such as when an application has an issue or starting a replacement server versus overprovisioning server instances. By using these features, we can significantly reduce hardware and software costs, and because the Intelligent Management is autonomic, we can also reduce administration costs.


VMware portability

If we use VMware, with WAS V9, we can extend our existing workloads as is from our on-premises data center to the cloud, creating a virtual data center that spans data centers. This capability uses an architecture that was jointly designed by IBM and VMware to automatically provision preconfigured VMware vSphere, NSX, and Virtual SAN on the IBM Cloud. In this environment, we can deploy workloads into this hybrid cloud environment without modification because of common security and networking models that are based on VMware.


WAS on Bluemix, single-tenant offering

Some enterprises are heavily regulated and need application isolation from application resources that are controlled by other enterprises. For these enterprises, we can use the single-tenant Bluemix environment offering to deploy WAS on a virtual machine (VM) on private, bare metal hardware. As a result, single tenant then creates an isolated single-tenant environment that can optionally use a dedicated backend database connection to the corporate data center. The dedicated VMs and hardware also deliver more predictable throughput.


Deployment flexibility on additional cloud environments

In addition to the deployments to the IBM Cloud offerings, we can now choose from the following options to deploy WAS Liberty to alternative platform-as-a-service (PaaS) environments:


Ease of use enhancements for caching

The WebSphere eXtreme Scale V8.6.1 licensed program is packaged with WAS V9. It improves ease of use in managing elastic, scalable, in-memory data grids and caching scenarios to handle exponential growth of transactions for high-performance WAS computing environments. New in WebSphere eXtreme Scale 8.6.1 is WebSphere eXtreme Scale Liberty Deployment (XSLD). XSLD is based on Liberty and provides a graphical user interface and a REST API to:

As with WAS V8.5.5, entitlements for use of various WebSphere eXtreme Scale capabilities are based on the WAS edition license in use.


Connect existing applications and data

In IBM WAS V9, we can connect existing applications to cloud-based services. These services provide new access paths to the applications and improve application utilization, using our existing application investment.


Connect to cloud services

By connecting to cloud services, we can integrate new capabilities, reuse existing applications, and lower costs. For example, we can extend our company's reach to its customers on mobile devices by adding a chat function for customers to interact with the call center. Create the chat function using the WebSphere Liberty WebRTC functionality. Then, we can integrate it with the Watson Language Translation service running on Bluemix using the WebSphere Liberty Bluemix Utility. This way, we can discover and import a service configuration, download client libraries, and integrate services bindings into the Liberty server configuration. The result is that call center agents who speak one language can assist customers on mobile devices who speak another language. This scenario is illustrated in the following figure, which shows a WAS integration with Bluemix Watson Services for Cognitive Apps.

In addition to connecting to Watson, we can connect our on-premises applications to other cloud services, such as Cloudant, dashDB, API Connect, and Log Analytics (beta). We can also take advantage of the latest technologies and extend the value of existing Java apps.


Essentials edition of API Connect

WebSphere provides an ideal environment for APIs that are based on Java services and exposed through an API management solution, such as API Connect. The API description is provided by a Swagger document associated with the endpoint and is developed and exposed using capabilities that are built into WAS and the WAS Developer Tools for Eclipse (WDT).

The apiDiscovery-1.0 feature in Liberty makes APIs from all applications discoverable using a single RESTful endpoint, /ibm/api/docs, for APIs described using Swagger 2.0/Open API. It supports JSON and YAML (input and output) files, in addition to annotation scanning for @Path, @Api, and @SwaggerDefinition. When we access APIs, we can use the Essentials edition of API Connect. This edition is included with WAS, along with IBM Support and increased API call limits, providing access for entering the new API economy.


Fixpack numbering scheme for Liberty

Beginning with V9, Liberty and WAS traditional (full profile) will be updated on separate schedules. Liberty has employed continuous delivery over the past two years to add new capabilities and features on a more frequent basis, in response to customer requirements and market demands. However, because the first delivery of V9 for Liberty is the same as the next V8.5.5 fix pack, the numbering scheme for the Liberty fix packs will be based on the year and fixpack number in the format: year.release.modlevel.fixpack.

By including the year in the format, we can see how current the application is. Therefore, the first delivery of V9 for Liberty is the second fix pack of 2016 and is numbered 16.0.0.2. The following figure illustrates the Liberty continuous delivery model.