I have an requirement as per which I have to call an existing java function which is called from the UI through jsp. Data is provided from a form.
I want to call that function from the java code.
Should I create an API which should be called from the java code, and pass all the parameters required for the java function
OR
create a mock of the form(if its possible) and pass it to jsp.
What is the recommended way?
If your code is within the same Web Application, you may want to get a handle to that JSP via a request dispatcher, then call that with wrapped request/response objects, suitably tweaked to hold just the parameters the JSP needs.
Using HttpClient may lead you to all kinds of issues, as this would go all the way to the network layer (for starters: are you sure that you can connect to your own app from the server? Are you sure you really know the IP/port? Are you sure there's no login or session required? And there's no security filter that makes sure your request comes via the load balancer? And so on on...)
Going with an API (even going to the trouble of having the code exposed as an API with a code change) may look cleaner, though. But then, if you're already using REST or SOAP, then it may not be so difficult.
Related
I have a Liferay instance running on a URL like example.org/app. This instance does have a REST API that would normally be running under example.org/app/o/restpath.
The way the server running this instance is that the frontend is accessible without restrictions from the outside, however the REST API is only accessible from the inside the network under a URL like example.org/rest.
I need to make sure that it is impossible to access the REST API with example.org/app. I should also be impossible to access the frontend with example.org/rest. Does anybody have any suggestions?
There are tons of ways of doing that, the best one will depend on your stack, preferences and abilities.
A reverse proxy is the first that comes to mind, bearing in mind that is is normally better if your app has control of who can access it. So a wrapper or a filter checking who is accessing would help. But even then, is the filter to be put on the main application or on your module? That is an evaluation that needs to come from you.
You can also combine the proxy strategy, with a filter, just in case one day you are tuning up your proxy and let something through. You can also decide change your proxy server too..
Or your company already have a proxy that enables traffic going out, and would be easier if that proxy was to have access...
Your servlet contained might also be able to provide such control, so you do not actually need a proxy.
Although I would feel more comfortable if that kind of feature was in the application layer itself, like a wrapper for your component and that wrapper provides the service, a filter, or even a method in in the entry-point, while the others are just extra and to reduce load.
Some companies have networks devices that go up several layers of the network stack, those have lots of potential to help here too, IDS would be able to provide alarms, triggers and such...
As it stands, one would need more information to help you more, even in what you mean by "ensure" ( how far this assurance need to go, like are you thinking about passwords, certificates, IDS, or a simple approach like the mentioned ones ), but I guess that covers it.
I've used angular js as front end technology and jersey to create web services in JAVA. My certain forms have fields that belongs to different beans. I know it is not good practice to have two resources in single POST request. Another option left is to use #FormParam annotation that requires lots of manual work to cast form fields to java objects. I've gone through both questions below.
JAX-RS Post multiple objects
Passing Two Objects in Rest Api using Jersey
i think ajax is better for you, you can send both POST and GET in the same time
first put the ajax code in jquery function after that get the function on element change or click
http://api.jquery.com/jquery.ajax/
This is more of a design-pattern question.
My client application [implemented and will run both as part of a scheduled batch job as well as a message processing application] makes SOAP over HTTP calls to a third party Engine to get some membership data. Since the underlying binding is done thought JAX-RPC, my SOAP response is eventually converted / copied into the generated client stubs.
Now, my question - Is it better to maintain my own domain objects and copy the data from the response objects of the service or is it OK if I can directly use the stub objects to do other processing!
Any suggestions?
This question is going to be somewhat subjective. I prefer to always translate to my own domain objects in case I ever need to swap out the web service implementation. If they ever change over to RESTful web services or just simply change up their wsdl on a version upgrade, you may be out of luck if you are using the stub classes throughout your application.
There are cons to this practice though:
You will need to maintain a similar set of classes
If the service never changes, you wont see any returns on your effort
You can always change this later if it proves useful
I am working on an application in Java on Google App Engine where we have a concept of RPC, but when should we ideally make use of RPC? The same functionality that I am doing with RPC could be implemented even without it. So in what scenario should ideally RPC be designed.....?
You typically use RPC (or similar) when you need to access a service that is external to the current application.
If you are simply trying to call a method that is part of this application (i.e. in this application's address space) then it is unnecessary ... and wasteful to use RPC.
... when should we ideally make use of RPC?
When you need it, and not when you don't need it.
The same functionality that I am doing with RPC could be implemented even without it.
If the same functionality can be implemented without RPC, then it sounds like you don't need it.
So in what scenario should ideally RPC be designed.....?
When it is needed (see above).
A more instructive answer would be scenarios where there are good reasons to implement different functions of a "system" in different programs running in different address spaces and (typically) on different machines. Good reasons might include such things as:
insulating one part of a system from another
implementing different parts of a system in different languages
interfacing with legacy systems
interfacing with subsystems provided by third party suppliers; e.g. databases
making use of computing resources of other machines
providing redundancy
and so on.
It sounds like you don't need RPC in your application.
RPC is used whenever you need to access data from resources on the server that are not available on the client. For example web services, databases, etc.
RPC is designed for request/response. i.e. you have a self contained request to a service and you expect a response (return value or a success/failure status)
You can use it anywhere you might use a method call except the object you are calling is not local to the current process.
In PHP one is always able to access the current request or response from any part of their code. This concept is fundamental to PHP programming. Request data, response data, session data (etc) are always there!
This does not happen in Java Servlets! In order to have access to the HttpServletRequest, HttpServletResponse, HttpSession (etc) in your code you need to pass them around as function variables. This means that you cannot code a web framework that inherently "knows" about all these and removes the complexity of passing them around.
So, I have devised this solution:
Create anf register a ServletRequestListener.
Upon the requestInitialized event bind the current HttpServletRequest to the JNI context giving in the name of the current Thread (Thread.currentThread().getName());
Upon the requestDestroyed event unbind the above JNI resource to cleanup.
This way one has access to the current request/response from any place of their code, since they are always there in the JNI context and can be retrieved by providing the current thread's name.
All known servlet container implement the single-thread model for each request, so there is no way for the requests to get mixed up (of course one must not forget to clean them up).
Also the JNI resources of each web application are separated by default so there are no concerns of mixing them up or of security issues that could arise from one web application having access to the requests of the others.
Kinda twisted, but nice and simple...
What do you think?
I think some web frameworks (GWT, Axis) already do that, but in a much simpler way: by using a ThreadLocal static variable (or accessible from a singleton). Spring also has this possibility.
I'm not sure it works with all the containers, though. If the container uses non-blocking IO and reuses the same thread to handle multiple requests in parallel, it won't work anymore.
See Get the HttpServletRequest (request) object from Java code for a similar question (and its answers).
If you are worried about different requests getting messed up (and then think about "sub requests" like a model window), perhaps you'd rather think about using Seam? They use an abstraction called a "Session" to handle a LOT of the things that we developers try to hack around with other traditional web technology stacks. Seam is built on JSF just as an fyi. You don't have to use EJB 3 or Hibernate with it, but it does integrate nicely with both of those as well. Something to think about.