Spring vs Seam

Asynchronous mailing through Tomcat6 and Seam 2.1.2

This article assumes Seam application is already configured on Tomcat.

Steps to implement Asynchronous mailing

1. Copy following mail related jars from jboss-seam-2.1.2\lib to the projects’ \WEB-INF\lib folder.
   1. Jboss-seam-mail.jar
   2. Mail.jar
   3. Activation.jar
      
2. Copy quartz.jar file from jboss-seam-2.1.2\lib to the projects’ \WEB-INF\lib folder.
   
3. Modify component.xml file is as described in red letters.
   
   <?xml version="1.0" encoding="UTF-8"?>
   <components xmlns="http://jboss.com/products/seam/components%22
   xmlns:core="http://jboss.com/products/seam/core
   xmlns:persistence=”http://jboss.com/products/seam/
   persistence” xmlns:security=http://jboss.com/products/seam/security xmlns:transaction=”http://jboss.com/products/seam/
   transaction”
   xmlns:mail="http://jboss.com/products/seam/mail
   xmlns:async="http://jboss.com/products/seam/async%22
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22
   xsi:schemaLocation=
   "http://jboss.com/products/seam/core http://jboss.com/products/seam/core-2.1.xsd
   http://jboss.com/products/seam/persistence http://jboss.com/products/seam/persistence-2.1.xsd
   http://jboss.com/products/seam/security http://jboss.com/products/seam/security-2.1.xsd
   http://jboss.com/products/seam/transaction http://jboss.com/products/seam/transaction-2.1.xsd
   http://jboss.com/products/seam/components http://jboss.com/products/seam/components-2.1.xsd
   http://jboss.com/products/seam/mail http://jboss.com/products/seam/mail-2.1.xsd
   http://jboss.com/products/seam/async http://jboss.com/products/seam/async-2.1.xsd" >
   <core:manager conversation-timeout="120000"
   concurrent-request-timeout="500"
   conversation-id-parameter="cid"/>
   <persistence:hibernate-session-factory name="hibernateSessionFactory"/>
   <persistence:managed-hibernate-session name="hbSession" session-factory="#{hibernateSessionFactory}"
   auto-create="true"/>
   <security:identity authenticate-method="#{authenticator.authenticate}"/>
   <transaction:hibernate-transaction session="#{hbSession}"/>
   <component name="org.jboss.seam.core.init">
   <property name="debug">true</property>
   </component>
   <mail:mail-session host="smtp.gmail.com" port="587" username="emaill@gmail.com" password="pswd"/>
   <!-- Install the QuartzDispatcher -->
   <async:quartz-dispatcher/>
   </components>
   
   
4. Make sure seam.quartz.property file will be available in WEB-INF\classes folder. To do that you should put this file in projects’ src folder.
   
   Sample seam.quartz.property file:

#===================================

# Configure Main Scheduler Properties

#===================================

org.quartz.scheduler.instanceName Sched1

org.quartz.scheduler.instanceId AUTO

org.quartz.scheduler.rmi.export false

org.quartz.scheduler.rmi.proxy false

#===================================

# Configure ThreadPool

#===================================

org.quartz.threadPool.class org.quartz.simpl.SimpleThreadPool

org.quartz.threadPool.threadCount 3

#===================================

# Configure JobStore

#===================================

org.quartz.jobStore.misfireThreshold 60000

org.quartz.jobStore.class org.quartz.simpl.RAMJobStore


5. Make sure seam.quartz.property file will be available in WEB-INF\classes folder. To do that you should put this file in projects’ src folder.
   

<m:message xmlns="http://www.w3.org/1999/xhtml"

xmlns:m="http://jboss.com/products/seam/mail"

xmlns:s="http://jboss.com/products/seam/taglib">

<m:header name="X-Composed-By" value="xtimes.com"/>

<m:from name="xtimes!" address="members@xtimes.com" />

<m:replyTo address="noreply@xtimes.com"/>

<m:to>#{buysellrent.emailAdd}</m:to>

<m:subject>POST/EDIT/DELETE - #{buysellrent.title}</m:subject>

<m:body type="plain">

<s:div style="notes" styleClass="section">

IMPORTANT - YOU MUST TAKE FURTHER ACTION TO PUBLISH THIS

POST !!!

CLICK ON THE WEB ADDRESS BELOW TO PUBLISH, EDIT, OR DELETE THIS POSTING.

</s:div>

</m:body>

</m:message>


6. Create following asynchronous class to send an email.
   

@Name(“emailService”)

@AutoCreate

public class EmailService {

@Logger

private Log log;

@In(create = true)

private Renderer renderer;

@Asynchronous

public void sendMessage(@Duration long delay, BuySellRent buysellrent) {

log.info("inside send message");

try{

Contexts.getEventContext().set("buysellrent", buysellrent);

log.info("After setting context");

renderer.render("/email/activatead.xhtml");

}catch (Exception e) {

log.error("Error Email Send #0"+e.getMessage());

}}

}

