With the release of IBM® WebSphere® Integration Developer and IBM WebSphere Process Server, comes a new programming paradigm for building service-oriented architectures (SOA) called the Service Component Architecture, a new programming model designed specifically for building and assembling business solutions in an SOA, and targeted for integrating and composing services. Check out the same here.

Link

I had talked about ESB Myths some time back. Today, I thought let me take one step backward and find out

What is ESB?

One defination goes as
"An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. An ESB can power your service-oriented architecture (SOA) by reducing the number, size, and complexity of interfaces between those applications and services."

Another says
"The Enterprise Service Bus (ESB) provides a new way to build and deploy enterprise service-oriented architectures (SOA). ESB is a concept that is increasingly gaining the attention of architects and developers, as it provides an effective approach to solving common problems such as service orchestration, application data synchronization, and business activity monitoring."

Another says
"An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond."

Another says
"An ESB is software infrastructure that simplifies the integration and flexible reuse of business components using a service-oriented architecture. An ESB makes it easy to dynamically connect, mediate and control services and their interactions."

Another one says
"An enterprise service bus refers to a category of middleware infrastructure products or technologies, based on Web services standards, that enable a service-oriented architecture via an event-driven and XML-based¹ messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code."

I feel the last defination describes the ESB better. ESB is an abstract layer sitting on top of a messaging system, which makes use of Web Services to achieve connectivity.

Although the exact definition of an ESB varies, most agree that the following are characteristics of an ESB::

* it requires the clear separation of message headers and message body
* it is usually operating system and language independent; it should work between Java and .Net applications, for example
* it (often) uses XML and Web services to transport messages
* it includes adapter standards (such as J2C) for incorporating existing applications into the bus
* it includes support for asynchronous processing
* it includes intelligent, content-based routing
* it includes a standardized security model to authorize, authenticate, and audit use of the ESB
* it includes transformation services (such as XSLT) between the format of the sending application and the receiving application, including the transformation of data/message formats
* it includes validation against schemas for sending and receiving messages
* it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
* it can conditionally route or transform messages based on a central policy
* it is monitored for message latency and other characteristics described in a Service Level Agreement
* it (often) facilitates "service classes," responding appropriately to higher and lower priority users
* it supports queuing, holding messages if applications are temporarily unavailable
* it handles a "publish and subscribe" messaging model, including event handling
* it handles business events from disparate sources

Any J2EE application needs some type of caching. Whether, the application needs to cache some meta data or some global objects , caching has always been used. Caching can dramatically improve performance of your application. The idea behind caching is to store locally any data that changes infrequently but which may be nonetheless expensive to obtain from the data source—such as data obtained from a database.

Most of applications I have come across or even developed myself, make use of some type of Singleton pattern making use of a hash table. Here we create a singleton object which gets the data from the database and caches.

public class GlobalCache
{
private static GlobalCache
instance = null;
private List classes;

public static GlobalCache getInstance() {
If (instance == null) {
instance = new GlobalCache ();
}
return instance;

}

// Prevent instantiation

private GlobalCache () {
classes = loadDataFromDB();
}

public List getClasses() {
return classes;
}
...
}

This approach works fine for standalone applications, but for a distributed environment, this approach won't work because the caches on individual nodes must get synchronized within the cluster.
Now, what are the options available to us?

One way is use caching solutions available in the market. Products like

SwarmCache
OSCache
EHCache

This is just a sample, market is flooded with caching solutions.

But, in case we do not want to use any of these caching solutions and want to develop something in-house that supports caching across clustering.. (Typical mindset of controlling what's happening in the application ?)

In a clustered environment each server runs in its own JVM, which poses an interesting problem: What happens when the repository changes on one node in the cluster? The caches residing in the other application server nodes quickly become out of date, and users connected to other servers in the cluster will get stale data.

The option is to make use of JMS. JMS is a natural fit for this problem, and it has the following advantages:

• JMS provides a simple yet flexible messaging API
  
• JMS is standard in any J2EE compliant application server
  
• MS is the basis of EJB 2.0's Message Driven Beans (MDB), which greatly simplify writing asynchronous J2EE applications

I am currently working in developing a caching solution on the same lines. Once finished, I will share my findings.

During my experience in handling J2EE projects, the LDAP has always proved to be a mystery for many a team members. Faces tend to go blank and they just don't know how to use.configure or write code to work with LDAP. I found a very nice article which takes your through the journey of LDAP - right from basics to the Advanced level where you configure LDAP with IBM WebSphere.
The article is in a 5 part series. Check out the same here.
Part 1
Part 2
Part 3
Part 4
Part 5

IBM has released a tool that allows organizations to calculate ROI for their Portal Projects. IBM says that ROI calculator that will help the organizations to select and frame the benefit areas and sample costs of an IBM solution. The ROI calculator allows the organizations to easily adjust cost and benefit drivers for the company's business portal project. Very useful to craft a business case for specific integrated business portal projects.

Check out the WPS ROI Link, for more details.

Another ROI Link...

I subscribe to the J2EEPatterns mailing list. One of the questions I recently came across was on the Singleton Pattern. The pattern seems to little hard to understand specially when it comes to multi threading. One IBM Article that really explains the Singleton Pattern implementation. I went through the same and I must say the article is Must Read.

I came across another article that talks about the challenges and pitfalls of J2EE.
1. It talks about the architectural approaches when selecting Application server.
2. What needs to be considered when designing and developing production ready applications?
3. How Operational requirements impact the application?

For full article, click here

You can also refer to my earlier article on the same subject

This article discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA). The author stresses the importance of addressing the techniques required for the identification, specification and realization of services, their flows and composition, as well as the enterprise-scale components needed to realize and ensure the quality of services required of a SOA.

