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
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO 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.
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    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...
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    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...