Part 1 of this article (WLDJ, Vol. 1, issue 8) explored third-party Java Message Service (JMS) integration into WebLogic Server (WLS) and addressed related issues. In Part 2, we'll implement transactional JMS design patterns using SonicMQ and the WebLogic Server Adapter (WLSAdapter) as the JMS solution. Included in this discussion are the message-driven bean (MDB), message-producing bean (MPB), and message- consumer bean (MCB).

It's almost impossible to address the performance of the JMS implementation on the WebLogic Server in a generic fashion. Message size, acknowledge mode, persistence mode, and type of consumer are just a few of the things that can impact the performance. Add the JVM, the operating system, and hardware, which can also affect the performance, and you begin to see why we can't generalize. With so many variables, it's not possible to extrapolate the performance of another JMS-based application, no matter how similar to yours it seems. The only way to understand JMS performance is by testing your own application (or a proof of concept).

BEA WebLogic Server (WLS) is the most widely deployed J2EE application server and continues to be an attractive platform for many enterprise-class situations.

WebLogic Server runs on hardware ranging from PCs to high-end mainframes. Therefore, it's essential to carefully choose the level of hardware necessary to provide optimal performance for your WebLogic Server deployment.

So, you're going to deploy WebLogic Server on the mainframe. Pretty scary, huh? There are all those 'glass house' terms: sysgens, operating systems with a 'z,' parallel sysplex, Workload Manager, and on and on. Without a little education, the mainframe world can be as foreign to the Java developer and architect as the distributed J2EE world is to a COBOL programmer on the host.

'WebLogic Server is supported on the mainframe.' I read the internal announcement and thought 'Huh?' Why would someone want to deploy distributed Java applications on the big iron? What about training Java developers on the underlying mainframe systems?

As a Java developer, have you ever found yourself running into what might be politely called 'issues' related to the CLASSPATH and class loading? If you haven't, you're one of the few. This is one of the most notorious sources of developer aggravation in Java development. Now J2EE has added a new set of wrinkles to this phenomenon.

The Grinder is an easy-to-use Java-based load generation and performance measurement tool that adapts to a wide range of J2EE applications. If you have a J2EE performance measurement requirement, The Grinder will probably fit the bill.

In the past six years or so the claim that Java is a slow language has regularly appeared in articles and news discussions. Most of the time I follow the debate, but after a while I get bored because the discussions remain at the micro-benchmark level. It continues to amaze me that there isn't more focus on system-level performance in discussions of language performance.

One of the big controversies of session handling concerns the performance difference between storing session state in an HTTP session object and using a stateful session bean. My colleagues and I expected that it would be more efficient to store data in an HTTP session object, as we were under the impression that there is more overhead involved with the infrastructure of session beans in the EJB container.

Any product that does well in the market has to have good performance. Although many characteristics are necessary for a product to become as widely used as WebLogic Server is today, performance is definitely indispensable.

With the rapid adoption of Web services standards and increasing support for asynchronous and XML-based messaging in the J2EE specification (JMS, MDB, JAXM, JAXRPC), it's time to address the challenges involved in building business applications based on a service-oriented architecture.

As a developer for a company selling application services to Fortune 500 companies, I was excited about the release of WebLogic 6.1. While its support of J2EE 1.3 features in and of itself is a reason to upgrade or adopt this product, the introduction of SOAP/WSDL-based Web services technology is a significant step forward for an already great application server. What I found interesting about BEA's approach is how relatively simple it is to tap the power of this new infrastructure. For RPC (synchronous-style) services it is a straightforward two-step process.

The rise in popularity of Web services is breaking down barriers and obliterating isolated silos everywhere. That's good news for any organization looking to make e-business the normal way of doing business with customers, colleagues, and partners. Of course, with every falling barrier comes a new set of challenges around the issue of security. In this article, I'll review the challenges of security integration with WebLogic J2EE applications in a distributed environment - and how they can be addressed with an Enterprise Application Security Integration (EASI) framework based on Web-centric industry standards.

Your WebLogic applications have a diverse array of integration requirements, and WebLogic Application Server provides a rich set of technologies to meet these needs. In this article we'll survey these integration needs and show how you can rapidly meet them using WebLogic Application Server and NeuArchitect for rapid application development.

Two daunting tasks face application architects and project managers alike.The first is to architect a solution that will reduce the risks involved with implementing new and changing business requirements during the application development and post-application deployment stages of a project. The second is to architect a solution that will reduce the development time and increase the corporation's Return on Investment (ROI) in past projects by reusing prebuilt visual and business components

J2EE is rapidly becoming an established platform for deploying long-running business-critical applications. As the number of J2EE applications grows and their importance increases, a standard way to manage J2EE servers and applications is becoming a key requirement. Java Management Extensions (JMX) provide a pure Java management infrastructure that can be used for all Java-based software.

As one of the two Sun J2EE Blueprints applications, the Java Smart Ticket Demo application, like its well-known sibling, Pet Store, illustrates best practices for designing J2EE applications. Pet Store illustrates best practices for larger J2EE applications, and the Java Smart Ticket application illustrates best practices for designing wireless applications. Both Blueprints applications were designed with portability in mind. The Java Smart Ticket application is a less complicated example application for showing what it takes to port an application to WebLogic Server 7.0.

Every developer has experienced it. The application that ran so well in testing hangs or performs miserably under load. While there are many possible causes of performance degradation or hangs, this article can't possibly cover them all. Instead, we'll look at three common mistakes in WebLogic Server applications that can deadlock the server or bring your performance to a screeching halt.

The Java Management Extensions (JMX) API provides a standard way of adding management capabilities to Java applications. BEA WebLogic 6.1 provides a full implementation of the JMX 1.0 specification, with all of its management features based on the JMX standard. As a result, the management capabilities in WLS are open and extensible, which makes it easy to build specialized management utilities for applications deployed on WLS.

