Within minutes of my blog entry, I received the strangest email notification, alerting me to another blog written by Alan Zeichick, 'co-founder and editorial director of BZ Media, which publishes SD Times and Software Test & Performance, and which also produces the Software Security Summit, Software Test & Performance Conference, and EclipseWorld. Also president and principal analyst of Camden Associates.' That's what his bio says.

Once upon a time people spoke the same language - but that was long ago. Nowadays people speak hundreds of languages with unique characters, inflection indicators, and other punctuation marks that make each language different from all others.

Faster than you can say XML, a whole cottage industry has developed to standardize the mechanics of Web services to add to them protocols for things like security and routing and workflow, and even to develop standard XML schemas for business.

The first house I ever bought was built in 1936. It had style, it had character, and it had really narrow hallways and tight corners. The sofa we had bought - the one that went perfectly with all the style and character - wouldn't fit in the house. Apparently folks in 1936 had smaller furniture. Eventually I learned out how to take apart a window and was able to get the sofa into the house, but in the process, Pandora snuck out.

Once upon a time, on a project not too far away, a bright young software architect had a thought. 'Why, things are getting a bit complex here,' he said. 'Perhaps I can make things easier by developing a common framework that can take care of a lot of the drudgery involved in developing software.' So this architect got to work right away to develop the framework, perhaps gathering requirements here and there and dipping into the standard pile of available software patterns for appropriate design ideas.

As the father of an avid teenage video game enthusiast, I was a bit amused late last year by all of the excitement and anticipation surrounding the upcoming release of Halo 2. For months leading up to the November 9 release date, I heard all the buzz from my oldest son about how great it's going to be, how much better the graphics will be over the current game, and so on.

It's all quite simple you see. In a major move last year, BEA made a significant and very welcome contribution to the open source community by donating the Beehive framework to the Apache software foundation. Beehive, perceived by many in the industry as somewhat proprietary in nature, is the driving technology behind the BEA WebLogic Workshop IDE and was engineered with one thing in mind: to help make your life easier as a WebLogic and J2EE developer.

In my travels I am often asked whether I am a WebLogic expert. I don't blame people for asking, since it is assumed that anyone who is editor-in-chief of a magazine dedicated to keeping its readers up to date on the myriad of BEA products must know everything there is to know about this end of the software spectrum. You might assume that by now I would be used to the question, 'Are you a WebLogic expert, you know, a guru?'

Earlier this year, BEA donated several proprietary technologies to the open source community primarily to increase the adoption of BEA WebLogic Workshop, which is the basic entry point into the WebLogic Platform suite. Although for typical J2EE applications deployed on the WebLogic Server, Workshop serves only as a basic IDE; for development in WebLogic Portal, BEA WebLogic Integration or BEA Liquid Data for WebLogic, Workshop forms the only IDE that you can really use.

It never ceases to amaze me how something can move from essential obscurity to mainstream hype in what seems to be only overnight. Take the low carbohydrate diets, which are all the rage now. For years, the Atkins diet was considered by most diet professionals to be pure nonsense - how can you lose weight with a diet rich in fat, with bacon and eggs in the morning and a pound of steak or two for dinner? Yet all it took was one investigative report from a prominent newspaper to give the diet credibility.

Rarely does a software product meet the expectations of each and every user. First of all, if it did, I guess there wouldn't be any need for further releases. We all have a wish list of sorts - if only this software program could do this or if only that could be better. Most of the time, you just grin and bear it, keep such thoughts to yourself, and accept the way it works until the next release. If only I had just a little clout to have the vendor design the software exactly the way I want it...

It wasn't all that long ago, the last issue of WLDJ if I am not mistaken, that I expressed my dismay over why so few projects in my travels were using WebLogic Workshop as the primary development IDE. And only a few readers sent in e-mails regarding their reasons for choosing another IDE over Workshop - some of which had a lot of merit (actually, all of them did). And, not being too far removed from the subject, I just happen to be on a WebLogic development project where I came in midpoint through development, and - you guessed it - Workshop was not being used.

