Business rules have gone from a technology that only a programmer could love, as well as being confined to specialist use cases, to a powerful platform that is often found coupled with SOA environments, helping to shape a new, more declarative programming model. Business rules platforms automate decisions, analysis to action, and policy compliance. This popularity is evidenced by the large volume of Forrester client inquiries on the topic and the strongly growing revenues of most business rules platform providers.

Forrester evaluated the strengths and weaknesses of top business rules platform vendors. The results of their evaluation: Fair Isaac, ILOG, and Pegasystems are the leaders in general-purpose platforms for IT because of their comprehensive developer features, rules management features, and strong presence in the market.

However, specialist vendors like Corticon Technologies, Haley Systems, and Resolution EBS are the leaders in platforms for nonprogrammers and nontraditional rules development, which is just one of the new product segments that are emerging within the business rules platform market.

Forrester has included business rules technology within our definition of the application platform for several years, and the recent, more rapid growth in this market shows that this view is now playing out in the market. So just as with acquisitions in the SOA infrastructure context, expect to see further consolidation or extension of the major SOA platforms to fully embrace this concept of rules in the platform -- this year.

Within a strategic SOA, the most important layer is the business service one -- the inventory of SOA-based services that deliver your core business capabilities in a modular, incrementally composable way that is ready for connection to any business process, partner, supplier, or customer. SOA and Web services management solutions apply enterprise management concepts to this service interface layer, delivering flexibility by enforcing policy and monitoring activity for service requests before they are delivered to the business logic of the service.

One can obtain SOA management capabilities from dedicated products or from features embedded in other products. To assess the state of the SOA management market and see how the solutions stack up against one another, Forrester evaluated the strengths and weaknesses of top SOA management vendors across 106 criteria. The result: Two pure-play SOA vendors, AmberPoint and Actional (recently acquired by Sonic Software), lead the pack, but platform vendors like CA, Hewlett-Packard, IBM, Oracle, TIBCO Software, and webMethods also have much to offer.

The acquisition of Amberpoint by Sonic Software is just one of a series of transactions that are driving the consolidation of the SOA infrastructure market, which also includes CA-Adjoin, IBM-DataPower, Mercury-Systinet, and HP-Talking Blocks. Use this Forrester Wave to better understand the dynamics of this part of the market, as well as to choose a solution.

IBM had announced the launch of their Community Edition version of the WebSphere Application Server. The application server is based on the Apache Geronimo.
My observations on the same..

1. Initial download was very smooth. The zip file was just about ~42 MB. Small footprint is sweet.

2. Installation of the server is another plus. Easy and intuitive. Any one can install. the whole installation footprint was just ~95 Mb. Coming from IBM, thats another big plus.

3. Got the server started. The start up time was just about 30 seconds. Couldn't believe.

4. Opened the Admin Console. Now, the first thing it asked was userid/pwd. Could not find the same anywhere. Had to open the Infocenter Help for help. BTW, the default userid/pwd is system/manager. Reminded me of Oracle DB days.

5. Once logged in, the interface was bare minimum but covered most of the things. Like all J2EE 1.4 servers, it provides a platform for multi-tier enterprise applications, including support for

* Java Servlets
* JavaServer Pages (JSPs)
* Enterprise JavaBeans (EJBs)
* Java Database API (JDBC) for data access
* J2EE Connector Architecture (JCA)
* Java Message Service (JMS)
* Java Naming and Directory Interface (JNDI)
* Java Transaction API (JTA)
* Java API for XML-Based RPS (JAX-RPC) including support for web services
* J2EE Management Model
* J2EE Management Extensions API (JMX)

6. Next step is to try and deploy some application and see how easy or difficult it is. Another thing, I want to try is to try deploying applications developed for WAS Developer/Enterprise Edition and see what all we need to do to migrate and deploy on the WAS community ed.

I will blog the same next time.

The capability of portlets to exchange information (also called inter-portlet communication or cooperative portlets) is powered by the property broker in WebSphere Portal. The WebSphere Portal V5.1.0.1 property broker does not support inter-communication between IBM portlets and JSR 168 portlets because they run within separate portlet containers. This article shows you how to write a custom portlet service to enable legacy IBM portlets and JSR 168 portlets to share information as properties. You also see how to manage the life cycle of a shared information property in a distributed environment, using the dynamic WebSphere Application Server caching feature.

Filed in: WPS

When ever, you are trying to move a J2EE application across vendor platforms, we usually run up many issues. I have listed down, some of the high level issues that crop up when doing this kind of migration.

Application uses vendor-specific services.

Some vendor-specific services provide proprietary features that may be critical to your application. In this case, you will probably have to do some redesign to obtain the desired result, possibly becoming dependent on another vendor’s services.

Older applications may be using vendor-specific services simply because that was the only service available when the application was written. As the J2EE specification evolves, some of these cases have become standardized. A migration project is a good time to upgrade to the newer specification. Since you will have to make a change anyway, why not move
toward the current J2EE standard?

Application uses J2EE standards, but still contains non-portable code.

It is possible to use the J2EE standard and still write non-portable code. For example, the JDBC APIs provide many opportunities to embed vendor-specific strings, for example, table names and database types. An EntityBean with bean managed persistence could therefore easily be no portable. For this case, we may recommend the use of the Enterprise JavaBeans environment services in conjunction with more portable JDBC APIs. Use good judgment and good programming practice to make these decisions.

J2EE support is partial or differs between server products.

