I have a simple Java application (Not a web application) and using maven I distribute it through a Jar file. I need to expose some of its public methods through HTTP(Similar to rest APIs) so that other applications can reuse it by making rest calls.
Doing some research I see for example, Jersey is an option but that seems to be only available for Java Web applications. I also came across HTTPComponents + HTTPClient but the code is much more complicated than how Jersey is.
My question is whether there is a simple solution for Java applications to expose public methods through HTTP.
Thank you,
Sara
Please refer to the comments for the answer. Multiple Web technologies were suggested and seems like I have to convert the project to Web based application if we'd like to distribute as rest APIs and otherwise, if user agrees just use the Jar and Java APIs. Thanks.
Related
I just develop a tool with my classmates and we want to use Vue.js as Web interface.
For Description what we programmed. We developed a Java EE web application in Eclipse. We use Tomcat 7 as web server. I search a long time and i found nothing.
Vue.js is a javascript front-end framework. There is nothing to stop you from using that with a middle-layer/back-end technology like Java EE.
In your HTML pages(or JSP) just include the Vue.js file as mentioned in the documentation, and other .js files that you create as part of your vue.js frontend application.
The library can then interface with any HTTP-based backend methods that you expose (using Servlets, Controllers, etc.) depending on how your Java EE project is structured and what frameworks it uses.
While investigating the same question, I found this good blog that has a git repository too
https://blog.codecentric.de/en/2018/04/spring-boot-vuejs/
From a glance it looks like a read solid implementation, however it has some sticky setup i haven't come across before.
It dose however seem like a professional and scalable solution i will definitely
give a try.
https://github.com/jonashackt/spring-boot-vuejs
Thankyou 04/24/18 by Jonas Hecht
For sure you can.
Your java application, which is your "backend", has to expose its functionalities as Web services (REST Json WS should be the easiest for what you are trying to do).
To expose your services as Web services, you need to find the easiest framework fitting your need. You will probably need to dive into Maven if you haven't yet, because these frameworks tend to have tons of dependencies.
Your Vue.js interface will make calls to the backend via HTTP requests each time necessary (get a resource, update a resource, ...).
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
As per my knowledge api and web services are used to fetch data from other websites.
So what's difference between them ?
Any Help!
EDIT
Can somebody please explain it with proper example ?
What is twitter and facebook api ? Can we say it's just a function or webservices to access their data.
A web service is just an API in HTTP clothing.
A web service is something delivered over the Internet for direct use by another computer (rather than a human).
An API is an Application Programming Interface. A website application might expose an API thorugh a web service. However, desktop applications like Excel or Word have APIs which have nothing to do with the web (they have VBA and COM based APIs).
Simlarly, a server application (eg. Joomla) might have a PHP based API that is used from withinthe server - ie. no web service necessarily involved.
All web services are APIs, but not all APIs are web services. One is a subset of the other.
Web Service is an API wrapped in HTTP.
All Web Services are API but APIs are not Web Services.
Web Service might not perform all the operations that an API would perform.
A Web Service needs a network while an API doesn't need a network for its operation.
An API doesn't need to be web based.
Web Services may also may not perform all of the operations one would expect from a full API.
API (application programming interface) is a list of methods and classes exposed by a programmer to use by other programmers, so eg if you use Twitter or Facebook API in your programs, you can make it cooperate with Twitter and Facebook, and do many useful things. :-)
There are many ways of exposing APIs (JAR files or RMI in Java, .net Assemblies, COM objects, DLL and .H files in C/C++, JSON over HTTP, XML over HTTP, many home-made methods).
Web Services are just yet another way of exposing API, in this case the actual execution of the exposed methods is done not on your computer, but on some other computer on the Internet (on the Web - hence name "WebServices").
A web service can be thought of as a type of API. But for the moment, you should forget that, and just concentrate on learning what an API actually is; a precise definition of methods for interacting with a piece of software. Sometimes, this involved sending data over a network, but usually we're talking about functions that may be called from a program.
For example, there's a function called FileUtils.rm in Ruby. This is the API; when you're calling the function from a Ruby script, it always looks the same. Then there's the implementation of the API; that's the code that actually removes the file - it might look completely different in every implementation of Ruby, but you (normally) don't care about that, since you're only dealing with the Ruby API.
Webservices available over internet.you can get information without actually having the classes or know how it works using http and soap protocols.
API is a kind of library (set of classes), you can use the functions available in that to perform some action in your application.
Check out the wikipedia entry on web API's at http://en.wikipedia.org/wiki/Api#Web_APIs.
It's well written, though pretty much agrees with what the others here say.
APIs exposed over web are Webservices
How can I interop easily between WCF and a Java app.?
WCF is a web service framework. Java also provides its own web service frameworks. They should be able to interoperate quite easily, although you'll need to ask a much more specific question if you want a better answer.
edit: The ProjectTango link you ask about says it all in the first paragraph:
... to ensure interoperability of
enterprise features, such as security,
reliable messaging, and atomic
transactions.
These are fancy additions to basic web services, and the specifications alone are not enough to ensure compatibility.
Basic web service interaction, which is all 99.9% of us ever need, will work just fine between WCF and Java.
Short Answer, Yes.
Long Answer, the interoperability depends on several factors. Basic interoperability is very easy. Only when you throw in factors such as security that things get complicated. We did some research on availabe Java web service frameworks and found out that the best suited one for our scenario is the metro stack along with netbeans 6.5 IDE. We achieved message secuity which has mandatory for the project using client/server mutual certificate authentication.
Some gotchas discovered in the process are:
- You have to add the webservices-rt.jar library from glassfish directory in netbeans project. (doesn't need glassfish to be running, just the jar file)
- WCF generates multifile WSDL files and netbeans cannot use them to generate proxy, although if netbeans is configured to use the URL (http://../?wsdl) it can generate the proxy.
- You have to put [IsRequired=true] on all datamembers in WCF. Java's handling of optional datamembers is quite complicated.
- Dictionaries as datamembers comes out as list
We have done this successfully on several projects. We use WCF basicHttpBinding, it is the simplest option if you just need to get it to work.
One of the things that can be a show stopper is if a service uses a platform specific datatype, like a Java vector or a .net dataset.
You can use JAX-WS services on the Java side, and then use WCF in .NET.
First create the JAX-WS services (glassfish libraries will allow you to do this). Create your POJO's, add the JAX-WS annotations, and deploy your WAR. Then, get the WSDL generated by your server and give it to VisualStudio. VisualStudio can generate the client for you.
That is the simple way, but your mileage will vary of course.