Layer and Vertical Architecture in Spring

[srcfrguser]

Hello All,
We have multiple applications and libraries. These are developed by multiple teams across the organization. To avoid confusion and to have complete control over dependency we would like to enforce proper vertical slice and layering in the application with the help of Spring.

Our initial sketch looks as follows:
app-UI ---> app2-UI
|
|
V
app-logic ----> app2-logic
|
|
V
integration ----> app2-integration

In app1 we are doing some thing as below:

app-UI:Spring-MVC (war) has spring-mvc-servlet.xml & applicaionContext.xml.

mvc-servlet.xml contains Controller and other web related declaration and etc..
applicationContext.xml has beans declaration specific to web app and reference to logic layer as follows:

<bean id="commons-lib" class="org.springframework.context.support.ClassPathXmlApplicationContext">
		<constructor-arg value="classpath*:/cBeanRefContext.xml" />
	</bean>

logic layer: (packaged as jar) and all beans are declared in cBeanRefContext.xml. This is shared by UI layer and different vertical Apps.
This xml will have all common beans and reference to integration layer as follows:

<!-- load Integration related context file -->
<bean id="commons-lib" class="org.springframework.context.support.ClassPathXmlApplicationContext">
                <constructor-arg>
                    <list>
                           <value>env.xml</value>
                     <list>
                </constructor-arg>
		<constructor-arg value="classpath*:/iBeanRefContext.xml" />
	</bean>

<!-- business logic bean declaration goes here -->
<bean id="loggerInjector" class="com.opsh.common.logging.LoggerInjector" />
<bean id="auditClazz" class="com.opsh.common.auditing.AuditingProxy"/>
<bean id="securityClazz" class="com.opsh.common.security.SecurityProxy"/>

Int-App: packaged as jar and all integration related beans are declared in iBeanRefContext.xml. This contains MDB's web services related to integration to external app and etc.,

This is how we would like to strictly enforce and control the layering and slicing.

The problem we are facing is, when we try to use loggingInjector or any beans from the logic layer in the UI layer, we are getting NullPointerException. However, in the server log we can see that cBeanRefContext.xml is getting loaded and the output is as follows:

 <Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@fd4662: defining beans [loggerInjector,auditClazz,securityClazz]; root of factory hierarchy>

My questions are:
1. Is this the right way of doing?
2. Is this possible at all?.
3. Where is that I am failing or am I doing something wrong here to get Null pointer exception?
4. What is the correct way of loading context files in the spring-mvc.?
Please Help!.

I've just noticed that if I use <import resource="classpath*:/cBeanRefContext.xml"/> in mvc-servlet.xml I don't get any Nullpointer expection and everything works fine. But I think this may not be the right way of doing it? Is that right?

John

[shahnawazshahin]

Hi. Thank you for raising your questions around software architecture.

One advice I can certainly give you is you don't allow your business rules or entities to be accessible from the UI layer. Always define Data Transfer Objects as a means of transferring data between the UI layer and the Business layer. I've seen examples that expose entities to the UI layer. But it is a better design to use DTOs, offering flexibility, security and better decoupling features.

Consider the following:

application (ui, integration) -> service -> domain -> gateway

Further information can be found here. But I'll provide an overview.

The Application layer contains user interface implementations (JSP, controllers, AJAX, etc.). The common pattern to adopt here is the Model-View-Controller pattern.

The Service layer acts as a Facade between the Application and Domain layer. This means that any changes to the Application layer won't affect the Domain layer and vice versa (along with the use of DTOs). It can also handle transactions, exceptions and logging. The Facade pattern is adopted here.

The Domain layer is where the business rules are kept. Objects normally kept here are entities and data transfer objects (DTOs). Work with DTOs to, say, transfer form field data from a web page to the Domain layer ready for processing. The Strategy and Factory patterns are used here, where the Factory pattern is used to instantiate entities to work with.

The Gateway layer is your interface between the application and the external resource (i.e. database, SMTP, MQ, FTP, etc.). Work with entities to retrieve or persist data. DTOs can also be used here acting as MDBs. perhaps you can call these DTOs as MDBs if you like. The Gateway pattern or DAO pattern is used here.

Notice that I've also mentioned "integration" as part of the application layer. This is a (sub)layer used if you want external applications to talk to you rather than you talking to them. This Application Integration layer could be implemented as a web service, for example. You can take a look at an example here (http://forum.springframework.org/sho...75&postcount=4).

The principle behind the above has been adopted from http://martinfowler.com/eaaCatalog/serviceLayer.html (thanks Martin!).

Let us know what you think. We can try and help you with a good layered design.

[uenluena]

For the project i work at the moment i did the following architecture. It's project where we build like 10-15 portlet applications and all of them are using the same architecture.

One of the main constraints was the possibilitiy to allow vertical deployments, which means that each portlet application bundled with the framework must be deployable on its own. Which again means, that we dont want to have a services layer with all the services in one project etc.

What i did was the following structure:

Web
We have mainly Faces portlets where we use the IBM Widget Library for better IDE integration and tools (Rational Application Developer).


