Category Archives: Spring

Spring Book – Chapter 19 – Tasks and Scheduling

Concurrent programming and management of threads in general are necessary because the world of web programming is essentially concurrent because multiple clients can access in the time. Asynchronous programming promotes using the same thread to process multiple requests, sequentially, but with no request blocking the thread.

Spring has supported task scheduling and asynchronous method execution from its earliest releases. Spring 3.0 has made this easier by allowing you to declaratively do this by using XML and annotation-based programming.

This chapter initially looks into the various concepts dealing with concurrency and then looks into Java support for doing this. Later on it looks into how Spring Framework can support doing this in your application.

Terms and Concepts

The following concepts and terms that will be used throughout the chapter :

  • Concurrency Concurrency is a system property in which several computations are executing simultaneously, and potentially interacting with each other. Concurrency is a built in feature of the Java language and platform.
  • Process A process is a flow sequence that runs independently and isolated from other processes. It cannot have access to data in other processes.
  • Thread A thread is a single, sequential flow of control within a program. A thread can be called as a lightweight process which has access to shared data. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently. Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority. When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread.
  • Task A task is a basic unit of programming. In our sample application, downloading the cargo utilization report of the first hundred customers represents a simple task.
  • Multithreading Multithreading is the ability of a program to manage its use by more than one thread at the same time and to even handle multiple requests, without having to have multiple copies of the program running. Each execution of the program is kept track of as a thread with a separate identity.
  • Multitasking Multitasking is the ability of a program to allow a thread to perform more than one task at a time. The program can keep track of where you are in these tasks and go from one to the other without losing information. Being able to do multitasking doesn’t mean that an unlimited number of tasks can be performed at the same time. Each task consumes system storage and other resources and as more tasks are started, the system may slow down or begin to run out of storage.
  • Serial Processing Serial processing is strictly sequential, without overlap of the successive processing times on objects or distinct subsystems. In a standard type of serial system, each object takes the same average amount of time to process and the next object begins processing only when the previous one is completed.
  • Parallel Processing Parallel processing signifies simultaneous processing on several objects or subsystems at the same time, although processing may finish on different objects at different times. Parallelism is a term typically used to describe executions that physically execute simultaneously with the goal of solving a problem in less time or solving a larger problem in the same time. Parallelism differs from concurrency and actually exploits concurrency. The advantages of parallel processing are faster execution time and higher throughput. The disadvantages are that there are additional hardware and power requirements.
  • Task Scheduling This is another form of concurrency in action, wherein a piece of work can be scheduled to run once or repeatedly at an interval for various application use cases. In our sample application a task schedule can be created for sending periodic mails to the entire customer in the system giving details of their cargo loyalty points.

Note: Scheduling is needed if you want your application to automate the repetition of a task at specific intervals or particular date. In any modern application its common to have scheduling requirements, and the Spring Framework brings a level of abstraction to this as well. Spring has good support for scheduling and, as shown later in this chapter, it also supports using other third party scheduling services, such as Quartz.

  • Liveness Liveness defines a concurrent application’s ability to execute in a timely manner. There are various kinds of liveness problems that can occur in your application, namely deadlock, starvation and livelock.
  • Deadlock An application that allows concurrency is prone to a deadlock condition in which all the threads are waiting for an event that other threads in the same set have to cause. For example, if thread A waits for a lock on object C, which thread B holds, and thread B waits for a lock on object D, which is held by thread A, these two threads are locked and cannot continue further, resulting in deadlock.
  • Starvation Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress by itself. This happens when shared resources are made unavailable for long periods by other “greedy” threads.
  • Livelock A thread often acts in response to the action of another thread. If the other thread’s action is also a response to the action of another thread, then livelock may result. As with deadlock, livelocked threads are unable to make further progress, but unlike deadlock they are not blocked. They are simply too busy responding to each other to resume with their own work.

Currency Support by Java

Concurrency is a built in feature of the Java language and platform. Java has a predefined class java.lang.Thread which provides the mechanism by which threads are created. However to avoid all threads having to be child classes of Thread, it also uses a standard interface java.lang.Runnable. Any class which wishes to express concurrent execution can implement Runnable interface and provide the run method. Threads do not begin their execution until the start method in the Thread class is called. Listing 20-1 shows creating a thread by extending Thread class and Listing 20-2 shows creating of thread by implementing the Runnable interface.

Listing 20-1. Creating thread by extending Thread class

Listing 20-2. Creating thread by implementing Runnable interface

