Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

The Decision Process: Moving to WebLogic Platform 7.0

The Decision Process: Moving to WebLogic Platform 7.0

BI, a company that specializes in business improvement programs for a wide range of companies, leverages J2EE for many of its software solutions. In fact, we've had several J2EE-based applications in production for years. Our flagship online media redemption vehicle is one such application, and is one of our largest. The application is an online catalog, which participants can use to redeem media for products. This application was the catalyst for our move to WebLogic 7.0.

In this article, I'll discuss the following:

  • Why we decided to change application servers
  • How we came up with the contenders
  • How and why we ultimately chose BEA's WebLogic Server 7.0
  • Porting the application
The Decision to Move
Before this process began, our application was running happily on a competing application server, which will remain nameless to protect the innocent. There were multiple JVMs running on one physical Solaris box. Not a small application, it interacts with three separate databases (distributed transactions galore!), our internal Order Management (OM) system, and an LDAP security realm. Furthermore, there are upwards of 50 EJBs and hundreds of supporting classes. The database schema is rather large, and yes, we do have a shopping cart!

So why did we decide to move off of our previous application server? After a long period of relatively successful application uptime, we ran into a new situation. Lots of traffic! While we were happily humming along in our environment, our capable sales staff sold our product to a large account, almost instantly creating a much larger demand for our application. Our single-server environment was not initially designed for quick and easy scalability, and it was in danger of being overwhelmed.

We quickly began to do extensive formal load testing of our environment and applications. We made some great strides in enhancing scalability and performance-tuning the code base, but nonetheless a server offering superior clustering would be needed to handle the increased traffic.

The decision to change application servers was also a matter of developer mindshare. The primary developers were not happy with the current application server. Ease of development, application server bugs/quirks, outdated specification support, and manual processes (who requires you to do pregeneration of EJB stubs and skeletons anymore?), and more, all led to this decision. Productivity, from the developer's point of view, was not very agreeable. This, combined with business buy-in on the need for a truly enterprise-level environment led to the business decision to move to a new application server and clustered architecture.

Choosing the Contenders
The first order of business was to select the candidate vendors. Considering the size of our team, we decided we needed to narrow down the choices as much as possible. A list of some of the features we most required in a new platform included:

  1. Scalability: Need to cluster and be easy to maintain
  2. Fault tolerance: Clustered scenario must eliminate downtime
  3. Standards support: How well does the platform conform to latest specifications?
  4. Direct technical support
  5. Developer efficiency: How easy is it to develop on?
We looked at OC4J briefly, since we're running on an Oracle back end. We also considered JBoss, a popular open-source EJB container. It contains many nice features, but we couldn't quantify how many large companies were actually using it in production. Also, the lack of direct support was a factor in not pursuing an open-source solution. In the end, we decided to look at the two big dogs on the block: IBM's WebSphere 4.0 and BEA's WebLogic Server 7.0.

Defining the Process
A committee of lead developers and system administrators headed up the evaluation process for the contenders. It consisted of the following basic elements:

  • A matrix of features, server requirements, and nice-to-haves
  • A sales pitch made by each vendor
  • References from other companies using the products
  • A "bake-off" between the contenders
The feature matrix was critical in the decision process. It contained elements such as desired J2EE specification, clustering/load-balancing capabilities, JDK support, technical support, and so on. We rated both products based on this matrix. Table 1 provides a small example of such a matrix. Some items, such as whether the vendor supports the EJB 2.0 specification or not, are simple yes/no evaluations. Others, like the effectiveness of a vendor's online support, are more subjective and were rated on a 10-point scale.

WebLogic 7.0 fully implements the J2EE 1.3 specification while WebSphere 4.0 was still on version 1.2. We had a strong desire for an EJB 2.0 implementation, giving us such goodies as container-managed relationships, EJBQL, JMS, and message-driven beans. Also, the Servlet 2.3 specification opened the door for us to use such valuable Web-based options as filters. We saw these as extremely valuable items on the list, and the version of WebSphere available to us just didn't provide them. The IBM representatives were quick to point out that all of these features were going to be available in their next release (version 5.0), which was slated for a couple of months after this process was taking place. Ultimately, we decided we couldn't wait for the introduction of a new version. BEA's WebLogic was an existing, stable product that was current with today's J2EE standards. BEA won this round. Note: at the time of this writing, WebSphere 5.0 was still not GA!

We also invited both BEA and IBM to send over a technical sales team to perform their canned presentations on the benefits/capabilities of their respective products. While this step was certainly informative, I'm always a little skeptical of sales pitches. Salesmen will sell you the world even when they can't deliver it. Overall, the presentations were simply a showcase for each vendor's bells and whistles. BEA stuck mainly to the application server side of things, which was fine. They brought in a small mix of sales staff and technical engineers that answered our technical questions. IBM, however, sent an entire team of people to provide the presentation. That was impressive. IBM also placed a heavier emphasis on their integrated IDE. I've been using Eclipse as my IDE for some time now, and I really like it. I have to hand it to IBM, the integration with their IDE (a souped-up version of Eclipse) and the application server was great. The presentation, along with the team sent with it, made IBM the winner of this round.