Service Layer
All our use case specific rules are in here. This is where we actually do our business. The access to this layer is done over a Business Delegator. As we use spring, we wanted to have a typed access to the service beans from the Page Code of JSF. The lookup goes like:

BeanUtil.getMyServiceBDFactory().createMyServiceB( );

The BeanUtil encapsulates the logic to see if the lookup to the service is done on servlet level/JSF level or portlet level.

DAO Layer
This layer is for our CRUD operations and quiet straight forward. We use iBatis as our ORM choice.

The DAO classes provide DTO's to the service layer and the service layer either gives those DTO's to the Web Layer, when the UI is data centric or a bean that holds the UI-specific data, if there's the need for it.


Each Project has a Web(Portlet)-Project, a Services Project (Service,DAO,Bean and Util classes which are use case specific) and a FrameworkServices project (all common services,dao,util classes)

[srcfrguser]

Thanks for your reply. I understand the layers in general architecture and we try to strictly follow layering.
Things that we are struggling with is, using Spring in layer and vertical architecture.

How do we share ApplicationContext in layering architecture?
How do we initialise and share the application context across vertical architecture?

We are struggling in understanding the Spring classloader hierarchy .

Have you tried this kind before? If so can you share your applicationContext.xml in web layer, middle layer and in the integration layer PLEASE?

[shahnawazshahin]

The way I look at it, if the middle layer and integration layer are separate projects resulting in as individual jar files, and the web layer depends on those two jars then you have the application context within the web layer.

Remember, though it helps to have separate projects for each layer, it is not necessary. You can simply have one project and use packages to separate the layers within. For example:

singleProject.jpg

But of course, if you like you can separate the layers into different layers:

multipleProjects.jpg

[srcfrguser]

Hey,
Thanks for interest on and patients on this. We are using eclipse and idea editors in development. Our projects structure in eclipse looks similar to the one that you shown in the singleProject view.
Now we are getting closer to my original question
Based on the project structure I presume you have applicationContext for each layer for example appContext_gateway.xml, appContext_domain.xml, appContext_service.xml, and appContext_ui.xml.
To maintain this layering during runtime and deployment, I am assuming UI layer will be loading Spring beans only from the service layer which in turn will have reference to domain layer and this in turn will have reference to gateway layer.
So, UI application context will have no clue about either domain / gateway layer.

My question is, how do you load this in the Spring classloader? I am more interested in looking inside appContext.xml. Are you just using <import resource.../> tags in each appContext-xx.xml or some other way?

Am I helping you to understand my question ? or you are still confused and not clear?

Thanks John

[constv]

Take a look at my post in another thread. It touches on the issue you are discussing. I think you guys are getting it wrong since with such packaging your architecture is totally application-centric, not service-oriented. It is a very common mistake, so you are not the only ones.

http://forum.springframework.org/sho...074#post214074

[uenluena]

as i stated in my last line:

"Each Project has a Web(Portlet)-Project, a Services Project (Service,DAO,Bean and Util classes which are use case specific) and a FrameworkServices project (all common services,dao,util classes)"

As you can see services,dao's, beans,utils for a specific use case is bundled in one utility project and can be reused by any kind of plattform, be it a Web Service, be it a batch programm etc.

The wiring of all this services,dao's etc. is done on the "front end" application, as only the "front end" application knows what it needs.

If you want to do a non-application-centric package, you can use the same structure without problems as it encapsulates all the services/dao's/Beans/utilities etc. needed for that

[constv]

as i stated in my last line:

"Each Project has a Web(Portlet)-Project, a Services Project (Service,DAO,Bean and Util classes which are use case specific) and a FrameworkServices project (all common services,dao,util classes)"

As you can see services,dao's, beans,utils for a specific use case is bundled in one utility project and can be reused by any kind of plattform, be it a Web Service, be it a batch programm etc.

The wiring of all this services,dao's etc. is done on the "front end" application, as only the "front end" application knows what it needs.

If you want to do a non-application-centric package, you can use the same structure without problems as it encapsulates all the services/dao's/Beans/utilities etc. needed for that

uenluena,
what you are describing sounds good. I was responding to the other posts (shahnawazshahin and srcfrguser.) Specifically, the illustration with the package structure.

[shahnawazshahin]

Thanks for your feedback constv.

I've had a look at the other thread. I've actually seen a similar package structure to the example that you've provided from the post link (http://forum.springframework.org/sho...074#post214074). This is something I'll definitely keep in mind and update. Perhaps I've oversimplified my examples a bit.

Having a look at the post through, I notice that the pattern showing that if there are n number of Domain objects, then there should be n number of service implementations. I thought a service implementation is course grained by design/nature. For example:

org.myapp.xxx.domain.ordermanagement

Order
LineItem
Product
Supplier

(business rules are kept here and had data access implementations also using Template method, or link to DAOs using Strategy).

(optional manager classes can be used like OrderManager, but would lead to an anaemic design).

org.myapp.xxx.service

OrderManagementService <- defining methods like add lineItem, cancelOrder, etc.

org.myapp.xxx.service.impl

StandardOrderManagementService <- interacts with the domain objects in a work flow manner

Is this no longer the case?

(Btw, what does svcone and svctwo mean?)