WebSphere eXtended Transaction Runtime Blogging Space
Next generation solutions are moving away from a monolithic nature. The smarter way to design solutions is to do it in a collaborative environment, where tools are available for better development, deployment and integration.
Transaction processing too has gone the smarter way. WebSphere eXtended Transaction Runtime (WXTR), enables cobol applications to run on WebSphere Application Server, as you may have read in the previous blogs. But in addition to providing a modernization platform to legacy Business Application, WXTR is strongly backed by an array of products that aid the entire development cycle. With IBM Rational Application Developer(RAD) and IBM Rational Developer for Power Systems (RDp), developing both COBOL and Java applications is made simpler with easy integration. The following guidelines demonstrate how exactly RAD and RDp can be integrated with WAS and WXTR.
Integrating RAD and RDp with WXTR : RAD's integration with WAS is quite straightforward. On RAD, a "stub" of a server needs to be added in order to readily deploy Java applications on the server. This can be done by adding a new server File ->New-> Server. Once this is done, a stub is created for a WAS server. There are no further configurations required to setup RAD with WAS. However, in order to develop JCA/SCA applications with WXTR, the appropriate jar files need to be included (SCA - wxtrsca.jar and JCA-CCWConnector.jar). With RAD already installed, RDp can be installed as a plugin on RAD.
This "internet-of-things" enables Application developers to develop WXTR applications as well as the client applications with relative ease. With easy integration, collaborating the different components of the application becomes that much easier. For information on other available tools in the integration space, do attend the "Internet-of-Things" track at the IBM Software Universe, India on the 20th of October.
Today’s business world is changing faster than expected. There is an increasing demand for business to reach out to wider audience and geography to stay competitive. One of the primary requirement for any business application today is to be globalized. We need to understand what it means to be globalized for an application. Do we say it is globalized if we translate the messages in different languages? No, it has something more to it. A globalized software should not only have its messages translated in different languages, it should support multiple cultures and also have a user interface that is appropriate to that region.
When I say multicultural support an application should be able to process data appropriate to the geography. Different geographies use different time format, different currency format and even number format. One should also use the graphics on the user interface appropriate to the local culture.
WebSphere eXtended Transaction Runtime (WXTR) is a new addition to the IBM's portfolio of online transaction processing capabilities. It provides you a platform to write scalable and reliable business applications using composite languages. The most recent version of WXTR v2.1 which was announced June 2012 has support for C and COBOL languages along with Java.
To write a globalized application on WXTR, it is obvious that you have to translate your application messages and documentation but, how do you do multicultural support? There are some libraries available which are specifically meant for this. I have used the ICU (International Components for Unicode ) libraries for my multicultural requirements.
ICU is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software. These libraries provide a comprehensive set of APIs for all your multicultural support requirements. Here is a link to ICU home page:
I'll provide more information about some of these APIs with examples in my next blog. Stay tuned.
namasevi 110000PUWU Tags:  cobol transaction ibm rational systems websphere extended power developer application db2 runtime server 2,879 Views
Here’s a quick view of the dependent products that would be needed along with IBM WebSphere eXtended Transaction Runtime (WXTR) in a solution. As a starter, following are the products that you would need as pre-requisites before you begin using WebSphere eXtended Transaction Runtime. A quick list of them and a note on why they are pre-requisites out here,
1. IBM WebSphere Application Server (WAS)
WXTR is a stack product on WAS. WXTR supports WAS version 7 and version 8. If you were to use WAS version 7, then you would also need to install WAS feature pack for SCA. If you are using WAS v8, the feature for supporting SCA is integrated within v8 itself.
With WXTR, COBOL applications are run natively on WAS. If you were to host your existing COBOL applications, the only way they can be interfaced with are either through the JCA layer using either a Servlet or EJB deployed on WAS or through the SCA wrapper using the callCOBOL method provided by WXTR. You can write Servlets or EJBs and use the JCA interface provided by WXTR to invoke COBOL applications through them. Or you can expose COBOL applications as a service using the SCA wrapper as well.
WXTR also supports administration of it’s resources through WAS admin console. Some of WXTR runtime resources like the number of application server processes and also memory pool settings etc can be controlled or configured from WAS admin console. WXTR’s life cycle of start and stop have been integrated with WAS as well. When WAS starts, WXTR runtime gets started as well.
2. IBM COBOL compiler version 4.1
IBM COBOL v4.1 is the COBOL compiler we support on AIX. IBM COBOL compiler would be required to compile your COBOL applications and also WXTR runtime uses IBM COBOL compiler runtime libraries to be able to host and run COBOL applications. So, to be able to natively run COBOL on WAS, IBM COBOL is a key component that must be installed. IBM COBOL v4.1 also supports off-line file access feature, which allows users access to VSAM files (of either KSDS, ESDS or RRDS format) stored in DB2 database.
3. IBM DB2 Version 9.7
IBM DB2 is supported as the resource manager. DB2 also allows you to store your existing VSAM files. Storing VSAM files on DB2 allows you to laverage all the powerful features of a modern relational database. WXTR runtime tightly integrates with DB2 database to allow data management as well as store some of the internal files for processing.
In addition to the above, you can use the following IBM Rational products as integrated development environments.
4. IBM Rational Application Developer version 8 (RAD)
RAD’s integration with WebSphere Application Server is well known. Java programs being written using RAD can make use of snippets supplied with RDp (or import the ones shipped with WXTR as well) for writing JCA code to invoke COBOL programs running on WXTR. You can just open WXTR Snippets drawer and drag and drop Java code to invoke COBOL applications.
You can also use Java to COBOL mapping feature in RAD to generate Java code to map to your COBOL copy book. This helps to handle your data across Java and COBOL layer easily by generating corresponding Java classes and getter setter methods to manipulate data.
5. IBM Rational Developer for Power Systems version 8 (RDp)
RDp is the development environment for COBOL applications on AIX. You need to install RDp’s Remote System Explorer component on the AIX machine to be able to interface with the AIX machine where WXTR is installed. If you already have a RAD installed, RDp just installs as an additional plug in on top of that. RDp v8 has all the features like content assist, program templates for CICS COBOL etc, which can be made use of for re-deploying your existing COBOL applications or even writing new COBOL applications in support of your existing business logic. In addition, with RDp and WXTR you can use snippets and code templates for writing COBOL applications. Using RDp, you can easily deploy your COBOL applications on the fly on WXTR.
RAD and RDp would add further value in your application development with the new seamless debugging feature. You can setup break points in Java code and in COBOL code and move back and forth across them. For example, you can enter data in a web page, and make the Java program stop at a point where you are executing logic in Java code and about to invoke COBOL. Then you can set break points in COBOL at entry and exit points. These products make it very easy to identify and isolate problems in an end to end solution. You don’t need to install anything in addition for being able to debug across mixed languages.
All above products make a typical combination set in a WXTR deployment. This link has further details on required software, http://www-01.ibm.com/support/docview.wss?uid=swg21501498&wv=1
CoolShubhendu 270004J5SA Tags:  wxtr exutended websphere administration system runtime 3,133 Views
System Administration in WXTR can be done through Websphere Application Server administration console where in specific panels are provided to configure WXTR resources.
Steps for doing it Administering WXTR through WAS Admin console will be:
It can also be done using the wsadmin.sh command line utility.WXTR provides wsadmin jython commands which can be used to configure WXTR resources.Hence it can be automated as well.And we would be concentraing more on the commandline utility in this blog.
I will be showing here how to automate System Administration in WXTR using a simple python program.
Sample automation of WXTR configuration using a python program is given below:
command1="/opt/IBM/WebSphere/AppServer1/bin/wsadmin.sh -lang jython -c \"AdminTask.cics('[-command get -c xad -colonSeperatedOutput yes -name SYS$XA -nodeName " + machinename + "Node01 -serverName server1]')\" "
This program gets the properties of the XAD stanza of the container.This is has been extracted out from a test suite which has other such entries.It also shows how can this be made part of a big suite.Here we increase the count of "passed" variable on every pass and if we know the total number of cases then we can deduct the passes from the total to get the failure.
Well, by now most of us are familiar with the word "Patterns" arising out of the PureApplication System. It offers a nice concept to encapsulate all actions (often we call that as a best practices) in to a single deployable unit (technically a compressed tar file) to represent a workload. The PureApplication system defines the framework and provides the necessary platform services for creating these patterns. The benefits of creating such patterns is immense as it provides simplicity and the ability to do repeatable deployments of your applications with just few clicks away. Gone are the days where you have to take a bottom up approach for configuring OS, middleware products, applications, etc,. to run your applications. Its just a matter of minutes for deploying your same applications with the PureApplication Systems's pattern approach.
In terms of patterns it can be classified in to System pattern and a Application pattern. There's always a question to see what's the difference between these two, and which one to be chosen for the application deployment. A virtual system pattern (vsp) is often used in situations where you need to describe a system topology that you want to deploy, especially when it incurs deployment of your products on to multiple instances/systems. This is more of a traditional method of deployment, however once done can be captured (or recorded) as a system pattern and further deployments gets easier with redeploying the pattern itself, rather than creating the topology again. To build the virtual system patterns there are virtual images available for the product that you want to include in the topology along with add-ons and script packages that help you to configure products.
A virtual application on the other hand does not come with the customization control that you had with defining a virtual system pattern - i.e. we do not have to define a topology and other descriptive elements in the virtual application pattern. In the virtual application pattern, it is mainly focused keeping applications (and its associated factors such as SLA) in mind, and the toplogy to run that application workload is determined by the system dynamically. This frees up the application deployer in terms of defining a topology or required system components - and instead focuses only on their application deployment and specifying its SLA and other business application specific requirements. Behind the scenes the plugins and the PureApplication system provides an execution platform appropriately for the deployed applications.
As an analogy for comparing vsys vs. vapp, if you are a vivid reader of EFY (Electronics for You) magazine, it describes solutions say for example if we want to create a water level controller. A vsys way of looking at it is to create a PCB board and define the various electronic components and how they interact with each other - all done from a ground up level, you can customize the board to have the functions that you require in the water level controller... for a vapp you simply go to an electronic shop and request for a ready-to-go device that helps you with the water level controller, albeit with limited control and functionality as provided by that specific device.
21st century COBOL
It is probably quite safe to say that the backbone of 21st century service infrastructures, is still COBOL-based applications. Innumerable industries, during the late 20th century, were built around Mainframes and COBOL applications. These applications formed the foundations, on which more features and capabilities were added in the years to come. As we moved into a Service-oriented Architecture(SOA) space, the need for the applications to become smarter and interconnected rose. Applications needed to be viewed as web services, java beans etc. made available over different transport protocols like JMS, XMS, HTTP to name a few. This opened up opportunities to apply cross technology knowledge into one single box.
WebSphere Application Server(WAS) gets WebSphere eXtended Transaction Runtime(WXTR)
As an application server, WAS is one of the most competent products in the market. WAS provides application deployment, monitoring, Integrated application development for Java and J2EE applications. The idea of opening up such services to legacy COBOL applications, on a Java environment is an idea that sounds exciting and impossible at the same time. However, this is exactly what is now possible through WXTR.
Possible modernization using WXTR
WXTR not only provides WAS capabilities to COBOL applications, but also opens up SOA capabilities as well. WXTR provides an SCA (Service Component Architecture) interface that enables other SCA clients (WebServices and SCA) to access COBOL applications.
An interface such as the SCA on WXTR, added to WAS capabilities means, WXTR is capable of fititng into the SOA Architecture. Each COBOL Application deployed on WXTR can be accessed as a service by any client that is part of such an SOA.
Below is an example of calling a service using WXTR's SCA methods :
API : CallCOBOL() - This API enables the Client application to call a particular COBOL program deployed on WAS.
CallCOBOLService service = new CallCOBOLService(); // A web service client calling a WXTR resource
CallCOBOL cc = service.getCallCOBOLPort();
cc.callCOBOL(ProgramName); // This line calls the COBOL program
Summing up, WXTR is something to watch out for in the future. With increasing WAS capabilities, the extent to which Enterprise Applications can be modernized to fit into the modern Application ecospace will only increase.
namasevi 110000PUWU Tags:  cobol cics extended transaction ibm was runtime websphere wxtr txseries 4,301 Views
Many of you might have heard about one of IBM’s latest addition to it’s product portfolio, WebSphere eXtended Transaction Runtime (WXTR). WXTR is a new addition in the transaction processing space as a complement to WebSphere Application Server (WAS) on distributed platforms. WXTR v1.0 is available on AIX platform only.
WXTR addresses a key space wherein enterprises are looking to modernize their existing COBOL workloads. WXTR tightly integrates Java EE applications and COBOL applications thus allowing users to re-use existing COBOL business logic while extending them with new and modern Java EE applications. Due to it's association with WAS, WXTR provides a forward looking and a modern environment for existing COBOL applications.
For a quick look, some of the key WXTR features are,
WXTR in conjunction with WebSphere Application Server and Rational tools is a solution that best fits organizations that are looking to write new code in Java EE while retaining their existing core business logic in COBOL. WXTR brings in the best of interoperability and integration. Unified administration provides a single environment to manage both COBOL and Java resources. RAD (Rational Application Developer) and RDp (Rational Developer for Power Systems) integration provides a more complete development environment together for Java EE and COBOL programs. WXTR supports CICS style programming. Users can use many of the built in features in RDp for application development e.g. command assist, syntax checking, templates etc. Seamless debugging across Java and COBOL is a reality with the use of RAD and RDp.
In summary, WebSphere eXtended Transaction Runtime brings in further simplicity , ease of use , modern facilities and much more.Thus reducing the overheads in managing COBOL and Java workloads.
Couple of references for WXTR as below,
namasevi 110000PUWU Tags:  runtime transaction processing ibm websphere india extended v2.1 3,354 Views
WebSphere eXtended Transaction Runtime (WXTR) version 2.1 was released last month, on 15th June. Version 2.1 brings a number of enhancements to the first version 1.0 that was released an year ago. Primary themes of version 2.1 are targeted at enhancing the overall value proposition of hosting COBOL applications in WebSphere Application Server (WAS) along side Java EE applications to unlock the value of existing COBOL applications with new ones written in Java EE.
The picture below depicts the three major themes very well,
On the first note, WXTR extends from being a COBOL container on WAS to support C application deployment as well. With this, traditional transactional applications written in C or COBOL can be hosted by WXTR in line with Java EE applications on WAS. WXTR now supports Oracle database as a resource manager in addition to DB2.
With version 2.1, WXTR delivers a greater value through superior integration, higher scalability and security features.
WXTR v1.0 added a feature pack recently on Modernizing Oracle Tuxedo Applications. Version 2.1 extends the value by supporting C applications as well.
For more information about WXTR v2.1 highlights refer to the links below,Website : http://www-01.ibm.com/software/webservers/appserv/extended-transaction-runtime/
WebSphere eXtended Transaction Runtime (WXTR) is a new transaction processing software introduced by IBM this year and was made generally available June 2011. WXTR delivers a technology that helps customers to reuse existing COBOL business applications by executing them natively within WebSphere Application Server. You may refer to this link for more information on this software: http://www-01.ibm.com/software/webservers/appserv/extended-transaction-runtime/features.html
In this blog I would particularly like to highlight a feature provided by WXTR and COBOL for AIX together to help manage the data stored in VSAM formats using DB2.
Most of the legacy COBOL applications particularly written for a CICS environment use VSAM files for storing business data. On a distributed platform say Unix'es and Windows there are software available to host these VSAM data such as TXSeries provided Structured File Server (SFS) where you can create and manage KSDS, ESDS, and RRDS based VSAM datasets. However think of... if we can manage these data in a relational database and leverage the power the database technologies provide us. This is similar to a tool available on system z platforms called CICS VSAM Transparency. And this is where WXTR and COBOL For AIX provides you the feature to transparently manage the VSAM data using DB2.
What this means is that WXTR allows you to store the VSAM data on a relational database (RDBMS) such as DB2 while retaining your COBOL and/or CICS/COBOL applications as-is. With this your applications or business logic built for the underlying data wouldn't change - we don't want you to change the data model that is built already and is proven.
Not the least, there are other benefits that this feature would provide: