I have a problem with web services. They are programed in Java and are running on a WASCE server ( both are on the same server).
My problem that i want to solve:
We have two Web services: App1 and App2
In App1 i want to call a function that is in App2. How can i do this? Is this even possible?
I tried creating a soapClient inside the App1 so i can connect to the App2 but that doesn't work.
exp:
I have a client that calls app1 gets data from app1 and send it to app2 then get back the response data from app2 and send it to an other function into the app1.
What i want to do is to skip the client part and do it directly so that app1 can send directly the data to the app2 and then receive an answer do whatever it needs to do.
For the note: Both of the web services use the connection to the database.
Thank you in advance.
(it has been edited with additional data)
What does "doesn't work" mean? Exactly what happens?
Start by generating some client code for App2. Can you use that from some simple Java environment, or say a Servlet. If that works, what happens when you try to call it from inside your App 1 Service implementation code?
However: if these are related services running in the same JVM can you not set up some simpler relationship using java libraries. My preferred way of developing a service is first to develop some useful Java code, and make sure that works, then "wrap" it as a Web Service. In which case I have a callable routine that can just be invoked as Java.
It's definitely possible, with differing levels of complexity and feasibility depending on exactly what it is you want, and the restrictions you place on it.
Probably one of the simplest ways to go about this, if you don't have a problem with the method in App2 being public, is to simply create a web service exposing that method and call if from App1.
If you want App2's method to be essentially "protected", so that it can be called by App1 but not by public clients, then there are several alternative options. Firstly, you could use firewalls or equivalent to prevent external requests to the service URL. Alternatively, you could expose the method through some form of interprocess communication; RMI would be the obvious native one for Java (set up an RMI method in App2 and export this through a manager, then obtain the reference in App1 and invoke the method remotely). Depending on exactly what it is you want to do, you may be better off with a framework that does all this under the covers; e.g. distributed objects through something like Terracotta.
You should give more detail in your question, though - currently the only thing you've really specified is that you want to call "a function" in App2 from App1. There are dozens (if not hundreds) of ways to go about this and the best one(s) will depend on the details of what you're trying to do.
EDIT (in light of comments): It's not the details of what you want to do that are lacking - I understand fine that you want to call some method in App2 from within App1. It's more the architectural details - what languages are both clients coded in, what libraries are you using to do the web services, are both clients on the same machine or separate ones (and if same machine, same JVM or not), are there any firewall issues that could inhibit certain kinds of connectivity, are there any office-political restrictions that could inhibit your options, are there any security restrictions that could do the same (such as whether you can expose the functionality of App2's method publically or not). All of these will shape what is possible and what is optimal - because at the end of the day, all networking is basically I want to use resources on that remote computer from here. Without more architectural specifics, there are literally dozens of ways that you could achieve this.
Regarding exposition: You would create a web service to expose App2's function in the same way you would create any other web service (with the details being dependent on the tool/framework you're using). As an example if you're using a tool that supports the JSR-181 annotations, you'd write a method in App2 that performs this function, and annotate it with #WebMethod. Then you'd ensure that if this method is not part of an existing webservice class you'd annotate its class with #WebService. I was presuming that since you already have a couple of web services, you'd know how to write/define them.
As for accessing the web service from App1, this can be done quite simply by a Java SOAP client. A tool such as WSDL2Java can create a stub class modelling the remote service that you can call; alternatively you can get a richer interface with something like CXF.
What WS library are you using currently, and what errors have you encountered when trying to use it to perform this interaction?
Related
I am currently implementing a small application A. This application A gets some objects from users and will do some preprocessing, before it passes these objects into a different web application B, which finally will store information of these objects.
Now to the question: What are possible approaches to call application B from application A? And which one is the most efficient (in terms of run-time speed)?
This call is one-way, possibly can be done asynchronous and always will happen in the same tomcat server.
The best approach is to change it in terms of architecture: Monolith vs Microservice.
You can expose REST, WSDL (soap) services in both applications to the others also externally.
In generall REST is less standardized than SOAP, also WSDL requires such contract installment
REST is protocol independent, can use any protocol for which there is an standardized URI scheme
Use an in-memory message queue such as ZeroMQ which provides fast asyncronous communication, constantly open connections (avoiding connect delays that REST would have) and plenty of other things.
I have a requirement, where a front-end application (written in spring MVC) needs to communicate with another backend application. Both the applications are going to be WAR running within the same tomcat instance. For understanding purpose, lets name it frontend.war and backend.war.
I have gone through many posts across various forum, and found many different strategies, some of them are as below:
1) Using EJB - Ruled out, EJB's are maintenance overhead and we have no plan to create a dedicated EAR to accomplish this; because we have plan to add more different forntend wars (application modules) which will communicate to same backend.war.
2) Using JNDI : Looks promising, but it needs to have one war to know about the 'interface' being exposed by 2nd war, its signature. So, it is making it tightly coupled with each other. Future change in the service contract can become nightmare.
3) Using REST API : This looks an ideal approach, with only one caveat that the communication is over HTTP call, hence it could be slow.
Other approaches like common parentContext (in Spring). ContextSwitching within application does have their own issues.
I am getting inclined to use REST API approach for this solution; as it is cleaner and easy to maintain. Further the http protocol is mature and has lots of know-how available for future development.
My query:
A) Is it possible to make a tomcat aware that a particular webservice call is indeed a call on the application running same JVM/Server (kind of 'internal'); rather than an 'external' webservice call?
B) If I use url like 'http://localhost:8080/rest/...' (note that backend.war is not intended for external world, so a domain name is not needed) ; will it do the trick?
I am looking for an approach, which gives me performance of JNDI (communication within same JVM) and flexibility of REST (You can change anything, anytime as long as public URLs are intact).
If you have thousand of war, maybe try the Enterprise service bus approach. WSO2 would be a good candidate. You could always change your entry point definition while keeping the backend intact.
Added benefit: your war can be deployed on multiple server and / or moved, but you keep only an entry point; only one address to change.
Create a jar file of the common functions, package them up as a dependcy to both projects - a service layer !
Alternatively, use rest and stick on different tomcat instances/servers - microservices!
I would use any "remote invocation" approach like Java RMI or CORBA. The latter applies also outside the Java world. Those have some benefits over others: they use TCP but not HTTP, therefore are lighter, serialize objects instead of creating new objects (like json or others). Additionally, I think RMI is simple to understand and use quickly.
I'm experimenting with grails in order to interface with an online trading platform.
specifically Interactive Brokers (IB) http://interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
The way the API works is you need to have their client program, Trader Workstation (TWS http://interactivebrokers.com/en/p.php?f=tws&ib_entity=llc) running and then we consume the API to do stuff. Consuming the API basically involves creating a "broker" object, calling a connect() member function (this makes a local port connection to the TWS software) and calling something like getData()
The value of grails in this scenario are the GORM features and the web framework provided. I want to be able to define objects abstracted from db implementation, easily do persistance operations and easily provide users with a UI to do CRUD and custom actions.
My challenge is the IB API uses asynchronous communication for requests and replies. i.e. when i call getData(), the API knows to use the callback function dataResults() when it is ready to send them. In order for dataResults() to be callable, the broker object I created still needs to be around to receive the reply.
Inside a controller function, if i create a broker object and call getData(), when the request finishes, the broker object obviously also disappears. So I'll never be able to receive the reply.
I think there might be some way to do this by kicking off background threads but i'm not sure this is the path i want to go down.
Does anyone have any recommendations on what the best approach is?
I'm not married to grails, the reasons i'm using it are above. If there is a desktop app framework that I can also easily make a web interface on top of later, I'm definitely open to that.
thanks in advance.
Create your object in Service and make the Service singleton (which is by default):
static scope = "singleton"
In terms of web UI Grails is definitely a good choice.
Then, the asynchronous operations could be handled by Ajax calls as you shouldn't block the controller waiting for results.
The following [presentation][1] has some good examples
1: http://skillsmatter.com/podcast/java-jee/high-volume-scalable-ajax-with-grails
I know 'normal' Java, but am new to the world of servlets, containers etc. Because of that I am not sure which approach is most sensible.
Situation: I have created a Servlet that receives information and stores it in a database. This database gets read by other applications.
Now what I need is an application that receives the exact same information and stores it in the same database. However this new application needs to pull this information from another server (I'll be using httpClient for this) instead of it being pushed to it. Both applications will co-exist.
For this new applications I see the following two options:
Make a stand alone application. For this I can copy paste a lot of the existing back-end code, but I will need to make some modifications (the servlet container offers a context, easy database connection pooling etc.) Further I might need to use some wrapper so this can work like a proper daemon that I can start, but also gracefully stop/restart etc.
Make the new application part of a Servlet. That is: just start a new Thread in the init() of the servlet that will run the new application. This would allow me to reuse all the backend code I already have, without needing to rewrite any of it. I only need to write the code that does the HTTP-GET requests to the other server. With this approach it will also be easier to start and stop the service, because I can use the Servlet container for that.
Some info about the project: the backend code that parses and writes the data to the database has a few threads, but is not very complicated. Writing the code for the original servlet was about one week of work. With the existing code base I feel this new application should probably be 1, 2 days of work max.
The way I see it option 2 is easier. But it feels a bit like I would 'abuse' servlets.
So my question is: Aren't servlets for applications that should handle requests, instead of applications that make request? Are there some huge drawbacks I don't see here? Which option would make most sense?
tl;dr: Can I write an application that doesn't serve requests as a Servlet?
Don't copy and paste code.
Write a re-usable class/module which handles storing the information in the database which can be used by both 1) the servlet and 2) standalone code which retrieves information from a HttpClient.
This way the same piece of code handles the same logic - how to store the information in the database - whether the information in question is being pushed to a servlet or being fetched from a remote URL.
Servlet containers are thread-managed environments. In general, don't start your own threads in a servlet, or bad things can happen... starting and stopping the application context, for example - the appserver doesn't know about the threads you might have started so won't stop them with your app... (More detail in this SO question)
I would try to extract the logic I need from the servlet into classes that don't depend on the Servlet API, and redesign the servlet to make use of these classes. (Refactoring). The servlet API, as you note, is all about receiving requests and sending responses.
I can re-use the logic in my new non-servlet classes anywhere I like, including a non-servlet part of the application that polls out pull that info.
You could use, but you shouldn't, it is a very poor design.
If you have two different ways to access your application (one through servlets and other as standalone), you should create at leats three classes:
One class that does all the work relating database, etc.
One servlet that calls the first class
One stand alone class (or whatever) that calls the first class
In this way, you don't copy/paste, and you can reuse your code (even you can have a third way to call the class that do the heavy work
If you want to reuse code, have this code as part of a "Service" or "Business Logic" layer that will be used both by your servlet and non servlet application.
Package the code as a jar and use it in both applications.
We're building some Java objects that are exposed via BlazeDS to our flex client application. So basically the BlazeDS messagebroker servlet instantiates and invokes methods on these objects in response to client requests. Works great.
We're using app server-based authentication and have set up a security constraint on the <destination> elements in the remoting-config.xml file element to prevent unauthenticated clients from being able to access these remote java objects. Again, works fine.
However, there are several places within the implementation of these java objects where we want to get the currently logged on user's username. Right now we are doing this via FlexContext.getUserPrincipal(), which gives access to this but we have a nagging concern that we don't like the idea that the implementation of these objects (the service layer) has a hard dependency on a BlazeDS class. But we're not sure how else to get access to this. The same applies to accessing the ServletContext and such.
Any ideas?
There isn't a way around this when using BlazeDS's MessageBrokerServlet. The only option I can think of is to write your own servlet that does AMF, like this one.