Consider SOA in a WebLogic environment

I've been working for a client recently, and they have a lot of Java EE Apps deployed on WebLogic 8.1 that require me to help them transform their application assets into SOA service assets. They have strict deadlines, so they can't make big changes to the application code. In the discussion, they constantly raise questions about Web services, and I feel that people tend to think of web services as a component block of SOA. They focus on translating application components into Web services and their impact on the overall environment and operations.

It is not surprising that many people view Web services as building blocks of the SOA infrastructure. I think Web services can be a component block of SOA, but it's not necessarily necessary. I'll explain why and how you can view the application components deployed on WebLogic server as part of the SOA.

Applications can be decomposed into components that implement business functions. Each application has specific business, functionality, and operational requirements. Functional requirements to meet implementation, I am not going to spend too much time on this, because we are talking about applications that have become part of the enterprise and need to be translated into SOA component blocks. What we need to focus on at this point is how to correlate business requirements and provide an easy operating environment for the application.

Many business requirements are attributed to the service level agreement (SLA) of the application, and business requirements may include the following:

Concurrent users

Response time

Error rate

Workload prioritization (business functions are broken down by priority)

Application Adoption Rate (Application extension roadmap for the number of users)

Availability of

Operational requirements are related to maintaining the infrastructure and may include the following:

Application Monitoring

Deployment strategy

Maintenance (patches, upgrades)

Problem diagnosis

In most cases, many applications are deployed on the WebLogic instance, which makes it difficult to correlate these requirements to the environment.

Isolation: Given the above scenario, let's look at a way to translate such an environment into part of an SOA. The first step is to isolate the application or component that is considered a critical type. Isolation can be achieved by deploying these applications to their respective WebLogic instances and then associating the appropriate storage and WebLogic resources to the application. These server instances can then be clustered, which helps with failover, making the environment highly available. Don't forget: The higher your business expectations, the more expensive your infrastructure will cost. If you need to isolate specific components of your application, you can configure the appropriate number of threads for them by taking advantage of the custom execution queues (execute queue) or the new features in the work manager (Work Manager) (9.0). Creating an execution queue provides a separate request channel for application components and prevents requests from lacking critical business functions. Isolation at the connection pool level ensures the availability of database resources.

Server features: We need to understand server characteristics from the aspects of throughput, response under load, and so on. This is done by performing a load/stress test and then tuning the environment to obtain the best performance metrics for the WebLogic server instance. This is an important task because it helps you plan for future application adoption rates to provide a scalable environment.

Disaster recovery planning: critical applications should have appropriate disaster-recovery planning. I trust the hot-hot type rather than the Hot-standby (hot backup) redundant environment. What if the backup does not run? How many server instances are sufficient to sustain peak loads in the event of a failure? Detailed information about this must also be noted in the documentation. All this ensures a well-functioning environment in the case of a failure, and the protection of the business is the bottom line.

Unified management: I have seen in some organizations that they use an operations team to manage multiple WebLogic domains. Such an environment is difficult to maintain and manage. Consider scenarios that need to be updated. and monitoring--this is a day-to-day operational task--you must view multiple WebLogic server consoles to gather information. My advice is to create multiple clusters, rather than multiple domains, for similar applications where possible. Clustering provides an inherent level of isolation for applications, which results in fewer domains and more manageable environments.

Operations are process-oriented: the operations of the environment are largely process-oriented and require detailed logging. The error pattern and the correct solution record are a dynamic process. Environment upgrades and patching downtime must meet the business requirements for high availability. The appropriate procedure must be set up for maintenance. You also define the step-by-step escalation process and write to the document. As part of the deployment process, you should also take a domain template to produce consistent domains across different environments.

Provide transparency: A well-managed environment requires an alert mechanism for critical business breaches. In the case of a problem diagnosis, the information in the server log must have a certain degree of transparency. The application must record key information that is useful for problem diagnosis. When diagnosing problems, you can use tools such as splunk to aggregate information from different logs in the server environment. In addition, the expected and actual key technical indicators should also be collected and correlated. For example, during capacity planning, a specific number of concurrent users can be predicted based on business requirements, which may be different from the actual numbers in the production environment. Such technical indicators should be regularly reported to facilitate future environmental tuning.

Conclusion

In this article, I introduce a much simpler way to convert an application residing on WebLogic into an asset in an SOA. In addition, other areas that I have not mentioned (such as databases, external systems) also need to be analyzed and studied. The above concepts can also be applied to these systems. These features are associated with costs, so you must analyze the return on investment (ROI) to achieve them. Finally, you'll get an environment that meets your business and functionality requirements, and you'll be able to implement SOA well. This article does not cover all SOA elements, but it presents a solution to meet certain SOA requirements in a complex weblogic environment.