The Curious Case of Web Services Migration - Part I

Vladimir Serebryany, Senior Consultant

During one of my recent BEA WebLogic to IBM WebSphere migration assignments at a major insurance company, I encountered an interesting problem.

The client had a large number of Web services which were running on BEA WebLogic and consumed by a .NET front-end. In the course of migration, our team had to not only migrate code to WebSphere but also help the customer refactor the source code repository and create a set of Maven scripts to provide a fully scripted build/deploy process for all environments - from unit test to production.

We started with the typical set of issues:

• WSDL files and corresponding XSD files had relative namespaces in them - and the spec strongly recommends absolute ones
• Source code was stored in typical WebLogic structures and deployable components were created by running four (!) different Ant scripts
• Code and WSDL files were stored in PVCS and the revision history had to be preserved
• WSDL2Java wizard was invoked every time scripts ran so binding Java code would be generated on the fly and not stored in PVCS - wise decision but binding implementation classes with client's code in them had to be preserved from being overwritten.

The first issue was easy to deal with – a couple sed/awk scripts took care of the namespaces. We gave WSDL files back to client; they validated them against their .NET environment and found no problems with new namespaces.

Item #2 was also relatively easy to solve - we manually rearranged code into a Rational Application Developer (RAD) structure and that was it. RAD is really good at that sort of thing. While doing that we also extracted PVCS archives as files from the central repository and rearranged these archives in the file system according to the new directory structure. We sent back these directories to the client’s PVCS team, and they imported these archives back into a new PVCS project. That way all the previous generations of source code have been preserved. We now were able to work with PVCS and track a file’s revision history right back to Noah's Ark.

Now we had to deal with WSDL to Java files generation. There were three sorts of files: custom code with business logic, binding code and classes generated from data types definitions in XSD files, and binding implementation classes. We did not have to worry about the first two types: the first set was permanent code which we shifted to another utility’s Java project for simplicity of maintenance. Generated Java was what it was - generated code which the wizard took care of, only the binding implementation classes was something we had to take care of. On one hand all the methods stubs are generated by the WSDL2Java wizard - on the other hand these methods already contained the customer's code. If we allowed the wizard to run "freely," this code would be overwritten.

Here we needed a trick and we found one. As it is well-known, RAD may designate one or more folders in the project to be the Source folders - meaning it will compile all Java code in these and only these folders into binary form. It happens that built-in RAD wizards are very sensitive to the order in which Source folders are listed in "Order and Export" tab of "Java Build Path" configuration page. If the WSDL2Java wizard for bottom-down Web services generation is invoked either from the pop-up menu or from the wsgen.xml script, it always places all generated files into the folder listed first in "Order and Export" tab. That "observation" provided us with opportunity to solve the problem. We would define two Source folders: “src/main/java” and “src/main/java2.” “src/main/java” would be listed first in "Order and Export" tab, “src/main/java2” would be the second. The single "target/bin" folder was designed for binary files. We placed all existing binding implementation files into “src/main/java2” folder, and we put WSDL and XSD files into a separate project. (Note that by using “src/main/java” folder structure we were shooting to use Maven.)

From that point on, if a WSDL definition changed, we would clean “src/main/java” folder and run the Web services wizard/script against new WSDL/XSD files. Newly generated binding files would go into “src/main/java” folder. As long as binding implementation files were also on the classpath, WSDL2Java wizard was smart enough to not regenerate *BindingImpl.java files, but rather pick them up from “src/main/java2” folder. IBM provided ws_gen Ant task, script and sample properties files were customized to run the whole task at any time for all 20 WSDL's we had in the service definition (see http://publib.boulder.ibm.com/infocenter/radhelp/v7r0m0/topic/com.ibm.etools.webservice.was.creation.core.doc/ref/rtdwsajava.html). We didn't include “src/main/java” folder into PVCS and never had to check-in transient generated code.

The remaining issue to solve was to reproduce in RAD the style in which WebLogic's WSDL2Java script generated the code. By tweaking WSDL2Java options on Window->Preferences->Web services->Websphere->JAX-RPC Code Generation->WSDL2Java tab in RAD, we matched the style of generated code so that RAD-generated code was almost drop-in replacement for WebLogic-generated code. The problem was solved - but only for development phase so far.

Coming in Part II: “My initial feelings were anger and frustration as Maven-enabled RAD essentially diminished RAD to be just a fancy code editor - and nothing more. Gone were round-trip interactive development, and my productivity as a developer really suffered. Only by the end of the project I found out how to keep RAD effective and fully engaged and still be able to build using Maven…”

Vladimir Serebryany is a Senior Consultant at Prolifics with in-depth knowledge and broad hands-on experience with the J2EE environment as well as expertise in EJBs, Servlets, JSP and JSF. Excelling at migrations, Vladimir has over 9 years of experience with a wide range of complementary skills including WebSphere, WebSphere MQ, WebSphere Business Integration Message Broker, UNIX, C/C++, Java, HTML/ASP, JavaScript, and Visual Basic. He has served as team leader/senior developer roles in large, complex projects and configurations with clients in the financial, insurance and telecommunication industries - among others.

Database Design and the Demands of Operational Business Intelligence

Anant Gupta, SOA Practice Director

