Ashna Open Java Framework ( AOJF )

General Approach
In the following image you can find the deployment view very easily:

Portal
As it clear from above picture, we're going to use the Liferay. For deploying this project we need a server with the following specification:

Web/Application Server
We can have some different web or even application server on it, but we want to use the following items:

Open Sources: Jboss or Tomcat
Business ones: Weblogic or websphere

Portlet Deployment
For each portlet which we will have a WAR file, which deploying it is so easy, in liferay we've set a directory which by default is \home\liferay\deploy\

And the interval is set to 5 seconds, it means that the portlet container after the interval gets to the mentioned directory and then is going to deploy all WAR files which are already there.

Liferay allows you to easily hot deploy layout templates, JSR 168 portlets, and themes. Layout templates allow portlets to be arranged inside the constraints of custom layouts. JSR 168 portlets add functional abilities to the portal. Themes modify the look and feel of the portal. Both can be done at runtime by utilizing the hot deploy features of Liferay. Because there are differences in classloader implementations, order in which WARs are loaded, and other nuances, describing how to hot deploy layout templates, portlets, and themes on Liferay's supported servers can be a difficult task. We hide the differing sets of instructions by utilizing Ant to mitigate this complexity. The following instructions assume you have a basic understanding of setting up Ant and calling Ant targets.

Workload
In this server probably we'll face to load problem too much, because it needs too much bandwidth.

ESB
The primary goal is enable integration between applications using standards, open protocol and well-defined patterns. To achieve this goal, Mule defines a set of components that can be used to perform most of the hard work necessary to get disparate applications and services talking together. We're going to use the MULE as an ESB.

It's a Standards-Based, Fully-Featured ESB
Mule ESB has everything you would expect from a commercial ESB -

Clusterable and fault tolerant application environment
Highly scalable Server supporting massive throughput
Fully transactional including distributed transactions
Secure;Authentication and authorisation
Auditing, and Information tracking Support
On line management, monitoring
Its built on J2EE standards such as JMS, JBI, EJB, Servlets, Web Services and the WS-* specifications. Mule ESB allows you to seamlessly integrate with J2EE components and Application servers from different vendors.

It Reduces Total Cost of Ownership
Mule is open-source and released under a BSD license. This means it can be used in commercial applications without restriction. Up till now there has been high cost of entry into the ESB/SOA market with the big name companies charging exorbitant license fees. With Mule ESB, not only can you try before you buy, but you can go to production without ever paying license fees.

It is Backed by Expert Services and Support
SymphonySoft can provide expert services and support. Our team comprises of industry practitioners and more importantly the authors of Mule. There is no one else better equipped to give you support when you need it.

It Just Works
There are no surprises, no misleading literature, and no lies. Mule ESB does exactly what it proclaims; it provides a robust, secure and scalable messaging and Business process environment.

Its Design is Driven by Demand
Mule ESB was developed by SOA practitioners to fill the void of easy-to-use enterprise messaging. What was produced was ESB for the masses. Being developed it the community, it has been continually exposed to every kind of usage scenario and has evolved according to the needs of its users.

It Facilitates Rapid Development
All ESB systems need to scale up as more applications are weaved into business processes and more load is put on the applications. It is this requirement that makes most ESB systems difficult to work with, which in turn drives up development cost. Mule ESB was designed to scale down as well as up. This promotes a rapid development cycle. At design time developers can produce a fully working system on their laptop. Deploying to a networked environment is just a case of changing some configuration values. Want to cluster the application? Again it’s as simple as changing configuration.

It Protects Existing IT Investment
Mule ESB can seamlessly integrate with you existing EJB applications, Web Services, Mainframe applications, Web applications, Business Processes, Messaging Services and Java applications. Mule ESB uses a zero-intrusion policy whereby your existing services and business logic components can be managed by Mule with modification of any kind. Mule can be hosted by any J2EE application server or can be installed independently.

It Enables Incremental Integration
Incremental Integration is the process of introducing potentially disruptive integration changes to you application infrastructure in smaller, manageable milestones. Mule ESB provides a broad range of integration and process management options and also allows you to switch between different protocols, technologies, message types and deployment topologies through configuration. Mule ESB adapts to your environment rather than defining it meaning it can be introduced in gradual steps.

It is Fully Extensible
We provide many integration options that provide enough breadth of connectivity for many integration projects. However, our simple plug-in model allows you to easily, extend and integrate any application.

It Makes Business Sense
No cost of entry and no license fees, means you can try our software for yourself. You can do this independently or use our mentoring services.

Our rapid development model and broad integration options means that evaluation prototypes can be created in days, not weeks or months. Being Standards based, means you can leverage your existing technology investment. Mule is fully customisable so even the most demanding scanios can be accommodated. Mule ESB is non-disruptive and promotes Incremental Integration to minimize impact on existing systems and allow for more manageable project milestones. Every step of the way SymphonySoft can help you evolve your ESB strategy and provide Reviews, mentoring, performance and security advice.

Workload
It is better that the MULE install on separate server because all of component flows are from this layer. Besides, the mule itself is a server so there's not any essential to install other servers on it. And also we'll use tcp to connect to it.

Business
Application Server
Business logics would be an EJB, but about the version of depends to the following items:

If we use wblogic, then EJB 2.1 will be used.
But the others such as: jboss, Oracle AS, and glassfish would be EJB 3.0

Workload
In this server IO and also process is too high, and definitely RMI and TCP already exist in here.