Thinking SOA in a WebLogic Environment

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Suchin Rengan's Blog | December 17, 2005  12:50 PM | Comments (0)

I was working at a client where they had various J2EE applications deployed on WebLogic 8.1 and needed help with transforming their application assets into Service assets for SOA. Also, they were in a very strict timeline, which meant no major rework of application code. During our discussions, questions regarding Web Services were often raised, and I felt it is not uncommon to think Web Services not not just Services as building blocks for SOA. Their concerns were around converting their application components into Web Services, and what implications will it have to their overall environment and operations.

It is not surprising that many think of Web Services to be the building block of a SOA infrastructure. I think it can be one but not necessarily the building block for SOA. I will tell you why and how we can think of application components deployed on WebLogic Server as Services that is part of a SOA.

Applications can be broken down into components that satisfy business functionality. Every application has specific business, functional and operations needs. Functional needs cater to implementation and I am not going to spend much time there since we are talking about applications that are already part of an enterprise that needs to be a member of SOA family. Where we need to focus at this point is how we can associate business needs and provide an easy operating environment for this application.

Many of the business needs fall into meeting SLAs for an application and may have the following requirements:
- Concurrent users
- Response times
- Error rates
- Workload prioritization (breakdown of business functionality in terms of priorities)
- Application adoption rates (roadmap of scaling their applications with respect to number of users)
- Availability

Operational needs pertain to maintaining an infrastructure and may have the following requirements:
- Application monitoring
- Deployment strategy
- Maintenance (patches, upgrades)
- Problem diagnosis

Often times, there are many applications that are deployed to a WebLogic instance and it becomes difficult to associate the above needs to such an environment.

Isolation: Given the above scenario let's see an approach to transform such an environment to be part of a SOA. The first step is to isolate applications or components that are considered critical. Isolation can be provided by either deploying these applications in a separate WebLogic instance and then associate appropriate memory and WebLogic resources to that application. These server instances can then be clustered that helps in a failover situation and thereby makes the environment highly available. Don't forget that higher the business expectation, costlier the infrastructure. If we need to isolate specific components of an application, one can do so with help of Custom Execute Queues or Work Managers (new in 9.0) and configuring them with appropriate thread counts. Creating execute queues helps in providing separate request channels for application components and prevents request starving for critical business functionality. Isolation at Connection Pool level can guarantee availability of database resources.

Server Characteristics: We need to understand the server characteristics in terms of throughput, response under load etc. This is done by load/ stress testing and then tuning the environment to get the best of a WebLogic Server instance. This is a key task as it will help one plan for future application adoption rates, there by providing a scalable environment.

Plan for disaster recovery: Critical applications should have appropriate disaster recovery plan. I also believe in redundant environment that is hot-hot instead of hot-standby. What if standby doesn't work? Detail in terms of how many server instances is sufficient to maintain a peak load in case of failures must also be well documented. All this leads to a good functional environment in case of failures and protecting the business is the bottom line.

Unify manageability: I have seen organizations that they have many WebLogic domains managed by a single operations group. Such an environment is difficult to maintain and manage. Think of a scenario where upgrades need to be done. As well for monitoring which is a daily operation task, one has to look into various WebLogic Server consoles to gather information. What I would suggest is to create multiple clusters instead of multiple domains wherever possible for similar applications. Clusters provide inherent isolation levels to applications which leads to fewer domains and a better manageable environment.

Operation is process oriented: Operating an environment is very much a process oriented that needs to be well documented. Documenting error patterns and appropriate resolution for the same is an on-going process. Environment downtimes for upgrades and patches must adhere to business needs of high availability. Proper procedures must be laid down for maintenance. Escalation procedures should also be defined and documented. Domain templates should be adopted as part of the deployment porcess to have consistent domains across various environments.

Provide Transparency: A well managed environment needs to have alerting mechanisms for critical business violations. Thresholds must be appropriately defined for various environment resources. There must be transparency in terms of information during problem diagnosis in the server logs. Applications must log critical information that may help during problem diagnosis. Tools such as one from Splunk, can be used to federate information from various logs in a server farm during problem diagnosis. Also, critical metrics should be gathered and co-related with respect to expected and actual numbers. For example, during capacity planning, one expects a certain number of concurrent users based on business needs, which may be different from what is actually seen in production. Such metrics should be reported periodically to enable further environment tuning.

Conclusion
Here, I have laid out a very simplified approach of transforming WebLogic hosted applications into assets that can be part of SOA. Undoubtedly, there are other areas like database, external systems etc that I have talked about and needs analysis and research. The above concepts can be applied to such systems as well. These features come with associated cost and one must look into ROI of implementing them. What you get at the end is an environment where you can satisfy the business and operational needs and we are well into accomplishing SOA. I am not saying that I have taken care of all the SOA elements, however, presented a solution to meet some of SOA needs for a complex WebLogic environment.

References

Implementing Execute Threads

Comments