When hearing the term Business Intelligence the first thought that springs to mind is that of reporting and trend analysis based on historical data. So what exactly is Operational Business Intelligence (BI)? It almost seems to be an oxymoron. In one sentence, it is the mechanism of enabling everyone, and not just the strategy team as in the case of BI, to make decisions that improve the top-line, bottom-line or enhance customer satisfaction. These decisions are not made quarterly or yearly but on a transactional basis. A very simple example of operational intelligence is your GPS system telling you to take a different route to work because of a bad traffic condition on your regular route. To make this more interesting, let’s assume that your system not only understands the traffic conditions, but also gas prices, your schedule, tolls, etc., and needs to present you the most effective option based on all of these factors. To do this, it needs to perform a lot of analysis in real-time. Similarly, systems need to look at the product / promotion info and customer purchase history / status and determine cross-sell, up-sell opportunities.

So far we have been talking about transactional databases or data warehouses / data marts, one for OLTP and the other designed strictly for post-facto reporting and analysis. The new trend will be a middle path where we will be designing data marts that will have the capability to be queried and performing analysis in real time. There will also be a trend that will emerge to update the operational data stores with updates from the data warehouse. Essentially, data warehouses will be able to continuously analyze data, recognize and send events that operations will subscribe to. For example, I might be interested in subscribing to an event if merchandise returns for one of my product lines exceed 5% of normal returns. So, databases will need to start understanding events and perform continuous analysis to determine the occurrence of any of those events.

All of this imposes challenges to the database design as both the depth of analysis and performance will have to be delivered simultaneously.

Anant Gupta was recently named the SOA Practice Director at Prolifics after serving as a Senior Business Integration and J2EE architect Anant has with extensive experience in IBM's SOA software portfolio and specializes in delivering business integration and business process management solutions. He has worked for major clients in the banking, insurance, telecommunications and technology industries.

Web Application Security Considerations

Andy Blank, Security Practice Solution Director

Should you consider doing anything about Web Application Security? Here’s a quick self assessment test for all the many application developers and infrastructure specialists out there. Answer the following questions as honestly as possible.

While building customer web applications (Portals, UI front ends to business processes, SOAInfrastructure, message flows, Web services, etc.), I think of security:

• First, foremost in priority, and continuously throughout!
• As one step in my development process.
• As a separate set of tools (identity management, access management, etc.) handled by a security team.
• Security? Isn’t that the job of the imposing looking person in the elevator lobby?
  

I would guess that the applications I develop/deploy have significant security holes:

• Never! I am a gift to modern development perfection!
• Half the time.
• Three quarters of the time.
• I really have no way of knowing.
  

Unless you honestly answered ‘a’ to both questions, you should take a hard look hard look at Web Application Security -- including coding practices, vulnerability testing, managing system access, and system configurations. 75% of all current internet based attacks are made against the application layer. In addition, security companies such as Symantec surmise that up to 80% of existing web applications have at least one significant exploitable vulnerability.

Since joining Prolifics in 1994, Andrew Blank has held key positions such as Senior Technical Support Engineer, Manager of Training Services, Senior Consultant, and Migrations Practice Manager. Currently, as one of Prolifics’ Solution Directors and as leader of the Security Practice, Andrew takes part in the design, development and delivery of Prolifics’ projects for such clients as Marsh & McLennan, MetLife and UPS. His expertise in J2EE architectures, portal solutions, IT security, and systems monitoring is integral to the company’s strategic planning for adoption and use of new product technologies.

Messaging: JMS vs SCA

Ivan Smirnov, Senior Consultant

In SCA, bindings are the means of transporting data (messages) to and from modules. One specific application I’d like to discuss is messages between SCA modules: that is, when one SCA module calls another SCA module. There are several types of bindings that can be used in that scenario. The easiest is, I kid you not, the SCA binding. At runtime, it becomes an EJB call. SCA binding was designed specifically for inter-module calls and it is so good at this, it makes you wonder: why use any other binding type at all? Well, if you need more flexibility, JMS binding may be handy.

SCA binding is best suited for simple synchronous calls between modules. It is possible to use SCA binding for an asynchronous invocation, but it will be implemented on auto-generated JMS queues on a SCA SYSTEM bus. With little control over queues, this option does not provide all the benefits of JMS binding.

Advantages of SCA bindings over JMS bindings:

• They do not require any external configuration and thus are maintenance-free.
• Interfaces are early bound. Interface types are checked when binding is established, and the Export interface must match the Import interface. This eliminates a possibility of errors not discovered until runtime.

Advantages of JMS bindings compared to SCA:

• More flexibility: target module can be relocated (even to a different cell).
• You don’t have to use the same interface on both sides of binding. Even method names may be different on caller (module Import) and target (module Export), so long as payload type is correct.
• There is an easily accessible checkpoint between modules(a JMS destination) where messages may be inspected for troubleshooting/debugging purposes.
  

In addition to this theoretical analysis, let me share my experience. I experimented with inserting JMS binding between modules where SCA was a natural fit, just for error handling purposes. My idea was that it would be much easier to control message flow and retry logic if there was a JMS queue between modules that I could configure to my liking. As intriguing as it sounds, there was too little real benefit in that specific ESB solution. So my conclusion was that error handling is not sufficient justification for using JMS binding where SCA binding is a more natural fit.


Ivan Smirnov is a Senior Consultant at Prolifics with extensive hands-on experience with the WebSphere family of products (including WebSphere Application Server and Process Server, WebSphere Studio/Rational and WebSphere MQ), Tivoli security offerings (including Tivoli Identity Manager and Tivoli Access Manager for e-business), DB2, XML and Web Services. With strong technical skills both in development and administration, as well as deep troubleshooting skills, Ivan handles aspects of implementation installation, configuration, securing and tuning/troubleshooting to development and architecture within a J2EE environment. He also possesses key Application Server migration skills and has helped several customers’ transition to the WebSphere platform from other J2EE platforms.