Next, we conducted reference checks with other companies that were using the product. While this sounds like a great idea at face value, the kicker is that the vendor-provided list of references is just that - "vendor provided"! Obviously, neither company is going to provide us with a client reference unless they had rosy things to say about the product. In order to at least partially negate this, we decided to conduct the interviews on a one-on-one basis without a vendor representative present. Needless to say, both vendors were portrayed in a favorable light, but it seemed BEA was even more so. BEA came out on top in this round.

Finally, we conducted a small "bake-off." The purpose of this was to display the setup, ease of development, and use of the application server and its deployment tools. Each vendor sent in a team to port as much of our application as possible in three days to their platform. Since our internal developers were helping each team, we received some hands-on experience working with each server. We didn't expect to have a fully ported application at the end of three days, but we wanted to see actual application server installations and development processes on a real application, and not some "sample" application that comes prepackaged, ready to deploy. BEA sent in a small team and was able to get a small amount of the application ported. IBM, on the other hand, sent in a larger team that had a lot of experience with porting applications. They were able to achieve much more in the same amount of time. While the outcome of the bake-off was largely due to the number and type of personnel that comprised each team, we had to award this round to IBM.

Making the Decision
If making this decision were as simple as checking off requirements on a checklist, selecting an application server would be a science. Believe me, it's not a science by any stretch of the imagination! There were several factors, many of which were intangible, that led us to choose BEA WebLogic 7.0 over IBM WebSphere 4.0.

Several members of our development group placed heavy emphasis on the J2EE 1.3 specification, which hurt the IBM camp's chances because WebSphere 4.0 simply did not have J2EE 1.3 support. There was no guarantee when the next version of WebSphere would be released, and many of the development staff were wary of using a newly released product until several service packs were out. WebLogic has supported this specification for some time now.

Another factor in our decision was vendor market share and developer mindshare. At times it felt as though we were the only ones using our previous application server. It made finding solutions to common problems and bugs difficult. Active discussion groups can save a lot of time during development. While both IBM and BEA currently have comparable market share, we found that BEA had a larger market of applications that leveraged EJBs. BEA has numerous active discussion groups online and with the addition of BEA's dev2dev site (http://dev2dev.bea.com), there really is a wealth of information available. In this area, BEA definitely has an edge, although IBM is closing that gap.

Another key intangible factor was developer experience. Personally, I've worked with every version of WebLogic since 4.5.1. Several of the lead developers also had development and deployment experience with WebLogic. We found that that was not the case with WebSphere. There was a smaller learning curve for a majority of our developers, who already knew WebLogic, which we knew would allow us to port our application faster.

Okay, I left out one of the most important factors. Cost. As developers, cost was a non-issue to my team and me; however, the business folks seemed to be concerned with this! This is where I, as a technically savvy person, stepped away and let the sales people do their business. In the end, the costs of the two products turned out to be very comparable - after we made it clear that the two companies were competing against each other. Capitalism at its best!

Porting the Application
With our future application server chosen, it was time to actually port our application to WebLogic 7.0. One of the core concepts of J2EE is application portability. It was time to put that notion to the test.

Although we always try to avoid it, there were a couple of areas where we had written to proprietary APIs. Programmatically logging in a user to a Web application using a security realm is one of those examples. Fortunately for us, WebLogic has a similar capability that we were able to use by simply wrapping our code.

Ultimately, we really didn't need to change much of our code at all. Most of the deltas to our source tree came in the form of modifications to our application packaging and the vendor-specific deployment descriptors. While porting our large application took a little bit of time and effort, the process was relatively smooth. That is a testament to the portability of J2EE applications and WebLogic's support of this standard.

Overall, BI has been very pleased with the decision to move to WebLogic. WebLogic Server provides the scalable and reliable environment that we require and provides us with the latest support of specifications and APIs. Based on our experience with moving to another application server, you should keep the following in mind:
1.   Narrow the list of contenders to a manageable size: The smaller the list, the easier it becomes to selectively compare the products. It greatly simplifies the overall decision process.
2.   Use a feature matrix to quickly size-up vendor options: This is also a handy way to discover subtleties in each server. Remember, however, that some features are more important than others. Weigh them accordingly!
3.   Keep in mind all aspects of the server, including scalability, standards support, ease of development and maintenance, as well as proprietary features your application can take advantage of: While both servers may support the specification, implementations are vendor specific!
4.   Be diligent about conducting interviews with vendor references: If possible, try to get neutral parties.
5.   Total Cost of Ownership (TCO) is a factor when considering a large-scale application: Remember, TCO involves hardware as well as per CPU licensing. You want an application server that can scale to large numbers on as few machines as possible to lessen the cost of hardware.

I for one am looking forward to working within our new environment!

More Stories By Chris Siemback

Chris Siemback is an Applications Architect. He has
been worked on numerous J2EE-based applications and
his work has also been featured in he Java Developer's

email: [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and G...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.