As shown sendMessage method will send email after delaying as per value of “delay” parameter. Also make sure you will set object to the context so that while sending mail seam application can get hold of it and assigned values for required fields.



7. Here is sample BuySellRent class which is used as business object while sending mail.

public class BuySellRent implements java.io.Serializable {

private static final long serialVersionUID = 1L;

private String title;

private String emailAdd;

@Email

@Column(name = "EMAIL_ADD", nullable = false, length = 50)

public String getEmailAdd() {

return this.emailAdd;

}

public void setEmailAdd(String emailAdd) {

this.emailAdd = emailAdd;

}

@Column(name = "TITLE", nullable = false, length = 50)

public String getTitle() {

return this.title;

}

public void setTitle(String title) {

this.title = title;

}

}

Challenges and Trade Offs While Building SOA and WOA

What is SOA?

SOA is not a technology – it is an architecture and strategy.

SOA architecture principles are:
Loose Coupling - Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.
Service Contract - Services adhere to a communication agreement, as defined collectively by one or more service description and related documents.
Autonomy - Services have control over the logic they encapsulate.
Abstraction - Beyond what is described in the service contract, service hide logic from outside world.
Reusability - Services should be developed with the intention of promoting reuse.
Composability - Collections of services can be coordinated and assembled to form composite services.
Statelessness - Services minimize retaining information specific to an activity.
Discoverability - Services can be found and assessed via available discovery mechanism.


What is WOA?

WOA stands for web-oriented architecture. It's the next evolutionary step for SOA, lightweight version of SOA, as WOA is a resource-oriented rather then service-oriented.

WOA is simply a way of implementing SOA by creating services that are RESTful resources, allowing any service or data to be accessed with a URI. It is a solution of the REST style for building Web services based on straight HTTP and XML documents.

According to Gartner vice president Nick Gall:“WOA meant to me was a more Web-centric style of doing Web services: Simpler, less complex, less vendor-driven, just a catch-all for this different style that was emerging.”

Nick simply describes, WOA = SOA + WWW + REST

According to Dana Gardner :“WOA, isn’t an architecture, it’s a webby style of apps and integration, of mashups and open APIs, of using REST and RIA clients, all from a variety of Internet sources.”

Following picture to describe trends adapted by IT industry from 1970 to the near future:

Trade Offs between SOA and WOA?

SOA talks lot about connecting application and database together, while WOA, apart from technology describes opportunity to connect people together and to support their collaborative efforts.

Traditional SOA builds a messaging layer above HTTP using SOAP, while WOA uses Plain Old XML over HTTP (POX/HTTP).

SOA uses WS-Security and another sophisticated standard for security, and WOA uses HTTPS. In the WS-* space a lot of options available for building secure applications, while for WOA security is still a concern as HTTP security relies more on infrastructure and thus not as sophisticated as WS-Security.

WOA uses well-established Web methods (POST, GET, PUT and DELETE) for interacting with services and lessen the dependence on proprietary middleware to coordinate service interaction and shift to common Web infrastructure. In contrarily, SOA development requires good amount of investment from organization to buy middleware products.

SOA uses system-level architectural style (how to implement your service) whereas WOA refers to interface-level architectural style (how to expose those service to users). SOA better suited for system-to-system integration while WOA is for user-to-system integration.

WOA build using light weight scripting vs. SOA requires complex .NET or java programming.
SOA implementation requires XML schema's for service contracts, while WOA just says go ahead and implement the web service in consumer required format.

Common Challenges in building SOA and WOA?

Most of time SOA and WOA development started by consulting company. And consulting company knows about the technology not about the business of the client. Lack of resources from Client Company at early stage lead towards bad architectural decisions and at the same time very few employee of Client Company gets awareness of new technology.

Too volatile requirement creates confusion in development team to define a clear line between current and next iteration and leads for bigger development cycle as well as complex change management system.

In a large organization lack of ownership and accountability from different team will lead for greater development cycle because of unavailability of basic infrastructure, required services etc.

Complexity of SOA (i.e. WS-* architecture) creates need for SOA governance. Without formal SOA governance SOA project can’t be successful. While WOA avoids many of the complexity of SOA, still needs good governance in place.


Conclusion

WOA and SOA are complementary architectural styles. In some cases, a WOA will serve the purpose. In others, architect may need to scale up to a SOA solution.

There is a place for SOA and WOA both, as WOA can be used for simple web based interface. A plethora of WS-* standards exist specifically to address the complexity of enterprise integration and interaction needs.

Though lighter weight WOA looks superior, limitation of no industry standard profiles for complex services in WOA advises not to ignore SOA. There is more work to be done in WOA world to figure out how governance, security, orchestration and others issues look like.