WebLogic Integration (WLI) consists of many application components, including a B2B application that manages business-to-business contracts during software conversation. To support the B2B application, WLI has a business process management (BPM) application for connecting business processes together. This used to be marketed as a discrete product, WebLogic Process Integrator (WLPI).

To understand the future of software, we need to understand the past, because once again we're seeing that history is repeating itself. This article looks at how the next frontier of software ­ the dynamic assembly of Web services into a new type of composite Web application ­ is following closely in the footsteps of the Industrial Revolution.

Standards can redefine a marketplace ­ consider the impact that SQL had on the relational database market. Standards can also create new markets ­ without HTML and HTTP, there would be no World Wide Web. My thesis here is that Web services and Java 2 Enterprise Edition (J2EE) will have a similarly dramatic impact on application integration.

This spring, BEA will deliver a new, unified application infrastructure platform. The new product name had not been announced as of this writing, so we refer to it here simply as the BEA WebLogic Platform. The new platform represents an integration and extension of the current WebLogic suite of products. Its delivery is an important milestone and opportunity for the WebLogic developer community.

While Web services possess the potential to completely change how applications and organizations are integrated, capitalizing on this innovative technology hasn't been easy. To truly leverage the potential of Web services, you need both an architecture that can handle enterprise integration challenges and a framework that enables developers possessed of varying skillsets to work together. BEA Systems is launching a new product designed to solve these problems - 'Cajun'. Cajun makes it incredibly simple for application developers to build sophisticated Web services.

Of the many challenges facing today's IT system architects, two stand out as being the most common and strategic: Integrating disparate applications and platforms to fully leverage data and software investments. Providing an enterprise-class framework that ensures reliable, available, scalable, and secure applications.

WLDJ: Could you tell us about your new role as BEA's overall CTO and what you think are your challenges in the next year? SD: I've been given a great opportunity to take the position of CTO for the overall company BEA is investing in areas on all levels of the application server that is becoming ever more critical to our enterprise customers, especially in the area of integration. With the emergence of J2EE standards around adapters and the new XML technologies around Web services and workflow, the industry is reaching critical-mass technology for standardizing the way the application and DB2 integration is done.

As a WebLogic developer, there'll come a time when you'll need to file a support case with BEA; many of you have done this already. Throughout the problem-solving process, you'll be speaking with one of BEA's DREs (developer relations engineers). These folks are very knowledgeable regarding WebLogic, and hopefully the two of you will quickly find a resolution to your problem.

Web Services have made quite an impact since the concept and technology were introduced. Just about every major vendor is putting considerable effort into making their products capable of developing and using Web services. This article will illustrate how a Web service can be developed and deployed with the Web services capabilities found in WebLogic 6.1.

Sick of working with all of those different Java files and deployment descriptors when developing EJBs for WebLogic Server? A couple of tools out there allow you to work with just the bean code, and use special Javadoc comments to define what should be in the other interfaces (Home, Remote), and the XML deployment descriptors (ejb-jar.xml, weblogic-ejb-jar.xml). After using these tools, you quickly realize how clean it is to just have one Java source file representing your EJB.

Are you planning to upgrade from WebLogic version 5.1 to version 6.1? Do you want to speed up the process of redeploying your EJBs, servlets, and JSPs to a newer version of an application server? The J2EE specification doesn't define any standard deployment procedures. These differ from vendor to vendor and even from version to version of a particular application server. Read on to find out which steps you should take to redeploy your components and estimate the amount of work to be done.

Welcome to the first issue of BEA WebLogic Developer's Journal! This article is the first of a three-part series geared around the clustering capabilities of BEA WebLogic Server (WLS) 6.1 and aimed at introductory and advanced audiences. This article will talk about the importance of clustering and the high-level clustering capabilities of WLS, provide an in-depth analysis of HttpSession clustering and persistence, discuss basic configuration and trouble shooting, and provide an example that ties together everything discussed in this article. The second article will provide an in-depth analysis of replica-aware stubs, their impact on a clustered system, and how they are used with EJBs, JMS objects, and DataSource objects. The last article will discuss clustering best practices, including the single-tier, coupled model; multi-tiered, coupled model; and the multi-tier, decoupled model.

We all know the story, right? In today's high-tech world, technical support has suffered a demise worse than Darryl Strawberry's life after baseball. It's virtually impossible to get anyone knowledgeable on the phone. Support is the lowest item on the totem pole. Qualified folks move on while the no-ops remain. Support engineers are bitter, angry, disgruntled individuals, bordering on inhuman. Tech support is such a rip-off. The executives allowing this blatant disrespect toward their customers should lose all of their stock options.

This article demonstrates how Wily Technology's Introscope can be used to reach accurate conclusions to resolve a typical Java application performance problem. The article will be useful for architects, operations managers, testers, and developers responsible for WebLogic application performance and will give readers a better understanding of practical approaches to analyzing, improving, and managing production performance, without developing monitoring code by hand.

A synchronous message processing is a requirement of many applications that need to send and receive messages in real time or near real time. The JMS 1.0.2 Specification defines the MessageListener interface that allows an application to receive messages asynchronously from a JMS Destination when a message is sent to that destination. An implementation of the MessageListener interface is typically a client application to a JMS provider that runs in a remote JVM.

In October 1999 12snap's main goal was the development and commercial implementation of the world's first wireless shopping platform for existing mobile devices as well as WAP-enabled phones. The first application allowed mobile phone users across Germany to participate in auctions through a combination of voice, cell broadcast, and short messages, all based on the GSM technology so popular around the world (except in North America).