Java IoT Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White, Zakia Bouachraoui

Related Topics: Java IoT, Mobile IoT

Java IoT: Article

Java J2EE Lite with Spring Framework

The combined burden of EJBs and coarse-grained component design has given the term test driven design a new meaning

To further drive this point home, let's assume a physical architecture of a J2EE application that uses the EJB approach. (This by no means is the only possible architecture, but it helps make some important points.) Figure 6 shows Web apps and some EJBs collocated on the same physical machine.

Just because Web apps and EJBs are collocated, three of these runtime services are not needed:

  • The remoting of EJBs is not necessary as Web apps will call EJBs locally.
  • Clustering of EJBs is achieved via replica-aware home and remote stubs. Again, since the caller (Web app) and the called object (EJB) are on the same machine, there is not much sense in using cluster-aware stubs. Note that HttpSession replication for making Web apps cluster-aware is still desirable though.
  • Typically, if EJBs are not remoted, then you wouldn't want to impose security restrictions at the EJB tier.
As for the following runtime services:
  • Caching of entity EJBs in the container, on the other hand, is a valuable benefit that may be considered depending on the use case at hand.
  • Transactions are the most commonly used service provided declaratively by the EJB container. Many developers prefer the declarative use of Container Managed Transactions (CMT) over programmatic transaction management.
  • Persistence is now a separate specification from the EJB specification (JSR-220) and therefore, in future, will not be a direct service of the EJB container. However, it is a valuable service that can save development time, and, in some cases perform better.
We see that just collocating causes some of the services provided by the EJB container to become redundant.

Therefore applications designed using EJBs will have to interject a container every time a service is invoked, even if it doesn't need 90% of the services it offers. In addition, it will be designed coarsely with the EJB's remote interface and bandwidth considerations. Compare this with a Spring-based design where the business classes are first designed, unencumbered by EJB technology, using all the power of OO design like inheritance and coding to interfaces. Once the business design is complete, then infrastructure services are applied to them on an as-needed basis.

However, many times collocation is not a good fit. Sometimes, depending on the use case, EJBs become a desired feature. For example, middle-tier bean caching necessitates the use of entity EJBs and clustering at an EJB level necessitates the use of session EJBs. For these and other reasons, let's look at how to access SLSBs from Spring.

Defining StatelessSessionBeans in the BeanFactory
SLSBs are widely used to provide the service façade in business applications. Sometimes it's not advisable to remove all SLSBs in favor of proxied objects. In fact, the non-invasive nature of Spring makes it a good candidate for phasing in its use. For that reason or other legitimate uses of SLSBs (like third-party SLSBs), it's easy to make Spring managed beans and SLSBs coexist in the same application.

In Listing 17 we will see how an SLSB can be wrapped in a Spring-managed bean that can be retrieved from the BeanFactory. In the listing the orderContext.xml file shows how a Spring-supplied class (SimpleRemoteStatelessSessionProxyFactoryBean) is injected with a jndiName and a JNDI location for telling it where a certain EJB lives.

The second point is the businessInterface property into which OrderService interface is injected. This is different from the EJBRemote interface and is just a Java interface that is also implemented by the POJO manager OrderServiceImpl.

Beyond that, it is business as usual. The SLSB can now be accessed just like any other bean managed by the Spring bean factory by using the handle orderServiceEJBProxy.

At this point, we have demonstrated that Spring can easily straddle an application that uses SLSBs at the service layer and service objects built from scratch using Spring.

Accessing the Bean Factory from a Web App
Now that we have defined services in the bean factory, how do we actually access the instance of those services? Spring provides several generic classes to make this task easier.

The ApplicationContext interface is at the root of the hierarchy of several interfaces whose implementers read the BeanFactory (or factories) into objects accessible by clients. The WebApplicationContext is one such interface for accessing the BeanFactory from a Web app, as shown in Listing 18.

First the web.xml of the Web app has the following lines supplied that tell the ServletContext about Spring's bean factory. The ContextLoaderListener loads up the Bean Factory configuration at Web app startup time. Next, the Order.jsp (that lives in the bundled Web app made2order.war) loads up the context from the ServletContext as shown in Listing 19. orderService and myProxiedServiceWithSeveralInterceptors are instances of singleton services that are defined in the BeanFactory.

Similarly, ClassPathXmlApplicationContext(paths) is another helper class that gets services from the BeanFactory as is used in the JUnit test suite's setup() method (see Listing 20). Note that a new BeanFactory can be swapped in at runtime by placing it in the classpath and destroying the current context.

Encouraging good testing practices is one of the value propositions of Spring. IoC is a good mechanism to encourage integration testing, whereas coding to interfaces is really what facilitates Unit testing.

In our example, jdbcOrderDAO can be easily replaced by a hibernateOrderDAO for conducting JUnit integration tests from within Eclipse, for example.

Similarly, instead of using a POJO manager implementation of OrderService, you can just as easily replace the implementation with the OrderEJB (which also implements the OrderService interface).

For unit testing on the other hand, EasyMock has been used. The class OrderServiceUnitTest only tests the service implementation by injecting a mock dao into the service layer. Since OrderDAO is an interface, this is easily achieved by casting the MockControl.getMock() method to return an OrderDAO instance. Then, by injecting the mockDAO to the service (setter injection), we can only test the code in the service. EasyMock uses the concept of recording and playback. The exact calls to the mockDAO are recorded first and then the test case is run. EasyMock asserts whether or not the playback is exactly the same as the one recorded.