Page Visitors: 24254

Post-Redirect-Get Pattern in Spring MVC

Do you have back button issues? Duplicate form submissions when you click back button? I think you have landed in right blog. With respect to Spring MVC, the blog even tries to give the complete solution by which to handle it.

One of the easiest way by which you can handle these issues is by implementing Post-Redirect-Get (PRG) pattern.

What is Post-Redirect-Get Pattern?

Post/Redirect/Get (PRG) is a web development design pattern that prevents duplicate form submission. When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.

To avoid this problem, PRG pattern is used, instead of returning a web page directly, the POST operation returns a redirection command. The HTTP 1.1 specification introduced the HTTP 303 response code to ensure that in this situation, the web user’s browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted.

I don’t want to re-invent the wheel, so i would just let the reader go through the Wikipedia which has explained it beautifully. Please follow the following URL:

http://en.wikipedia.org/wiki/Post/Redirect/Get

Beautiful well constructed figures in Wikipedia will make you understand this pattern in minutes.

I hope you would now have a clear picture of PRG pattern after going through the above URL and are ready to see this implemented in your Spring MVC application as detailed below in this blog post.

I really don’t know whether this is the best approach by which Post-Redirect-Get pattern can be achieved in Spring MVC. Nevertheless i am sharing an approach below by which PRG pattern can be achieved. If this is not at all right approach, or there is another good way by which to do it, please let me know through your comments to this blog post and i promise to correct it accordingly.

In Spring MVC PRG is implemented by having two request-mappings for each page one for GET and the other for POST. The page should always be rendered using GET method and the form should always use POST method for submitting data to controller. To achieve PRG after submitting the form in the POST method of the request should send the response with redirect to the page, by doing this the page will be rendered using GET request. The following a sample code.