Over the past several months, I've had the opportunity to interface with several BEA WebLogic project teams and ask how they do their development. One question I usually bring up, mainly out of curiosity, is whether or not they decided to use BEA WebLogic Workshop as part of their overall development strategy.

We often like to assume that most corporate IT organizations have kept somewhat up-to-date with all of the various technological innovations over the years, and have done so in an incremental manner. However, the reality of the situation is quite different. You may (or may not) be surprised by how many IT organizations do not necessarily ride the 'bleeding edge' wave for one reason or another.

Anyone who has recently been on the job hunting circuit, looking for a position as a developer, knows that employers are getting rather picky. With the oversupply of IT professionals, recruiters are not just looking for good people, they are looking for good people with an exact skill set to match their requirements. As such, the chances of getting the position you desire is not as guaranteed as it was back in the boom times four years ago.

While recently reading through a leading national newspaper, I happened to notice a slick, full-page advertisement for a new enterprise-class server. Made by a leading hardware manufacturer, it was one of those N-way Intel Xeon rack-mount systems that are in a whole league by themselves compared to the machines you and I have at home.

The novel Dune, by Frank Herbert, a classic in science fiction, is littered with great references and quotes. One such quote is: 'Knowing there's a trap is the first step in evading it.' With this in mind I can't help but think of the future for BEA WebLogic. The trap I refer to is the consolidation of application servers and operating systems to implement application server platforms.

The start of a new year is traditionally a time when we reflect on where we've been for the past year, and what we hope for the coming year. Magazine editors take this opportunity to take part in an age-old ritual, making predictions for the new year. What will the industry achieve during the upcoming year? What struggles and opportunities will we reflect on this time next year?

A colleague of mine, who is a senior architectural specialist, recently finished a short, three-week consulting engagement with several other performance-test engineers to determine why it was taking several minutes on average for users to log in to a financial funds management system.

I currently find myself on a consulting engagement for a large, multimillion-dollar, enterprise- wide Web services project for a major Fortune 500 firm. It's a golden opportunity to see first-hand the development of a bleedingedge enterprise service bus (ESB), complete with hundreds of Web services-enabled legacy systems and a sophisticated call center workstation front end.

I have always been a firm believer in the value and importance of trade publications in the information technology industry. I remember back in my early days as a consultant being assigned to (more like thrown into) the maintenance end of an Informix-4GL project.

In the battle over application servers, I've got good news and bad news. The good news is that the battle is over. The bad news is that everybody lost. And by that I mean something a little different from what you might think. Application servers are no longer a hot property. Yes, you still need them, and they still form the backbone of a J2EE shop's infrastructure. But the days when you selected a platform on the abilities of a particular application server are over. Part of this is due to the relative maturity of the J2EE specification, which has grown into something that developers can now truly code to regardless of platform choice.

Imagine for a moment what it would be like to be a 21st-century software developer sitting in your cubicle at work. All right, I know that we are already a few years into the century, so let's push it up, say, 50 years.

When I first graduated (well, actually, the second time) I had an offer from a company for a programming job. They were going to hire me, contingent upon my passing the IBM Programmer's Aptitude Test. So one day I drove my college junk heap an hour out of my way to take this test. I had to get an 'A' to get the job.

Have you ever visited one of those theme parks that depict life as it was in colonial times? I'm always fascinated by the blacksmith and other craftsmen who show you just how hard it actually was to produce items that we take for granted, and how many modern inventions, such as electricity, they did without. They look happy, but I know it's just a show for the tourists. No one wants to use archaic methods to create things.

From time to time I hear people say 'those who can, do; those who can't, manage.' Usually a developer mutters this as he begins another 80-hour week courtesy of a slip in the project plan. Of course, once you get to be management yourself, you realize there's more to it than simply ticking off hours on a project plan.

My neighborhood is home to a host of birds, many of which fly south during the winter months. With spring in bloom, I always look forward to the return of the various avian travelers who dart and weave all over the open fields near my home. That's the kind of migration I look forward to.

One of the more interesting conversations I have with IT organizations is over what constitutes a portal. While issues vary, it is clear that there is a business definition of a portal that is distinctly different from the technology definition of a portal. That isn't necessarily a bad thing, as long as you can separate the two and clearly make the transition between one definition and the other. When that doesn't happen, a bit of chaos can result.

