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
    The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
    Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
    @DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...
    CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear these words all day every day... lofty goals but how do we make it real? Add to that, that simply put, people don't like change. But what if we could implement and utilize these enterprise tools in a fast and "Non-Disruptive" way, enabling us to glean insights about our business, identify and reduce exposure, risk and liability, and secure business continuity?
    In this Women in Technology Power Panel at 15th Cloud Expo, moderated by Anne Plese, Senior Consultant, Cloud Product Marketing at Verizon Enterprise, Esmeralda Swartz, CMO at MetraTech; Evelyn de Souza, Data Privacy and Compliance Strategy Leader at Cisco Systems; Seema Jethani, Director of Product Management at Basho Technologies; Victoria Livschitz, CEO of Qubell Inc.; Anne Hungate, Senior Director of Software Quality at DIRECTV, discussed what path they took to find their spot within the tec...
    The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
    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.
    DXWorldEXPO LLC announced today that Telecom Reseller has been named "Media Sponsor" of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. Telecom Reseller reports on Unified Communications, UCaaS, BPaaS for enterprise and SMBs. They report extensively on both customer premises based solutions such as IP-PBX as well as cloud based and hosted platforms.