The flow of the above example is {GET(prgTest.html} –> {POST(prgTest.html)} –> {REDIRECT(prgTest.html)} –> {GET(prgTest.html)}

I thank my dear friend Karthikeyan Vaithilingam, for allowing me to print his R&D on this in my blog. Please follow the following link to his other blog entries:

http://seenukarthi.com/blog/index.html

I would also suggest reader to go through another approach as given in the below blog post and implement whichever is the best approach in your web application.

http://www.mkyong.com/spring-mvc/handling-duplicate-form-submission-in-spring-mvc/

If you are using JSF or one its implementations like RichFaces as your choice of web application, to implement PRG, please blog my blog in here.

Page Visitors: 21855

Spring Book – Chapter 17 – Messaging with Spring

Messaging is a method of communication between software components or applications. Messaging enables distributed communication that is “loosely coupled” (decoupled). A component sends a message to a destination, and the recipient can retrieve the message from the destination. The important thing here is that, the sender and the receiver do not have to be available at the same time in order to communicate with each other.

Java Message Service (JMS) defines a standard way for Java applications to create and exchange messages through a Message Oriented Middleware (MOM).

Messaging is one of the key components in any modern day application development. In this Chapter we will initially cover messaging concepts in some detail. Later on we will cover JMS and its components in detail. We will then deep-dive into the support provided by Spring in applying messaging to your application. We will then go through the transaction support by JMS and again what Spring has to offer in this space. Finally, the Chapter concludes with a discussion of Spring’s support in achieving global transactions in your application.

Messaging in General

Messaging systems are used to build highly reliable, scalable, and flexible distributed applications. A messaging system allows separate, uncoupled applications to reliably do the communication asynchronously. The messaging system architecture generally replaces the client/server model with a peer-to-peer relationship between individual components, where each peer can send and receive messages to and from other peers.

Messaging systems provide a host of powerful advantages over other, more conventional distributed computing models. Primarily, they encourage “loose coupling” between message consumers and message producers. Other advantages of messaging systems include high scalability, easy integration with other heterogeneous networks, and reliability due to lack of a single point of failure.

Messaging is another integration style as detailed in Chapter 6.  Systems exchange messages within each other using a component known  as a broker, which provides the necessary guarantee and services while using messaging along with capability of interfacing with other interfaces like JMS driver, AMQP (Advanced Message Queuing Protocol), Stomp (Simple Text Oriented Message Protocol), XMPP (Extensible Messaging and Presence Protocol) etc. These interfaces are often referred to as Message Oriented Middleware (MOM) and are available as commercial and open source products in the market. Figure 18-1 shows a diagram of a MOM-based messaging system.

fig18-01

Figure 18-1. Messaging using MOM

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols, such as the following:

  • Simple (or Streaming) Text Orientated Messaging Protocol (STOMP) provides an interoperable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.
  • Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. It’s a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns.
  • Extensible Messaging and Presence Protocol (XMPP) is an open-standard communications protocol for message-oriented middleware based on XML (Extensible Markup Language). The protocol was originally named Jabber, and was developed by the Jabber open-source community.

Advantages of Messaging

The main advantages of using messaging as an integration technology in your application can be summarized as below:

  • Platform Independence – one of the biggest advantages which messaging integration style brings onto table is communication and integration of heterogeneous platforms. Using messaging it is possible to integrate applications and systems which are implemented in completely different platforms. Even though we have many ways of integrating heterogeneous platforms like RPC-based, common database etc., only messaging truly provides a decoupled way of interaction between such disparate systems.
  • Network location Independence -messaging also provides capability of connections applications and systems in completely different networks with ease.
  • Architecture Flexibility and Agility – this very important advantage of messaging is achieved through level of abstraction and decoupling capabilities. Because of decoupled components, these can be replaced with a more capable component at a later stage with ease giving application flexibility and agility to changing business scenarios. In a typical messaging environment, the various components like producers, consumers and client components doesn’t need to know which programming language or platform these are written for, where they are located and even the protocol they used to communicate. These details are all abstracted away, making it more flexible from the architecture point of view.
  • Reduce system bottleneck – asynchronous nature of messaging is the key in avoiding system bottlenecks. Since messaging architecture gives your application asynchronous nature, your receivers need not keep up with the rate of requests coming in reducing the system bottlenecks. In a synchronous environment, your application would have resulted in system bottlenecks if the number of requests exceeds a particular amount which the consumer can consume and process.

Using traditional RPC-based technologies, there is a synchronous communication between a client and a server component. Also, communication between many to many can over a period of time turn into a mesh of one to one communication between various components as shown in Figure 18-2 below. This meshing can be troublesome from the application maintainability point of view.

Figure 18-2. Traditional RPC-based application component interaction

Figure 18-2. Traditional RPC-based application component interaction

On the other hand using a messaging style of integration allows adding a mediation layer between one or more consumers and one or more producers. This result in clear communication between various components which has a clear interface with other components interacts, making it easy to swap the various components according to application requirement. Figure 18-3 shows message-based component interaction.

Figure 18-3. Using messaging-based application component interaction

Figure 18-3. Using messaging-based application component interaction

Page Visitors: 14545

Web Service Framework Comparison – 2013 – Part II

As promised here is my Part II of the blog. You can find Part I of the blog in here. Also my chapter on Spring WS in my Spring book in here.

The Blog is still under construction but i would like to publish it and then keep on updating with more content. Apologies for incomplete blog post.

Apache CXF

The project is a merger between two open source projects namely Celtix developed by IONA technologies and XFire developed by Codehaus. As you would have already figure why the name CXF – Celtix XFire. Rather than me plagiarizing, I would suggest reading the Wikipedia for more details http://en.wikipedia.org/wiki/Apache_CXF.

Some of the advantages associated with Apache CXF is as follows:-

  • Good cohesive support for the Spring Framework.
  • Good OSGi support (How much this is a valid constraint for the evaluation is questionable, i agree).
  • Good support for more strong web service functionalities like WS-Security, WS-Policy etc. to name a few.
  • It also has a compliant JAX-RS implementation allowing it to expose web service as REST and SOAP based.
  • It also has W3C compliant SOAP/JMS implementation if they are required.
  • Much easier to use and implement.
  • Less verbose when it generates basic classes for WS/WS-Client from the WSDL.
  • More “standards based” API’s. The API’s are slim and trim with good performance and ease of use.
  • Considered more “embeddable” as opposed to other WS frameworks, especially with the Spring Framework.
  • CXF provides support for code first and contract first development, and provides ability to plug-in various flexible binding mechanisms.
  • The front end programming API’s is spectated from the core code making it really flexible.

Some of the disadvantages associated with Apache CXF is as follows:-

  • Doesn’t support Orchestration and WS transactions yet (I really don’t know how relevant this is, i plagiarized it from Ankur Kumar blog, refer reference section of this blog post. As he is well-versed with WS, i think i should believe him. Might be Daniel Kulp will help me with this.)
  • WSDL 2.0 support is not yet there.
  • Again, CXF is very good with SOAP, so for web services based on REST, due to its very good support for SOAP, CXF brings in added weight and complexity (I am expecting Daniel Kulp to help on this as well)

Apache Axis2

As explained earlier is a completely re-written version of the famous Apache Axis SOAP stack. While doing so it has to some extend looked upon various lessons learnt and corrected it. Some of the advantages of using Axis2 are as detailed below:-

  • Good support for more strong web service functionalities like WS-Security, WS-Policy etc. to name a few.
  • Good integration support for binding frameworks like XMLBeans, making it suitable for creating web services having complex schema definitions.
  • Somewhat better integration support with the Spring Framework. More details can be found at http://axis.apache.org/axis2/java/core/docs/spring.html.
  • Considering performance aspects, it performs a bit faster compared to Apache Axis2 due to use of proprietary API’s.
  • Supports bothe Contract-First and Contract-Last approach, which gives good flexibility and choice to the users. This is key to some extend.

Some of the disadvantages attributed to Axis2 are as detailed below:-

  • Lack of cohesive support with JAX-WS. the support is detailed in the following URL: http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html.
  • Again good cohesive support between Axis2 and Spring Framework as opposed to other WS frameworks.
  • Good amount of classes, a bit hard to understand and difficult to refactor in case if it is required.
  • Churns out more proprietary API’s and you as a developer would have to handle these.
  • Quick turnaround with fixes and releases. You could read Part I of this blog which compared these aspects in detail.
  • Slowly Apache is phasing out Axis2 in favour of Apache CXF (Please dont quote me on this, but this is slowly happening)
  • It’s a web application by its own with all the services deployed in WEB-INF/services folder as AAR (Axis 2 Archives). This structure as a whole can be problematic while deploying, maintaining, upgrading, versioning and testing to a greater extend.

Spring WS

Some of the advantages associated with Spring WS is as follows:-

  • Full support of the Spring programming model and this can be a very good advantage to take this framework on. The Spring Framework is leading the Java web framework race, now almost single handedly and this advantage is key according to me.
  • Clean API’s (same as above because Spring having clean API’s has influenced this to a larger extend)
  • Clean mapping of the incoming SOAP messages to the methods
  • If your web application framework is based on Spring MVC, Spring WS gives easy and clean mixing between WS endpoints and Spring MVC’s controllers. Also coding of endpoints is as easy as coding a new controller in Spring MVC.
  • Easy unit/integration testing capabilities.
  • Support for different XML marshallers.
  • No generated code/deployment descriptors.

Some of the disadvantages associated with Spring WS is as follows:-

  • Supports only Contract-First approach, which could result in lack of flexibility to the users.
  • Most of WS-* support might be questionable. By the way how much of WS-* things we use?

Technologies grow faster and with open community development, issues identified gets fixed quickly. Having said that, there is an article which i would like to share; http://www.ibm.com/developerworks/java/library/j-jws19/index.html; which rates Apache CXF more as compared with Apache Axis2 in security aspects. Many issues identified would have got corrected over the period of 3 years, but its worth noting these.

Although my comparison is not that well structured, i found a blog released on the same day as i was typing mine, which details the set of criteria which should be used for evaluating the web service frameworks. If i have to do this extensive comparison, it would take me at least 3 months. Since i don’t have much time at this point, i still don’t want the reader not to see these evaluation criteria, which is well structured and though through:

http://naveenbalani.com/index.php/2010/05/evaluating-web-service-frameworks/

Things which I think (Purely my own)

  • For almost 80% of the projects the capabilities required can be covered in a good way by using either Apache CXF or Apache Axis2. If already you application is based on Spring Framework, I would suggest using Apache CXF along with Spring Framework OR using Spring WS with use of CXF as the web service engine.
  • Spring WS similar to the Spring programming model has good and clean API’s, making it easy for developers (juniors) to code web services in Spring WS fast and easy. If you would like more standards, i think Apache CXF is a good choice over Apache Axis2. Again Apache Axis2 is slowly getting itself eaten up by Apache CXF. Fro an enterprise application point of view longevity and community support id required and here CXF scores well compared to Axis2.

Spring WS > Apache CXF > Apache Axis2

I cannot really say that Spring WS is above Apache CXF, because they are very very good fraewmorks. According to your application requirement, i would suggest using either Spring WS or Apache CXF.

Finally to finish off the blog, i would again like to share a picture, which gives Google Search Trends for these Web Service Frameworks in the year 2013 – WorldWide. How much it gives an edge to Apache CXF is questionable, nevertheless gives an indication as to what people are looking for in Google with regards to these frameworks and which is more active.

GoogleTrendsWSFrameworks

There is a beautiful page maintained in Apache which compares the various WS frameworks as a whole. The page is edit last in the year 2011, but I felt the page is a good share in my blog (note Spring WS is missing in the list because it is not an Apache project).

http://wiki.apache.org/ws/StackComparison

References

Page Visitors: 6560

Web Service Framework Comparison – 2013 – Part I

I have done a similar blog post earlier, namely Spring Integration Vs. Apache Camel, surprisingly it received good review from the community and i thought i will do a similar exercise on one of the other big topic of comparison these days, Web Services Framework.

I have a Spring Book Chapter in Spring Web Service, which you can find in my Spring Book, Chapter 16.

Again, i am not biased on selecting any of the frameworks. The view expressed are solely mine. To be honest i don’t have a great deal of experience in the field of web services, but again as part of one of my projects i came into a scenario where i have to select on these frameworks and i thoughts to share the details that i collected. Again, i don’t want to give a verdict, as i don’t consider myself capable of doing so. Just so that anyone in situation can go through the blog and get details, compile it, present it to the team and based on it take the final decision for your project.

Also i have taken three web service framework, which i felt was top in the industry as of now. If anyone disagrees, please feel free to comment on the blog and looking at its relevance i will correct it, as i don’t want this blog to a misleading one for the community as a whole.

Apache CXF

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.

– http://cxf.apache.org

Axis2

Apache Axis2™ is a Web Services / SOAP / WSDL engine, the successor to the widely used Apache Axis SOAP stack. There are two implementations of the Apache Axis2 Web services engine – Apache Axis2/Java and Apache Axis2/C.

– http://axis.apache.org

Spring WS

Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.

– http://static.springsource.org/spring-ws/sites/2.0

Comparison from ohloh.net for the two projects:-

WebServiceComparison1

WebServiceComparison2

I think the comparison figure that is shown above doesn’t convey the exact comparison that we expect. Just by looking the figure above, Spring WS scores very low and can be taken out immediately from comparison. BUT that’s not the case IMHO. Lets get dirty and try the various comparison in some detail.

This is something new in this post, job trends on these technologies from indeed.com is as shown below. What it shows? It might not be relevant, but it shows what companies are looking at hiring when it comes to these technologies. It might be misleading but it shows that what companies are thinking and which technology is popular in various organization’s mind.

JobTrend

JobTrend1

The above comparison figure on the various web service framework’s job opening’s doesnt really give any technical comparison between them but is a good to know fact. It also gives some trends followed by various companies.

Note:- Spring Web Service project was added by me in ohloh.net, solely for comparison perspective. The code location was already added in the main Spring Framework project. If anyone feels that this is not the right way, please feel free to send me a comment and i will do the needful. Also, if it is violating any of the legal terms doing so, please don’t sue me.. :). If given proper directions, i will correct it as early as possible.

