Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Modernizing Legacy Systems, Part 3

Workflow and services-oriented architecture

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.

    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.

  • More Stories By Anwar Ludin

    Anwar Ludin specializes in service-oriented architectures for the financial sector. He currently works as an independent consultant for
    financial institutions in Switzerland, where he helps design J2EE architectures based on the WebLogic platform.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...