This year's BEA eWorld 2003 show is the center of attention for BEA's product announcements and vision for the upcoming year, exciting stuff indeed. The theme for this year's conference is 'convergence.' You'll notice that this theme is likewise ingrained in the articles in this issue of WLDJ to provide continuity with the show.

My house has bars on its windows. Yes, bars. I am sure at some point in the life of the 110-year-old house, they served a functional purpose. Surely, if I were a robber, I'd be more motivated to look elsewhere for my next DVD player to steal, but the bars are more decorative, just ornamental now. If I were truly concerned about security, I'd get myself a modern home security system with all the bells and whistles like motion detectors and night vision cameras. Technology has really bolstered the security for homes in the past decade.

It is the dawn of a new season as BEA WebLogic Developer's Journal moves into its second year. What better way to start the new year than with a focus issue on Web services? And it's not too early to do so; as we move closer to BEA's eWorld 2003 developer conference in March, I'm sure Web services will be a hot topic.

The Web services world is currently cluttered with code-intensive solutions that require intimate knowledge of lower-level protocols to successfully deploy applications as Web services. Much like the initial situation of the World Wide Web, when a detailed knowledge of the HTML specification was crucial to successful publishing, Web services is mired in UDDI, WSDL, and SOAP.

My friends arrived in town (Denver, CO - U.S.) last weekend and to their surprise, I told them I had four football (American football, that is...) tickets to the Broncos game on Sunday. That morning, we proceeded to tailgate, drink, and eat merrily; and then we entered the new 'Mile High' stadium to watch our team trounce the unwitting opponent. My mind works overtime, as my wife would say, and as I watched the game it occurred to me that I was drawing comparisons to work-related matters rather than admiring the Broncos.

I recently upgraded a small WebLogic 6.1 application to WebLogic 7.0. The process was really quite simple. I attribute this smooth transition to the application's standard use of J2EE components and to WLS 7.0's backwards compatibility! I really only had to do a few configuration changes to get it working. In particular, the JMS store and JMS paging store are no longer allowed to have the same JDBC persistent storage prefix.

There's no question about it - J2EE applications are tough, burly pieces of software. Often they require numerous servers, communicate over various protocols, and run on software from various vendors. Let's examine a simple J2EE application in which everything, including the database, runs on one machine. In this case, the Web server and application server are a single instance of WebLogic, and the database is the one bundled with your version of WebLogic. Sounds pretty easy to manage, right? You just put your applications in the /applications directory and WebLogic deploys them for you. Database connectivity to the bundled database came out-of-the-box. Could it get any easier? Actually, it's just the opposite. It could get a lot

Improving application integration has become an increasingly important component of today's IT strategy. In a recent Morgan Stanley survey of 225 CIOs, 80% indicated that they would begin new application projects in 2002, with application integration as a primary initiative.

I have two newsworthy items to talk about this month. One concerns the application server market; the other pertains to a newly announced partnership in the wireless space. Each tidbit dates from July, but as editorial schedules run a bit behind the times, I'll relay them to you now.

Although many of the symptoms of performance problems (e.g., poor response time) are similar throughout the application life cycle, the underlying causes and the techniques used to diagnose them become more complex in later stages as the load increases and the configuration becomes more complex. In this article, we discuss the tools and techniques that are useful in diagnosing tough performance problems that occur under realistic high loads. We also illustrate why tools used in development or under limited load conditions are not suitable for finding such tough performance problems.

If you asked me what the theme for this month's WLDJ is, I'd have to say 'performance and scalability.' I was once asked, 'What is the most scalable way to build a J2EE application?' 'Let's just find the holy grail while we're at it!' I thought. The question is quite common among J2EE developers but not an easy one to answer, even with a stack of ECPerfs up your sleeve.

EJBs have always been the best way to ensure that your applications were portable and would leverage all the optimizations of the J2EE server. Now they are also easy to build. With the release of WebLogic Platform 7.0, you can create EJBs in record time. At the center of this revolution is Container Managed Persistence 2.0, which allows WebLogic to build tools that remove the layers from EJB development.