BEA Confronts J2EE Productivity, Integration Gaps
With the release last week of WebLogic 8.1 and associated tools, BEA Systems, one of the vendors credited with inventing the J2EE app server space, says it's time for Java/J2EE devs to examine how to more efficiently build, manage and integrate their complex code. IDN spoke with BEA execs, users and analysts to see just how BEA is filling in what they see as J2EE productivity gaps.
BEA Systems, one of the vendors credited with inventing the J2EE app server space, says the time has come for enterprise Java/J2EE developers to think more about "time to value" by using tools and platforms that enable easier integration of components and applications.
Tapping into an integration-ready app dev trend gaining momentum in both Java and .NET technologies, BEA last week officially released its integrated WebLogic Platform 8.1, along with its expanded suite of Workshop visual dev tools and integration capabilities. The goal, BEA execs said, is to bring devs an integrated stack of app server and app dev technologies to make it easier for Java/J2EE devs to support application integration across Java and non-Java (including .NET, C++ and IBM mainframe) environments.
[In specific, WebLogic 8.1 is shipping now, bringing together BEA's WebLogic Server 8.1 with an application server; a portal server, its Liquid Data XML-based data access environment, along with WebLogic Workshop visual modeling and design tools for app development, data integration and business process integration. For more on the product map, seeIDN's earlier story.]
Filling Java/J2EE's Missing Pieces
BEA's approach to helping devs create integration-ready apps is based on the realization that there were pieces missing in the JCA (Java Connection Architecture), said Vittirio Viarengo, BEA's senior director of product management. "We took the JCA infrastructure and added some of the things missing. For example, we added bi-directionality, so when an event is happening in the system, you get notified," he told IDN.
Another feature Viarengo noted is BEA's approach to enabling devs to "put Java controls in front of components, and basically create business abstractions that make it easier to work with code." He explains it this way: "As long as the [underlying] business services don't change, this approach can make it easier for developers to 'add employee,' 'get employee benefit' or any of a number of basic services. The idea is to have these services loosely coupled with the implementation."
"Developer-as-Integrator" is Sign of the Times
Some analysts say it's a good beginning, but that BEA may need to do more to assure developers. "BEA has taken a first step toward making it easier for Java developers to get into integration, but they really need to consider whether they need to do more at the adapter level," said Shawn Willett, an application infrastructure analyst with Current Analysis in Sterling, Vir.
As a case in point, Willett pointed out that most of BEA's adapter and connectivity technology is OEMed from iWay Software, "and that can be a vunerability because they don't control their own IP [intellectual property] to take it in the direction their customers might want to go."
Ronald Schmelzer, senior analyst at Zapthink, a web services analyst firm in Waltham, Mass. said the BEA move is simply a sign to things to come, as development tools all embrace integration-enabling technologies. "I don't think that there is thing as a separately definable market for 'lifecycle dev-to-integration,'" Schmelzer told IDN.
"The truth is that most application server vendors, development tool vendors, and the emerging class of Service-oriented integration vendors are all going to have to produce 'build-to-integrate' tool suites," he said. "What we're seeing is the entire class of development tools mature -- not separate into different markets.
"Basically," Schmelzer added, "developers are being increasingly called to develop not just point solutions, but reusable Service components that are going to have to easily integrate in heterogeneous environments. So, what development tools vendor would NOT want to be in this space?"
IDN asked BEA CEO Alfred Cheung whether frontline devs will be attracted to BEA's approach, as well as the added responsibility for back-end application integration.
"[As] we've seen in the past, these [integration problems] are very complicated problems by the most technical people in the organization," Alfred Chueng, BEA's CEO told IDN. "There was never any enabling tech to reach the developer. A lot of the hard work is done," he added, "but now what we have to do [is] to get integration technology, portal and JVM [among other components] to work together in the runtime. We're only supplying one pieceâ€¦The rest of it will be in the implementation on how people will use it."
Identifying, Filling the J2EE Gaps --
An End User View
IDN spoke with Scott Metzger, CTO of TrueLink, an e-provider of credit information to consumer and businesses based in San Luis Obispo, Calif., and a new user of BEA WebLogic 8.1, to get a better sense of the state of today's Java/J2EE developer, and how BEA's approach begins to address some growing concerns.
Metzger, who has a staff of about 35 devs, said that as a user of J2EE for more than three years, he had determined there were eight (8) gaps between the state of J2EE platforms and tools, and his B2B online and offline needs. One of his main concerns? For many corporate application projects, home-grown Java/J2EE development doesn't scale very well.
"Using JBoss, we initially thought we could save money by using an Open Source Java implementation, but we found many hidden costs and some hits on productivity," Metzger said. "The first part of the cost was just spending too much initial time on developing our own extensions to J2EE to meet our business needs. We also found that over time, we were spending more and more maintenance effort on our infrastructure, so the long-term costs for us were going more toward maintaining the infrastructure rather than building new applications."
Metzger admits that when he first made his JBoss decision three years ago, he knew there would be some added costs, "but then, J2EE didn't meet all of our needs." Even in messaging, Metzger conceded that JMS "wasn't fully baked when we got started." That forced Metzger and his team to build their own lightweight protocol that would support a service-oriented architecture.
Because of Metzger's dual needs of online and offline services, he admits TrueLink was pushing the limits of Java/J2EE when they began. "We wanted a common code base for our online transaction model and offline batch model, so with SOA you can do that effectively, but that means having a loosely coupled versus a tightly coupled architecture," he explained. "But, at the beginning, with J2EE you had to buy into a tight-coupled architecture. That's why we started so many custom [home-grown] infrastructure projects."
"Even JMS wasn't fully baked when we got started," Metzger went on. "So, we ended up developing our own lightweight protocol. What we wanted to do was a clear vision of having a service-oriented architecture because we wanted a common code base for our online transaction model and offline batch model. Having SOA, you can do that effectively, having loosely coupled versus tightly coupled."
When asked if this need to augment Java/J2EE with custom infrastructure was common, Metzger replied, "J2EE is complex, and requires some deep specialization in certain areas, especially in the internals of messaging and database interaction." He went on to note that Java/J2EE's tendency to require exact alignment between client and server can be problematic.
"A standard J2EE 'best practice' is to transfer data over a wire protocol by serializing your objects and sending them in RMI-like style. With our [home-grown] lightweight messaging protocol, we found that the versioning has to be exactly right; meaning that if you change the version of the client interface, you have to make sure the server interface is exactly in synch with that. If it's not, we found frequently that we had to take it all the way back to development before we could even determine the problem was a wrong version of something that was released. So, we found if you didn't check versioning, you could create a whole lot of work for yourself."
BEA started to fill in many of these gaps in J2EE, Metzger said. To avoid the versioning problem in J2EE, Metzger said his team hit on the idea of using XML "to marshal all our information off the wire, which allowed us to not need as fine-grained versioning, and we could also more easily read what was going across the wire." Metzger added he was also attracted by the improved database connectivity over JCA.
Overall, Metzger said, he was glad to see Java/J2EE "moving in a better direction," and noted that even with move from JBoss to BEA, he still expects TrueLink to be on the cutting edge of Java deployment. "We're small enough [a team] to be a little farther out than most Java users, which we enjoyed at times and suffered the consequences [from] at other times."