Architecture

Digg This!

This is the last installment in my series of articles on modernizing legacy systems with the BEA WebLogic Platform (WLJ, Vol. 3, issues 2-3). Part 1 introduced a high-level "modernization process," with a "recipe" towards modernizing legacy systems. In Part 2, I concentrated on integrating the legacy system with the WebLogic Platform. I also introduced the concept of a layered architecture and some fundamental J2EE patterns.

In many ways Parts 1 and 2 represented the fundamental "building blocks" in modernization. This month I'll concentrate on building the business process, or domain model layer. I will also introduce the concept of application services, which is a way of managing the workflow or use cases of the modernized platform. Finally, I'll look at how to build a service-oriented architecture with BEA WebLogic Workshop. As I mentioned in the first installment, one way to summarize "modernization" is by saying that it's a way of incrementally moving business logic from a legacy system to WebLogic.

Business Objects and Domain Models
As I discussed in Part 1, one of the tasks in the modernization process is to "prioritize use cases" in order to port them to the BEA WebLogic Platform. At the time, I didn't really get into the details of how to actually do the porting. Let us now get into those details by studying the business layer of our architecture. The advantage of using an object-oriented language such as Java over a procedural language such as Cobol is that you can actually build a rich domain model. Basically, the domain model will be a layer of interconnected objects with associations and inheritance hierarchies. The domain model will usually be implemented using business objects with fine-grained interactions that have state and behavior. A crucial step in the modernization effort is therefore to design the domain model so that it reflects as closely as possible the business entities used by the legacy system. In other words, the domain model is an object-oriented implementation of the conceptual model we have devised by studying the legacy system. In Figure 1, for example, for a banking system, entities such as accounts, customers, credit cards, ranking strategies, and so on will be mapped into business objects with relationships, inheritance hierarchies, and behavior.

Business objects are nothing more than "plain old Java objects," or POJOs, so they can be tested in an independent way and even reused. It should be noted here that I am making a distinction between business objects, which are POJOs, and entity beans. For me, an entity bean is a persistence mechanism but is not adapted for building a rich domain model. You might not actually agree with my point of view and consider that the domain model can be designed with entity beans, but I personally have found that approach very cumbersome. However, nothing stops you from "persisting" the business objects by using CMP entity beans or, as shown in Part 2, by using DAOs to the legacy system. Now let's look at the concept of "application services," which implements the layer on top of our domain model.

Application Services
You might decide to implement the use cases to be modernized (see Part 1) by using Session Facades. In this case, the Session Facades would directly leverage business objects from the domain model and also contain some logic specific to the use case. In such a scenario, you would have as many Session Facades as modernized use cases. However, this approach has the following disadvantages:

• We are using your Session Facades for the wrong intent. Session Facades are only meant to be used for exposing business-tier components to remote clients as coarse-grained services.
• Our Session Facades become bloated with business logic.
• There is a risk of reproducing use case business logic between Session Facades.

The solution to the previous problems is to use "application services". Application services provide a way of encapsulating use case–specific logic outside of individual business or domain objects. In other words, every use case to be modernized should be implemented by one or several application services that in turn update the domain objects. Another way of seeing things is that domain objects provide the static relationships in the business domain and application services provide the dynamic interactions between the domain objects.

Finally, Session Facades can leverage application services in order to communicate with remote clients. Figure 2 illustrates the relationship between session facades, application services, and business objects in our banking example.

One thing I absolutely like about J2EE is that it promotes component-based design. BEA WebLogic Workshop helps me design a service-oriented architecture by building Web services from my J2EE components but at the same time hiding the underlying complexities of J2EE development. Very powerful indeed. I'll start by defining what I mean by "service-oriented architecture." From my point of view, a service-oriented architecture is a way of building enterprise software so that its functionality can be accessed by "external" applications without relying on "internal" artifacts such as client JARs containing component interfaces. Basically, according to my definition, the service-oriented architecture simply adds a "Web services layer" to our layered architecture, which "hides" the underlying component platform. In that sense, Web services still rely on the underlying layers, such as application services, and the business-specific layer in order to fulfill their job. As you might recall, the business-specific layer contains all the reusable components. So what are the advantages of building such an architecture?