In Part II of the post, i will be covering the comparison of these frameworks in detail, looking at various aspects and trying to get some conclusion as to which framework has an edge over the other and what is the reason for me to think so.

Let me have my short and sweet weekend and by next week you can read my blog post, which will be more useful and informative.

 

Page Visitors: 1392

Spring and Hibernate Example

The beauty of Spring is that it can integrates well with most of the prevailing popular technologies, and in the case of ORM, it integrates well with Hibernate.

I have written a Spring Book and in Chapter 8 i explain Spring’s Data Access capabilities in detail. There is separate topics written on ORM integration and this specific heading namely “Spring and Hibernate” is dedicated for explaining this beautiful integration between two open-source framework.

Please visit Page 9 in Chapter 8 of my Spring Book for more details on the same.

This section of the chapter examines the means by which Spring can be integrated with Hibernate. I assume that the reader is somewhat familiar with Hibernate and by reading this far familiar with Spring Framework as well to some extend.

ORM is a piece of software/product for the representation and conversion of data between the database and the object-oriented programming language. Hibernate is a powerful technology for persisting data and is a clear winner in the ORM race as of now. However it hasn’t become a standard. It takes much of the database related boiler-plate code from the developers, thereby asking the developers to concentrate on the core business logic of the application and not with the error-prone SQL syntax. It also enables application to access data from any database in a platform-independent manner.