For more detailed examples, look at the class OrderServiceUnitTest.java.

Because of the simple nature of this application, it certainly doesn't make it a good candidate for an example of test driven design. However, all else being equal, easily testable code will more be more likely to drive design than code that is hard to test.

Where Do We Go from Here
Spring provides an IoC and AOP-based framework to build infrastructure services. Even though we identified some EJB container-based services that are not needed; sometimes, depending on the use case, those services provide value. In those cases, remoting, security, and persistence can be applied to Spring proxy using the same mechanism that was used by transactions or auditing. This allows for open-ended growth where services are applied on an as-needed basis to certain Spring-managed service beans. The sample application does not show these additional features, however, the interested reader can explore Spring supplied support classes for:

  • Remoting using Caucho's Hessian and Burlap protocols
  • Security using Acegi
  • Persistence using Hibernate
There are several Spring classes for other services, which are not mentioned here.

We have implemented the separation-of-concerns pattern by isolating business code from infrastructure code via method interception and Spring proxies. In addition, using IoC and the convenience of a BeanFactory, we are able to inject different implementations into different service contracts.

By moving to a POJO-based business tier, our design is not encumbered by bandwidth considerations as with EJB design. The design of the applica-tion can be as object-oriented and fine-grained as needed because we are not dealing with issues of multiple inheritance or layering.

We looked at the scalability issues and concluded that we can apply several enterprise-level services on an as-needed basis while still remaining cluster-able at a Web app level.

We looked at testing strategies and showed that coding to interfaces allows for the easy use of third-party testing tools like EasyMock. IoC via interfaces allows for integration testing using a configurable bean factory.

In the end, made2order is easier to maintain because we have removed infrastructure code from our business code. It is easier to test because of ease of configuration using a bean factory approach and coding to interfaces. Last, it performs better compared to an EJB-based solution because we are not interjecting a one-size-fits-all container in our business operations.


More Stories By Pankaj Tandon

Pankaj Tandon is a software engineer at Crowncastle. His interests include object-oriented design and development and architecting the software process using open source technologies. He is a Sun Certified Java developer for the Java 2 platform. He lives in Pittsburgh, PA, plays guitar, and mixes music in his spare time.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Pankaj Tandon 02/21/06 10:38:18 AM EST

I just realized that if you are here then you have already found the online version of the article.. here is the link to the downloadable artifact then..

Click on "Additional Code II" to get the full webapp+ code.

Pankaj Tandon 02/17/06 05:48:23 PM EST

Hi all,
I have received several emails from folks telling me about this snafu on JDJs part.
The link is there burried somewhere in the JDJ labyrinth.
You can get to it and some performance analysis at:

Bob Raker 02/16/06 11:37:12 AM EST

This was a very good article. But, where the hell does one go to download listing 9-20. Thanks.

Rob Moore 02/14/06 12:14:11 PM EST

Is the sample code available?



SYS-CON Brazil News Desk 02/14/06 09:46:50 AM EST

J2EE applications of late have become weight conscious. The combined burden of EJBs and coarse-grained component design has given the term test driven design a new meaning: technology driven design! Fortunately a host of lightweight solutions are emerging, such as PicoContainer, Spring Framework, Hivemind, Hibernate, Castor, and Webwork. In this article I'll discuss my experience with the Spring Framework and how it can be used to make a J2EE application more maintainable, testable, and better performing.

SYS-CON India News Desk 02/13/06 02:55:13 PM EST

J2EE applications of late have become weight conscious. The combined burden of EJBs and coarse-grained component design has given the term test driven design a new meaning: technology driven design! Fortunately a host of lightweight solutions are emerging, such as PicoContainer, Spring Framework, Hivemind, Hibernate, Castor, and Webwork. In this article I'll discuss my experience with the Spring Framework and how it can be used to make a J2EE application more maintainable, testable, and better performing.

IoT & Smart Cities Stories
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
Cloud computing delivers on-demand resources that provide businesses with flexibility and cost-savings. The challenge in moving workloads to the cloud has been the cost and complexity of ensuring the initial and ongoing security and regulatory (PCI, HIPAA, FFIEC) compliance across private and public clouds. Manual security compliance is slow, prone to human error, and represents over 50% of the cost of managing cloud applications. Determining how to automate cloud security compliance is critical...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear these words all day every day... lofty goals but how do we make it real? Add to that, that simply put, people don't like change. But what if we could implement and utilize these enterprise tools in a fast and "Non-Disruptive" way, enabling us to glean insights about our business, identify and reduce exposure, risk and liability, and secure business continuity?
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound e...
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in development and launches of disruptive technologies to create new market opportunities as well as enhance enterprise product portfolios with emerging technologies. His most recent venture was Octoblu, a cross-protocol Internet of Things (IoT) mesh network platform, acquired by Citrix. Prior to co-founding Octoblu, Chris was founder of Nodester, an open-source Node.JS PaaS which was acquired by AppFog and ...
In today's enterprise, digital transformation represents organizational change even more so than technology change, as customer preferences and behavior drive end-to-end transformation across lines of business as well as IT. To capitalize on the ubiquitous disruption driving this transformation, companies must be able to innovate at an increasingly rapid pace.
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
"MobiDev is a Ukraine-based software development company. We do mobile development, and we're specialists in that. But we do full stack software development for entrepreneurs, for emerging companies, and for enterprise ventures," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...