Basically, by adding the Web services layer to the modernized platform, we are promoting loose coupling between systems, which is good because we can evolve the platform without any impact on the clients leveraging our services. That is, of course, as long as our Web services' interfaces don't change. As a result, the modernized system is now seen as a set of services accessible from any internal IT system as well as external business partners. Figure 3 illustrates the overall architecture with the additional Web services layer.

Building Our Web Services with WebLogic WorkShop
The process of building the Web services layer of the modernized platform can be broken down roughly into the following steps:

Import into BEA WebLogic Workshop the required components from the business layer. If your Web services are hosted in the same WebLogic Server containing your business domain modules, then you will simply have to import the application services modules. However, if you decide to build your Web services as remote clients of the business tier, then you will have to import your Session Facade and transfer object modules. You don't need to import any components from the integration layer because they are "hidden" away from you by the business layer. Every layer in our architecture hides the underlying layer and transfer objects are used to communicate between layers.

Design the Web service interface and its workflow. Will it be synchronous or asynchronous? Will it leverage another service? You will most probably design this interface with a business analyst. You can use activity and use-case diagrams during the design process. Basically, the Web service will expose to the "external world" a specific business process relying on the application services of the modernized platform.

Code the service logic using BEA WebLogic Workshop by leveraging the components from the business layer. According to the architecture I have presented so far, the logic provided by the Web service should leverage as much as possible the underlying application services. In that sense, by using WebLogic Workshop you are actually building your Web service by "assembling" or leveraging application services from the business layer. In other words, WebLogic Workshop provides the "glue" to build Web services out of your components. I have found the approach to be extremely powerful.

It's that simple. BEA WebLogic Workshop really takes care of a lot of details specific to J2EE for you. Actually, one way of realizing how WebLogic Workshop simplifies your life is by trying to build the same service "manually," using Apache Axis for example.

Deploying Our Web Services with WebLogic Workshop
Deploying your Web services mainly consists of packaging them with the application services modules or Session Facade client JARs in an application archive. This is actually taken care of for you by BEA WebLogic Workshop, which will generate the EAR archives ready to be deployed. You simply have to select "Build EAR" from the "Build" menu in WebLogic Workshop. The result will be an EAR archive ready to be deployed to a production server. As shown in Figure 2, you actually have several possibilities for the runtime deployment of your services. For example, you might decide to package the entire modernized application with the Web services layer as a unique application archive or for security reasons separate the Web services layer from the rest of the modernized application by deploying them in different runtime nodes. In that case you would build two applications EARs, one for the modernized platform business and integration layers and another one for the Web services layer.

Conclusion
This was the last part in my series of articles about "modernizing" legacy systems with the BEA WebLogic Platform. I tried to provide a recipe-based approach for the different steps involved in the modernization effort. One of the things I also tried to emphasize is that any modernization effort should try to build a better, more robust platform on top of WebLogic and the J2EE specification. The modernized platform should provide additional, or value-added, services in order to justify the effort in the first place. Some of those services, such as security, container-managed persistence, and so on, are provided by the BEA WebLogic Platform. Other services have to be designed by us. However, building the "right" application architecture is extremely important.

I have tried to introduce several patterns that you can reuse in your own design. We have seen that we should build the modernized platform in layers, using the layered architecture approach. Integrating both modernized and legacy systems should be done by using Data Access Objects and Transfer Objects. The approach I have taken is "use-case driven" in the sense that we have tried to identify specific use cases of the legacy system and "re-hosted" them on the modernized platform. Those use cases are then mapped to one or several application services of the business layer. The modernized workflow results from the relationships and choreographies between application services.

I looked at the importance of building a rich domain model, and described the legacy system by designing relations and hierarchies between business objects. Besides giving us a better understanding of the business domain, the domain model provides us with an object-oriented view of the legacy system that was previously built by using a procedural language such as Cobol. I mentioned the advantages of building a services-oriented architecture and illustrated how easily this could be done using BEA WebLogic Workshop.

We used several patterns in the modernization effort (see Table 1), which are thoroughly documented. You can find out more about them by consulting the Core J2EE Patterns, 2nd Edition and Patterns of Enterprise Application Architecture books. Finally, I hope my articles provided some insight into "modernizing" a legacy system by using a rich, multilayered, service-oriented target architecture based entirely on BEA WebLogic.