Help !! For a Simple framework
Hi ,
In my J2EE application , we need to contact different 3rd party services(which are stateless session beans) developed by other vendors. As our application is dependent on others , incase they are down or cannot send response to our calls ,we need to show sample test data from an XML file. Now what i need is some idea as where and how to go about it..
To use test data or not use should depend on configurable properties, if the property is true for a service then only should go and read test data else should contact the 3rd party stateless session ejb.
How to define a common tesdata inteface .
Please help me as I am new in this design stuff. Any starting steps will be greatly appriciated.
The test interfaces are already defined for you - the 3rd party session bean remote/local interfaces.
It is pretty trivial to create implementations of those interfaces to return the test data from your XML files.
There are a number of ways to handle the switching, if you have used the service locator pattern, then I would personally slot the logic in to the service locator, to either look up the 3rd party bean or return a POJO test implementation of the interface according to configuration.
Without the service locator, you are forced to do a little more work, you will have to implement your own test session beans to the same interfaces as the 3rd party session beans.
You can then either deploy them instead of the 3rd party beans or you can deploy both the test and the 3rd party beans under different JNDI names,and use ejb-ref tags and allow you to switch between test and real versions by changing the ejb-link value.
Hope this helps.
Bob B.
Hi,
I would use a delegate and a service locator.
The delegates has public methods that you define, and calls the service locator to locate the actual service implementation. Declarative configuration (such as in the deployment descriptor or in a properties file) of your service locator will tell it where to look for the service, either the real third-party service or the mock objects.
This will cleanly decouple your client code from the service implementation.
Bruno