The J2EE specification is a moving target and vendor support is bound to lag behind the latest standard. Although your application may be running on a J2EE-compliant server, loopholes in the J2EE implementation may expose migration issues. In some cases, the J2EE specification has been interpreted differently. Since it is difficult to predict these migration issues, we rely on experimentation to identify them. In these cases, we try to guide you in the direction of the latest J2EE specifications to avoid future problems.

Vendors support different versions of the J2EE specification.

It is relatively easy to identify these migration issues by reviewing the relevant J2EE specifications. We are faced with the fact that the one vendor supports Enterprise JavaBeans 1.1 while the target system supports Enterprise JavaBeans 1.0. This impacts both Java code and deployment descriptors. For each of these migration issues, we try to preserve as much of the EnterpriseJavaBeans 1.1 class=GramE>code as possible, to facilitate future updates to Enterprise JavaBeans 1.1. These migration issues are generally localized and well-defined, making the use of automation attractive.

Vendors provide needed services that are not yet covered by the J2EE specification.

The J2EE specification does not cover all situations. The J2EE 1.4 and Enterprise JavaBeans 2.0 draft specifications provide clues for future directions, and vendor might be supporting these in some format.

Despite the architectural arguments for or against using document style across the board, the fact is that the WS-I has declared that both RPC-Literal and Document-Literal style Web Services are allowable for interoperability. In particular, you need to evaluate whether to use document style or RPC style messaging in your web services based on the details of the particular scenario you are implementing. While you want to be consistent in your processing model, you can achieve this by using either document and RPC style in a consistent way. You do not have to choose just one style throughout your business.

Some guidelines that can help you identify which mode to use in a particular scenario are:

* Some XML is intended to be treated as documents (for instance, consider a newsfeed). Document style should be used when the message payload is going to be processed as XML, for example, when it is to be transformed into another format and stored directly into a database or if the payload is going to be merged with other XML and then sent on to another destination.

* If your application already has XML interfaces, you will probably want to use document style. Likewise, if you are sending data conforming to an industry XML vocabulary, you will probably to want to use document style.

* When executing functions or sending data which will be analyzed, you need to carefully evaluate the choice between document and. RPC offers simplicity and sometimes better tooling support. Document offers greater flexibility and decoupling, and under some circumstances (large messages with many elements) vast reduction in message size, but may requires more XML expertise and hand coding.

However, despite that fact that both models have been accepted, the practical fact of the matter is that there have been fewer problems found when using document-literal style communications than RPC style. Thus, if you anticipate any interoperability with your services, it is advised that you plan on using the document-literal style for your Web Services. When doing so, be very cognizant of the limitations placed on what XML Schema elements can be understood by JAX-RPC and other vendor tool sets.

A good article discussing the various styles of WSDL can be found here.

IT architects and developers are taking a life-cycle approach to Service-Oriented Architecture (SOA). IBM offers several enhanced products to support every stage of the SOA life cycle and to strengthen the SOA Foundation. But what are the practical steps you need to get started? In this article, you'll learn how to build your first Hello World SOA application.

This article, primarily for IT security professionals, describes how to use IBM WebSphere® Portal to encapsulate a security scan tool. Users can access a portal to request a scan of their own computers; they see the results of the scan in the portal or in an email. You learn how to integrate the scanning tool, which runs as a service on a server, with your company portal. The tool delivers the results of the scan to the user through the portal interface. Readers should have experience with Java programming, and have a good understanding of database development, the Nessus open-source vulnerability scanning tool, and portlet development for Websphere Portal.

During development of any J2EE applications, we often run across issues wrt what to do with the common code ?
Should we bundle the common code jar along with the EAR file ? or
Should the common code jar go in the shared library path ?

There are different schools of thought that say we should follow one over the other. Here I will try to list some of the pros and cons of placing the common code in the shared library

Pros

1. The development team will deal with only one version of the common code. Had the code been bundled with every application, then dealing with multiple versions becomes a nightmare.

2. Using common code means changes to the underlying framework can be done easily and the change will be effective for al the application in one go.

3. Fixes to the common code automatically apply to all applications.

4. Small amount of memory and hard disk is saved with having only one copy of the common code library.


Cons

1. Backward compatibility is paramount. Since every application uses the same version of the common API, it is nearly impossible to coordinate API changes. Thus, the API must be very stable.

2. Changes desired by one application impact all applications. This makes introducing change very difficult. Application teams will have to coordinate their development and test cycles.

3. Fixes required by one application impact all applications. This creates the difficult tradeoff between fixing one application quickly and the risks introduced by the change in other working applications.

4. Code on the lib/ext classpath is not reloadable. Thus, changes to it require restarts of the application servers. Updates to EARs require only a restart of the EAR.


Finally, the team has make a decision, based on the cost benefits analysis of sharing the common code library at runtime.

I had talked about the J22 pitfalls here and here earlier. The J2EE best practice bush has been beaten around for a long time. I came across this set of best practices on the WebSphere site. I am mentioning the high level points here. For complete details check out the article here.

1. Always use MVC.
2. Apply automated unit tests and test harnesses at every layer.
3. Develop to the specifications, not the application server.
4. Plan for using J2EE security from Day One.
5. Build what you know.
6. Always use Session Facades whenever you use EJB components.
7. Use stateless session beans instead of stateful session beans.
8. Use container-managed transactions.
9. Prefer JSPs as your first choice of presentation technology.
10. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
11. In WebSphere, turn on dynamic caching and use the WebSphere servlet caching mechanism.
12. Prefer CMP Entity beans as a first-pass solution for O/R mapping due to the programmer productivity benefits.