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.
Related
I feel a bit naive for asking, but I'm trying to get a better understanding of web service frameworks.
Do you absolutely need a Jax-WS/RS reference implementation (like Axis/CXF) to run a web service application on a server like Tomcat? Is it at possible to get by with a collection of your own imports (Spring Framework libraries, Java EE libraries, JAXB, etc.), provided that you do not need things like wsdl2java auto-generation?
Are Axis/Axis2/CXF an essential part of any web service project, or just a nice to have?
I've used CXF and Axis in the past, but both were buried so deep beneath Spring and my IDE that I never got a clear picture of where the web service framework ended and the Spring framework/dependencies began.
The documentation on the web service frameworks also doesn't tell me much, as it focuses on what they frameworks can do, vs. how you might be able to get by without them.
Thanks
If you want to deploy a web application on Tomcat then the bare minimum you need to do is implement the javax.servlet.Servlet interface.
If, by web service, you mean a SOAP service, then there is more you will need to do (well, to be specific, you will need to implement a Servlet which behaves in a certain way). There are two primary features that frameworks like CXF/Axis provide (and a myriad of smaller features):
Serialization/Deserialization
Bare HTTP requests are available as streams of bytes (InputStream/OutputStream). In many applications you will want to convert those byte streams into Java objects. With JAX-WS this is done by requiring the input/output be XML and using JAX-B. Other frameworks (e.g. JAX-RS) can work with other input/output formats (like JSON).
Routing
An HTTP request consists of a URL (perhaps with query parameters), headers, an entity body, and various metadata around the call itself (e.g. IP address, session object, etc). Somehow this request has to get mapped into a method call in your service, with parameters. In JAX-WS this is done by mapping parts of the SOAP envelope with information about your service endpoint gleaned from reflection.
So...
If you want to skip using Axis/Axis2/CXF you will need to find some way to implement those two features yourself. You will almost certainly also be surprised by the amount of tiny details involved in solving those problems (e.g. SOAP RPC/encoded message format versus document/literal format, etc.)
CXF will also implement a number of SOAP extensions, the most prominent of those being ws-security (although many people end up using Spring security and bypassing formal SOAP security anyways).
Alternatives
Your question is a little vague so I'm not certain what you're after but there are some alternatives.to just using Axis/CXF...
Different JAX-WS library
There are other JAX-WS providers out there. For example, you could use the JAX-WS RI although your experience is not likely to be too much different than CXF/Axis.
Different web service technology
Rather than using SOAP you could use a RESTful framework like JAX-RS. This can be particularly helpful if you want to understand more the connection between HTTP and your calls. There are a myriad of articles discussing the benefits/drawbacks of SOAP vs. REST so I won't go into that here. In general JAX-RS is a lot more clear and customizable but requires more work to configure.
I have whole business logic along with its integration to database written in Java. Now I have two options: either I can write a Restful webservice to access it or I can follow the standard servlet approach to access it from UI... What are the advantages and disadvantages of both?
In fact, you try to compare things that are different.
REST is a style of architecture targetted distributed systems in the context of the Web technologies. Whereas it doesnt depend on the HTTP protocol, the latter is particularly suitable to implement these concepts. Implementing a RESTful service with HTTP means that we will leverage all its features and use them for the right thing. Those principles can be implemented with different technologies and in Java with different frameworks.
This link could provide you some insights about the REST concepts: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Servlets correspond to an API and a container to handle Web applications. The container is responsible of the transport layer and let you focus on the way to handle HTTP requests and create responses. But you are free to them to build you application and use HTTP like you want. Most of time a framework is used on the top of them to implement applications. You can even implement RESTful applications with raw servlets if you want with a bit of additional work.
There are several frameworks like that:
Restlet (http://restlet.com/projects/restlet-framework/) that allows to create and / or consume RESTful services in Java. They can be executed in a standalone application or within a servlet container.
Spring MVC that provides a support to configure Web applications within lightweight container with dependency injection. The framework also provides REST support.
Hope it helps you,
Thierry
Webservice going to help you to communicate between two application which may be having different platform(for example communication between java and .NET possible using this).
But servlet can bind u to talk within one application which is bind with java platform. you can able to talk with two java application using servlet also but for that u have change server configuration. So please understand your requirement and use it
As Thierry said, they are diferent things, and its up to you define the need of REST implementation. I would suggest an article: http://martinfowler.com/articles/microservices.html
Its a very reusable way to isolate and expose your business logic.
I am trying to consume a public Web Service:
The Web Service uses SOAP communication
The Web Service doesn't expose the WSDL. It is possible to download it from the creator's website.
The Web Service only allows to connect via "whitelisted" static IPs.
The Web Service is hosted on GlassFish, so I am guessing it is written in Java.
The Web Service specification is rather long and contains many mandatory fields.
I would like to expose the Web Service to different type of developers during a Hackathon challenge, which may be using Python, Java, C# or other programming languages.
I used SOAPUI to test the Web Services and it was rather easy.
When I tried to use the standard packages in Python (SOAPpy) and C#, I had many difficulties. When using Java and CXF, it was a nightmare creating the request object.
How would you go about exposing the Web Service in a way which is friendly to developers?
No changes can be made to the original Web Services.
Thanks in advance!
If you want to access the original web service I recommend use its native protocol (SOAP) even though SOAP can be a major PITA and sometimes library support might be lacking (especially in modern script languages like Python, Ruby) because SOAP is not "cool".
ReST/JSON web services are deemed to be more "easy to work with" by many developers but shoehorning a "wrapper"/proxy on top of the existing web service will probably cause even more confusion and subtle bugs.
If the web service is fairly complicated this could mean this project is not ideal for a hackathon. If I were in your position I'd prepare client stubs (including a simplified library API) for 1-2 languages like Python and Java. For Python check out one of jurko-suds, pysimplesoap, or soapfish and check out which one works best out of the box with your service.
As I feel I'm drifting out of the StackOverflow scope I'll stop here :-)
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
I'm currently working on implementing the public API of our web application. The application is written in Java.
This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.
What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).
We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.
The API infrastructure will be on a different sub-domain and on a different server.
The API should use Oauth to authenticate the users.
I looked into Grails, Play!Framework and Restlet to achieve my goals
Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?
Thank you all
I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.
This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.
You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.
I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.
What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).
If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.
REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.