One of the problems with using Hibernate is that the client Application that accesses the database using Hibernate Framework has to depend on the Hibernate APIs. These objects will continue to get scattered across the code throughout the Application. Above all, the application code has to manually maintain and manage these objects. Here comes Spring to the rescue with its IoC container capable of configuring these objects using Spring configurations.

 

Page Visitors: 526

Spring Book – Chapter 18 – Remoting

Fundamentally Spring remoting is a Remote Procedure Call (RPC) feature which uses a communication protocol like RMI, HTTP or JMS, to inter-operate across multiple JVM’s. The plumbing involved in actually talking to one another using these protocols and other complexities are hidden away from the developer by employing a proxy object created by Spring.

In this Chapter, we will first go through the basic concepts in remoting and then go on to the support provided by Spring. We will then go on in detail to cover the various remoting technologies which Spring supports in detail.

Basic Concepts

This section provides standard definitions for the basic concepts and terminologies that will be used throughout to explain Spring remoting in detail.

Remote Procedure Call (RPC)

A remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

– wikipedia.org

Remote Method Invocation (RMI)

Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines*, possibly on different hosts. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.

– oracle.com

Proxy Pattern

Proxy patterns are key for gaining an understanding of Spring remoting. Figure 19-1 shows the UML diagram for the proxy software design pattern.

