Welcome!

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

Related Topics: Weblogic

Weblogic: Article

Modernizing Legacy Systems, part 2

Integration as the critical step

  • For the previous part of this series please see link at foot of article

    My previous article (WLDJ, Vol. 3, issue 2) introduced a "recipe" to modernize legacy systems with the BEA WebLogic Platform by using a step-by-step approach. In many ways, that article introduced a "modernization process"; in this one I will delve into the details of cross-platform integration and architectural design. I will also use the same recipe-based approach to illustrate how to build a scalable, robust, and maintainable modernized platform around WebLogic. In the process I will present some fundamental J2EE patterns that you will be able to reuse in your own design.

    As I mentioned in my previous article, integration is a critical step in the entire process. Its goal is to provide the bridge between the legacy world and the WebLogic modernized platform. In many ways, the legacy system can be seen as a resource that we want to integrate with the WebLogic Platform. One of the goals of the modernization process is to shield the platform as much as possible from the legacy system so that the design of the modernized system can evolve relatively independently of it. Let's look at the architectural best practices used for integrating both platforms and implementing the integration tier.

    Design a Layered Architecture
    A best practice is to build J2EE applications using logical layers. In particular, higher-level layers leverage the services of lower-level layers. The idea of a layered architecture is to organize the modernized platform according to generality. The topmost layer, the most application specific in a layered architecture, contains application systems that can be considered as a coherent set of use cases available to end users. The layer directly under the application systems, the business-specific layer, contains reusable components specific to a business. For example, for a financial institution this layer could contain reusable components representing accounts, customers, financial statements and reports, etc. The application layer could then contain a Portfolio management package that leverages the underlying reusable financial components. Finally, the layer under the business-specific components consists of infrastructure components such as logging frameworks and utility classes. Some of the characteristics of a layered architecture are:

    • The topmost layer is the most application specific and the bottom one the most generic.
    • Each layer exposes its services to the layer directly on top through a set of interfaces and facades. The opposite is not true; a top layer does not expose its services to the underlying one. However, components located "horizontally" in the same layer can leverage each other's services and public interfaces.
    • Layering addresses module dependencies and therefore minimizes build and packaging time.
    • Data is passed between layers by using Transfer Objects (see "Implement Transfer Objects").
    Layers should not be confused with tiers. A logical layer might span one or several tiers. Layering is really a logical way of organizing your architecture and exposing service interfaces through facades.

    Figure 1, an example of a layered architecture, illustrates the case of a banking system as a set of package dependencies.

    Implement Transfer Objects
    One of the first steps in designing the modernized platform is to identify transfer objects. As you might recall from my last article, the legacy system is most probably implemented by using a procedural language such as COBOL. Therefore, one of our initial tasks will be to encapsulate the legacy system in order to provide a Java object view of it to the BEA WebLogic Platform. Data access objects (see next section) will then encapsulate the legacy services and transfer objects will be used to transfer multiple data elements between the legacy system and the different tiers of the WebLogic platform. So what is a transfer object precisely? Basically, a transfer object is an instance of a plain Java class, used as a container for data elements in order to optimize data transfer between tiers. It must therefore be serializable and is passed by value to the client. A transfer object usually simply provides getter and setter methods to its members. For example, in a banking application we might have transfer objects such as AccountTO, CustomerTO, and CreditCardTO that contain relevant information about accounts, customers, and credit cards. An important point to emphasize is that transfer objects can be used effectively to build a domain model of the legacy system in Java. It is therefore very useful to spend some time identifying the legacy system's business entities. As a good rule of thumb you can map each identified entity in the legacy system to a corresponding transfer object. It is also worth mentioning that transfer objects are used in every tier of your application, from the resource to the presentation tier. It is therefore very important to design and implement your transfer objects in such a way that they are reusable and correspond to the business domain as much as possible. Finally, transfer objects were called value objects in the first edition of the book Core J2EE Patterns. However, the term value object was misleading. It was used well before the J2EE patterns group for "a small simple object, like money or a date range, whose equality isn't based on identity." Also, transfer objects are equivalently called data transfer objects but I have kept the J2EE patterns group terminology in this article for the sake of clarity.

    Implement Data Access Objects
    Data access objects (DAO) are used to completely encapsulate the legacy system and provide a simple and uniform interface to it. A DAO permits the following fundamental operations: create, read, update, delete (CRUD), and find. The parameters passed to and returned from DAOs are transfer objects. In our case the legacy system will play the role of a data source and we will use DAOs to retrieve or update data. Usually we will build one DAO per transfer object. Let's review the interface implemented by a DAO:

    • create(aTransferObject: Transfer Object): PrimaryKey. The create/insert method effectively creates a new business entity in the legacy system and returns its primary key. For example, in a banking system the create method could be used to open a new account according to the information contained in the AccountTO and return the account's primary key, which should also be a serializeable object.
    • read(aPrimaryKey: PrimaryKey): Returns the transfer object corresponding to the primary key.
    • update(aTransferObject: TransferObject): Updates the legacy business entity corresponding to this transfer object's primary key with the new data contained in it.
    • delete(aPrimaryKey: PrimaryKey): Deletes the business entity in the legacy system corresponding to this primary key.
    • find(aQuery: QueryOperator): TransferObject[]: Returns all business entities corresponding to the query operator as a list of transfer objects.
    Now that we have specified the DAO's interface, how do we implement it? As we will see, every method in the DAO's interface will usually correspond to one or several COBOL service programs running on the legacy system. A COBOL Service Program (SP) can be considered a special kind of COBOL module that can be accessed from Java. For example, consider a banking system. Figure 2 illustrates the relationship between a CreditCardTO transfer object and its CreditCardDAO DAO in a class diagram.

    Listing 1 shows a possible implementation of the CreditCardDAO DAO using the Java Toolbox for the AS/400.Note that I have shown only the reate method.

    Note that the DAO pattern has the advantage of completely shielding our components hosted on BEA WebLogic from the legacy system. In other words, we can modify the data access logic during the modernization effort and even completely replace it with entity beans without breaking any of our components relying on the DAOs. We could use a Factory method returning the appropriate DAO implementation.

    Finally, Figure 3 shows the interactions between a client such as a session bean and a CreditCardDAO.

    A Note about Distributed Transactions
    The details of distributed transactions between WebLogic and the legacy system are beyond the scope of this article. One of the major difficulties is to achieve a rollback once a transaction has been committed. In our case, the operations available on the legacy system are exposed as COBOL SPs and a rollback is no longer possible once an SP has been called. Also, the legacy system might not provide any transactional services at all and can only be considered as a simple data source. We could, however, achieve the same result as a rollback by doing a "compensating" data update. This simulates the effect of a rollback on the legacy system by doing, after an operation, a corresponding opposite operation in order to restore the system in the same state prior to the initial operation. Consider once again the legacy banking system:

    • Begin transaction: T in the WebLogic business tier.
    • Update operation: Withdraw amount A from customer account. This actually corresponds to a COBOL SP call with an immediate commit on the legacy system.
    • Commit: Perform commit operation in the WebLogic business tier. The operation has already been performed in the legacy system.
    • Rollback: For the legacy system, simulate a rollback by crediting customer account with amount A.
    Note that the Web Services Transaction specification takes exactly the same approach for long-lived transactions or business activities. Finally, if we consider the most generic form of the operation, where we have a mix of JTA resources and the nontransactional legacy system, we could implement a compensating transaction as illustrated in the following code snippet:

    updateLegacyBankingSystem();
    try {

    UserTransaction.begin();
    updateJTASupportedResource1();
    updateJTASupportedResource2();
    updateJTASupportedResource3();
    UserTransaction.commit();

    }
    catch (RollbackException ex) {
    undoUpdateLegacyBankingSystem();
    }

    Implementing Use Cases
    The modernization recipe introduced in the first article mentioned that use cases with added value should be identified and considered as the initial candidates for the modernization effort and re-hosted on WebLogic. Another important task is to determine to which layer of our architecture the use case belongs. For example, if the identified use case can be reused by several different applications or other use cases, then it should be implemented in the business-specific layer and exposed through a facade interface. However, if the use case is very application specific, then it should be implemented in the topmost application layer of our architecture.

    Conclusion
    In this article I have presented some of the essential patterns for designing the modernized BEA WebLogic Platform's architecture. In order to integrate both legacy and modernized systems, I used the transfer object and DAO patterns. Transfer objects have been used as a basis for building a domain model of our legacy system and transfer data between it and the modernized WebLogic platform. The legacy system can also be completely encapsulated as a data source by using the Data Access Object pattern. Usually we will build one DAO per transfer object.

    A layered architecture minimizes dependencies between components of the modernized WebLogic platform and promotes greater reuse. An important aspect of modernization is to identify value-added use cases of the legacy system and reimplement them in one of the layers of the modernized platform. If the use case is business specific and can be leveraged by other use-case implementations, then it should be located in the business-specific layer of our architecture and its interface exposed as a service facade. However, if the use case is application specific it should be located at the topmost application-specific layer of our architecture. Now that we have built the integration infrastructure of our modernized platform, I will show how to build the application- and business-specific layers of our architecture using BEA WebLogic Workshop in my next article. I will put all of the pieces of the puzzle together and modernize a small banking system with the WebLogic Platform. We will also see how WebLogic Workshop takes a RAD approach towards designing the application.

    Reference

  • Fowler, Martin (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.
  • 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.
    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...
    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...
    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...
    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...
    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...