According to Leo Shuster, REST should be used when performance and simplicity are paramount, very less security is required and no complex interaction between consumer and services are necessary. In other cases SOA can be a better choice.

The Right Portal Framework

Consideration:

For any j2ee framework there are three well established industry recognized framework exists. Struts, JSF and Spring.

So which one is right when we go with Portal technology. Let’s compare apples and oranges.


Does Struts Satisfy Needs?

Struts1.x

Pros:

• Struts have been around for a few years and have the edge on maturity. And since it here from many years there are many developers who know struts very well.

Cons:

• It is one of the first MVC framework, and hence very cumbersome and "backward" by today's standards (because of the need to maintain backward compatibility, they can't rearchitect it the way it should be done).
  
• The heart of Struts is the Controller. Struts use the Front Controller Pattern and Command Pattern. A single servlet takes a request, translates HTTP parameters into a Java ActionForm, and passes the ActionForm into a Struts Action class, which is a command. The URI denotes which Action class to go to. The Struts framework has one single event handler for the HTTP request. Once the request is met, the Action returns the result back to the front controller, which then uses it to choose where to navigate next. This structure restricts struts to handle only one event per request.
  
• Struts were designed to be model neutral, so there are no special hooks into a model layer. There are a view reflection-based copy utilities, but that's it. Usually, page data must be moved from an Action Form into another Model input format and requires manual coding. The Action Form class provides an extra layer of tedious coding and state transition.

Struts2.x

• Struts1.x+webwork2 = Struts2.x
  
• It provides some goodies like:
  -Stateful Checkboxes
  -First class AJAX support
  -Easy integration with Spring Framework
  -No More Actions Forms, use POJO forms
  -Easy to Customize Controller
  -Easy Plugins etc. etc.
  
• The major change in Struts 2 might be learning curve for developers.

Does JSF Satisfy Needs?

Pros:

• JSF is an official standard from sun. It is a Specification, hence will have lots of implementations. It is also now part of the J2EE specs. Therefore any vendor that wants to be J2EE compliant is forced to come out with a JSF implementation and provide support for it.
  
• JSF has been designed from the ground up to support Portlets (JSR 168). It just fits into the portal. It is almost like a container agnostic framework. You can write JSF for standard web development and then turn around and put it into a portlet with little if any change.
  
• JSF was built with a component model in mind to allow tool developers to support RAD development. JSF provides the ability to build components from variety of view technologies like Rational Software Developer etc.
  
• JSF uses the Page Controller Pattern. Although there is a single servlet every faces request goes through, the job of the servlet is to receive a faces page with components. It will then fire off events for each component and render the components using a render toolkit. The components can also be bound to data from the model. Thus JSF can have several event handlers on a page and can be hooked into model without breaking model, In short, JSF adds many benefits of FrontController but at the same time gives flexibility of Page Controller.
  
• The new portlet specification JSR286 as opposed to JSR -168, speaks quite a bit on the topic of JSF support. It's just an added bit of confidence that the JSF portlet apps we write now will be very portable in future portal applications servers.
  
• IBM is a pioneer in portlet technology and although they heavily supported struts in their portal, their portal team strongly recommends using JSF instead of struts.

Cons:

• Using JSTL in JSF produces un-specified results. It does not work some times.
  
• There is no apparent support for Portlet Modes or Preferences.

Does Spring Satisfy Needs?

• Spring itself is more than a MVC framework. Spring is made up of many components, main component being the Core Container (Beans, BeanFactory, ApplicationContext, etc) that provide the Dependency injection via a lightweight container, and the rest of the components (e.g. AOP, Transaction Management, etc. ) are built around it.
  
• The idea is that Spring allows you to use what ever you want, to mix and match its components easily. So in effect, you can use Spring to do your Transaction Management and AOP but choose to use Spring MVC, Struts or JSF as your MVC framework.
  
• Spring MVC is again action oriented framework like Struts and unlike JSF and Tapestry.
  
• There is a Spring Portlet Framework available now, which is gaining industry acceptance.

Can we think of Tapestry?

• Tapestry is innovative, and since it is complicated to use. It has a steep learning curve.
  
• JSF and Tapestry have fundamental similarities, but here is a very good discussion of using one over another.

Conclusion:

1. In general, unless there is a compelling need, direct use of portlet API is recommended instead of using any framework. For less complicated portlets can also give a thought of using tools like IBM portlet factory.
   
2. As till today there is no specific portlet framework available, till then a long-term strategy would be to move to JSF as other then all the pros following information also forces to use JSF.
   -JSF has Specification.
   -It is integrated in JEE 5
   
3. At first glance Struts 2 looks promising, but yet not proved as being very new and developers are readily not available.