Figure 19-1. UML diagram of proxy software design pattern

Figure 19-1. UML diagram of proxy software design pattern

In simple terms, a Proxy object is one through which we control access to the actual object on which the functionality lies. Based on the context in which these proxy objects are used, it can be categorized into three types:

  • Virtual Proxy – If you would like to control the creation of resource intensive objects in a lazy fashion (objects will be created only when the application actually uses it for the first time to do something), the heavy objects can be put inside the proxy objects and its creation can be controlled according to the requirement of your application.
  • Remote Proxy – Used to mask the complexity in communication mechanism between remote objects. Spring remoting uses this type of proxy for abstraction.
  • Access Proxy – Used to control the access to a sensitive object by wrapping it with a proxy.
  • Smart Proxy – If you would like to provide additional functionality to the existing object, smart proxies can be created to address this in your application.

The Proxy pattern is one of the most important design patterns because it provides an alternative to extending functionality in Java using inheritance. Another alternative is object composition, where an object (proxy, now you know) forwards method calls to an enclosed object (real subject).

Problems Faced Today

Most of the remoting mechanisms provide a layer of abstraction over the transport details used for communication in a distributed environment. This locks your code to a particular programming model. In present day of application development, locking to any model is not considered a right approach especially with frameworks like Spring being around which allows non-locking integration with other third party technologies and programming models.

In the case of using Java RMI (Remote Method Invocation), your service interface has to extend the java.rmi.Remote interface and your client is forced to catch the java.rmi.RemoteException exception class. This dependency of your code to Java RMI makes your code tightly couple with this programming model. It not only locks you in, but also clutters your business logic with the remoting infrastructure hurting the principle of separation of concerns.

Any enterprise application normally will be using many applications and services that function on different platforms. When the need arise for sharing the data or functions between these existing applications, the need for remoting could arise.

Integration will remain a high priority in coming years, according to Forrester analyst Ken Vollmer, as virtually all enterprise application delivery projects require significant integration among applications, internal data sources, external trading partners, and more and more frequently, external data resources.

To answer these challenges, the main goals on which Spring Remoting was built and the advantages it brings can be summarized as below:

  • Hide plumbing code as much as possible through abstraction—Spring Remoting hides a lot of plumbing code from the developer by the use of service providers in the server side and client proxy in the client side. Due to this the code becomes cleaner and more maintainable in the longer run. Clear separation of concerns and avoiding tangling and scattering of code.
  • Remoting capability by configuring and exposing services declaratively—Spring’s abstraction uses the configuration based approach for remoting. On the server side no code change is required at all and you have the power of exposing your existing services as remote services with ease. In the client side expose remote methods from existing code. You can then use Spring’s dependency injection to wire various objects into your remote objet with ease.
  • Support for multiple protocols and handling exceptions in  a consistent way—Spring offers a consistent way of writing service exporters, and client FactoryBeans for various protocols represents the same approach and is also consistent across. It provides consistency and ease of adoption as the overall flow remains the same irrespective of remoting technology. In addition, due to this consistency, on the server side ,you have the provision of exposing the services using various protocols declaratively. In the client side it brings in easy swapping of various available protocols according to infrastructure and other considerations. It is also easy to switch between remote and local deployment by mere configuration change which is very handy during testing and actual deployment phase.

In the following sections, we will see whether Spring Framework was able to deliver their goals and in what way they allow extension to it following the Spring philosophy.

Page Visitors: 3856