Advanced Web sites typically consist of both static content (served by a traditional Web server) and dynamic applications (using a portal product) surfaced in a common end user experience. With the new adaptive page caching, portlet caching, and object caching functions, IBM® WebSphere® Portal V5.1 can efficiently serve the dynamic parts of a Web site while projecting the static parts into caching proxies or browser caches. This paper explains how and why to run an entire Web site -- including the static parts -- on WebSphere Portal with unified deployment, administration, and content management.

After years of providing highend messaging solutions, IBM announced that it would begin to ride the bus. A host of new additions to its WebSphere product line, including a lightweight WebSphere Enterprise Service Bus and an Eclipse based service-oriented architecture development tool known as WebSphere Integration Developer, marks the company’s expanded SOA platform.

IBM also announced a wider partnership program for its SOA offerings, a new WebSphere Process Server, the WebSphere Business Modeler and the WebSphere Business Monitor. In addition, the company said it will release an updated version of its WebSphere Message Broker. The announcements reflect an array of new solutions that IBM is offering for start to-finish SOA implementation within enterprises.

Recently, I migrated from WSAD to RAD 6.0. I have started working on creating JSF portlets (JSR 168 compliant). While, surfing the net for any good article, came across this 2 part tutorial.

Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 1

Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 2

I found it pretty useful although the instruction are little cryptic. So you need to go through the article pretty closely to get the sample running.

Another 5 series article on creating plain vanilla JSF applications.

Developing JSF Applications using WebSphere Studio V5.1.1


This I found easy to follow and give clear instructions to go about creating the application. The same logic can be followed for creating portlets also.

Filed in: WPS

Message-Driven Beans in WebSphere
— With WebSphere Application server 5.0+ you can now add Message-Driven Beans (MDBs) to your WebSphere arsenal. These beans are handy for many processes. I recently had to write a MDB using MQ Series. WebSphere Application Server (WAS) 5.0 had the same functionality built-in, but I had a hard time learning how to use it. I also encountered some issues while configuring it to run in a load-balanced environment.

During my last couple of years as architecting J2EE applications, I have come across certain do's and don'ts, during the design of a Enterprise Application.

1. Use of EJB's
Many projects use EJB's because that is the "in thing" or because this is an enterprise application, using EJB's is a must. My experience says use EJb's where it makes sense. Places where you need to utilise the EJB Container services - like transaction, security. In case, the application does not require all this, then the application should look at POJO's as a viable alternative.

2. Validations
Another issue is the deciding which validation need to be done at client side and what all need to be done at server side. We tend to segregate the validations between client and server. It works fine, as long we are the only clients for our server objects. The movement, another client(Rich Client Application, Mobile Applications) wants to utilise the services of our server objects, our server objects start bombing, because the new client is not conforming to the client side validations expected from him. The best practice is to make sure that our server objects does all kinds of validations so as to avoid any bombs later on.

People might question, on why do we do perform simple checks like field length validations twice. I say, you are not doing twice. Look from the Responsibility angle, the serve object needs to be self sufficient to perform all validations for the data the object deals with. The server object should not fail because the client did not gave correct data or all the data. Validation on the client side are more from Presentation layer perspective, where the client can restrict the user from entry garbage data or insufficient data.

3. Application Security
When starting the design of the enterprise application, the application security is the most ignored aspect. It is usually added as an add-on the application during the fag end of the application development. But it might be too late by this time. Security needs to be thought through and implemented as a vertical layer in your application.

Once, I worked on an application, where the application had almost 10 different types of security requirements. Privileges needed to be captured at multiple layers. Presentation layer had different set of security privileges. Business layer had different, Data Layer different. Even the data going into database needed to be encrypted, even the DBA was not supposed to see that data.
There is a nice book Core Security Patterns: Best Practices and Strategies for J2EE™, Web Services, and Identity Management on the same subject.

4 Internationalization and Resource Bundles
Another pitfall is the non-use of resource bundles. The common excuse is, our application is a extranet application or meant for one particular customer target or country, where the requirement is English only. Internationalization is the underlying theme today for all applications. The application should from day one take internationalization into account. Here,just moving the text for labels, or messages does not make the job complete. Things like menu items text, application header and footer and also how does the language effects lay out of the page need to be accounted for.
In the old client-server days, I remember we were working on a MFC based windows applications where we needed to support 2 languages - English and German. So the mandate was the length of each field label needs to be 25% extra as what we had for English label.
Check out J2EE Internationalization and Localization

5 Improper Use of MVC model
MVC is a presentation layer model. Adding business logic to the model class leads to wrong usage of the MVC model. The model class should call a business delegate class and that business delagate class should invoke the business objects. The Business Delegate acts as a client-side business abstraction; provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services.



These are some of the big ticket guidelines. I will try to blog down another set soon. Watch out for the same.

Filed in: J2EE

Recent, I came across an article that talked about the 10 top myths when it comes to Enterprise Service Bus(ESB). I am mentioning the heading's here.

1. ESB is just a new name for EAI.
2. ESBs compete with J2EE application servers.
3. I don't need an ESB if I'm using Web services.
4. An ESB is simply an abstract concept or design pattern.
5. ESBs are simply message-oriented middleware with a new marketing spin.
6. ESBs will be obsolete once BPEL and the WS-* standards are complete.
7. Microsoft is building an ESB with its Indigo project.
8. An ESB container can be implemented using an EJB container.
9. ESBs offer yet another proprietary middleware stack.
10. ESBs are useful only for departmental applications.

Read details about each of these here

Filed in: SOA

Disparate Service Invocation Challenges and Solution Alternatives for SOA in J2EE by Sushil Shukla and Sudhir Bhojwani -- This presentation discusses the challenges in heterogeneous service invocation and solution alternatives in the form of Apache WSIF, Apache Beehive and other custom frameworks.