I am a bit lost nowadays with all the available libraries out there. What I'd like to have is a small app server (best: jboss as7 as it is very lightweight and based on osgi) and have a lightweight, yet efficient soa-like infrastructure. I was looking on apache service mix though it looks quite complicated/complex. What I basically want to have is this:
Easy definition of stateless services (easy as in a simple java pojo class)
Modularization with automatic service discovery using osgi
Services can automatically represent themselves as either WebService OR (!!) JSON-Format like REST Service
Integrated, easy to handle authentication using OpenId to secure any service endpoint including handling all validation/verification processes
I couldn't easily figure which of all frameworks would really fit in, for example, in Apache Service Mix I can't seem to find support to represent services as JSON-like RESET services nor could I find any integration of security?
Sounds like you want GlassFish 3.1 to me. I can't speak to JBoss or any of the other Java EE 6 containers.
Java EE 6 pretty much covers most of your requirements:
Easy definition of stateless services -- that's a Stateless Session
EJB, and that's just a Pojo -- put #Stateless at the top if it.
Services can automatically represent themselves as a WebService --
that's also a Stateless EJB -- put #WebService at the top of it.
Integrated, easy to handled authentication using OpenId -- JSR 196 (Java Authentication SPI for Containers) covers that, but you'll need an implementation specifically for Open ID. Oh, apparently here is one.
That's all just plain 'ol Java EE 6.
For OSGi, GlassFish 3.1 is a full boat OSGi platform and all of the EJBs are also OSGi discoverable. So I guess you get that for free as well.
As for HTTP JSON WebServices, JAX-RS will do that, but not "for free" like #WebService can. But creating a facade of HTTP RPC on top of a Session Bean should be trivial, since JAXB in Jersey (the JAX-RS implementation within GlassFish) will publish Java as JSON or XML.
So, I'd start there with GF 3.1 and bend it until it breaks rather than running around the net playing ala carte.
Related
I need to work on webservice project. So going through book to cover the basics of webservice project. But these are questions I am struggling with:-
1.Java API for XML Web Services(JAX-WS):- JAX-WS is nothing but just a java programming language API for creating web services which is now a part of core java starting from version 6 (though originally developed as part of Java Web Services Development Pack). Is it right?
2.All other webservices framework whether it is metro, jersey, glassfish uses the JAX-WS internally. Is it correct?
Q: 1.Java API for XML Web Services(JAX-WS):- JAX-WS is nothing but just a java programming language API for creating web services which is now a
part of core java starting from version 6 (though originally developed
as part of Java Web Services Development Pack). Is it right?
It is correct, JAX-WS is an application programming interfaces (API). That API, together with the JAX-WS reference implementation (JAX-WS RI, RI = reference implementation) is a part of JDK since version 6. To extend a little bit, JAX-WS 2.0 is included in JDK 6 from the beginning, JAX-WS 2.1 comes with JDK 6u4, and you will find JAX-WS 2.2 in JDK 7 (see this link).
Q: 2.All other webservices framework whether it is metro, jersey, glassfish uses the JAX-WS internally. Is it correct?
Strictly speaking, Metro doesn't "use" JAX-WS, but includes already mentioned JAX-WS reference implementation. Jersey included JAX-RS implementation, and Glassfish is not a Web-service framework, but an application server. Glassfish comes with the complete Metro distribution.
JAX-WS is a Web Services framework that provides tools and infrastructure to develop Web Services solutions for the end users and middleware developersJAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for building web services and clients that communicate using XML. JAX-WS allows developers to write message-oriented as well as RPC-oriented web services.
In JAX-WS, a web service operation invocation is represented by an XML-based protocol such as SOAP. The SOAP specification defines the envelope structure, encoding rules, and conventions for representing web service invocations and responses. These calls and responses are transmitted as SOAP messages (XML files) over HTTP.
There is another type of web-service, which is called RESTful.RESTful web services are built to work best on the Web. Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a web service induce desirable properties, such as performance, scalability, and modifiability, that enable services to work best on the Web. In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.
Genrally JAX-RS is used for developing RESTful web services. JAX-RS is a Java programming language API designed to make it easy to develop applications that use the REST architecture. The JAX-RS API uses Java programming language annotations to simplify the development of RESTful web services. Developers decorate Java programming language class files with JAX-RS annotations to define resources and the actions that can be performed on those resources. JAX-RS annotations are runtime annotations; therefore, runtime reflection will generate the helper classes and artifacts for the resource. A Java EE application archive containing JAX-RS resource classes will have the resources configured, the helper classes and artifacts generated, and the resource exposed to clients by deploying the archive to a Java EE server.
Different frameworks uses either JAX-WS or JAX-RS. Jersey uses JAX-RS and Metro uses JAXWS.
Was just wondering at the current point in time, what is a good combination of tools/frameworks/libraries for implementing a REST API on top of J2EE that integrates to a backend RDB and using OpenID for authentication.
What I am looking to implement is a server component that provides a set of services, all of which will utilise OpenID authentication, and the services will retrieve or update information to/from a backend relational database environment.
What I'm interested in are:
* application server options available (e.g. Tomcat, Glassfish etc.)
* IDE's (e.g. Eclipse, Netbeans, IntelliJ etc.)
* additional components useful for implementing REST (and JSON payloads)
* what is best practice/good technique/options available for database integration from the services (hibernate via spring, hibernate directly, raw jdbc connections ... )
* for integrating authentication via OpenID - what is an appropriate integration point for any custom authentication mechanism within the J2EE environment - are there any commonly used solutions/plug-ins available for OpenId etc.
Also any pointers to good, current tutorials, books etc.
Edit:
Unfortunately I haven't had as much time to research the results to this question as I'd have liked.
At this stage I've found that installing/setting up REST with Jersey was very quick and I believe I can use a ContainerRequestFilter to provide the OpenID support as per the article here: http://plaincode.blogspot.com/2011/07/openid-authentication-example-in-jersey.html
I intend on using OpenId4Java for the OpenId support, with the PAPE extensions to get users email address returned. I don't need OAuth as I don't need to access any of the users other OpenID details or info on their OpenID site from my server app.
I've had a look at the latest Spring, it looks very good and if I were needing to build a web client with my solution, or had more time to look at both, I could easily have ended up leaning that way.
Thanks for the good answers and replies, hard to pick a single correct answer. I've accepted yves answer because it is correct and the way I'm going at the moment with minimal time to research properly, but awarded the bounty to cfontes answer, as it is also correct, and he's replied with additional information and justification.
Make it simple and modern (Spring is neither one nor the other for RESTful web-services):
Jersey – the JAX-RS reference – defines resources and supports OAuth; its code is compact, easy to use & to plug to libraries (backends, etc...).
Take a look at this project on GitHub, it produces JSON from static data. Its web.xml and ProductResource are good places to start.
Every server will do the job, Jetty is my favorite, Tomcat, the standard
The choice of an IDE is up to you, the 3 you're giving are great, well integrated with Maven and source control tools. I use Eclipse from habit
I would go for
Spring 3: this can be useful to wire things up with Dependency
injection and other things.
Spring MVC: Restful support and Request mapping, a request based
framework that integrates very well with Spring
Apache Tiles: to make the HTML templates easier to make.
Spring Security: it's a JAAS implementation and for me it's better and
easier than Standard JAAS.( doesn't need a full web server, tomcat will do fine)
This can help you decide which Persistence provider you want : Persistence Provider comparison I would go for Hibernate, because it have a lot of great features like Criteria API, hibernate Search and it's widely used.
Of course your app should be using JPA 2 for the sake of interchangeability instead of using a Persistence provider directly ( it's not easy to chance from one to another but with JPA2 it's possible, also should be giving you a lot of trouble but it's possible)
I would go with NetBeans 7.0.1 and GlassFish as explained here
From the linked tutorial:
The IDE supports rapid development of RESTful web services using JSR 311 - Java API for RESTful Web Services (JAX-RS) and Jersey, the reference implementation for JAX-RS.
For authentication, I would use the GlassFish JDBC Realm (have a look at this tutorial) but I have never worked with OpenID, so I don't know if this approach can be used together with OpenID.
I am totally new to Spring Web Services and so what concept should I start concentrating on and where should I be looking for them and in general what steps would you recommend to get to speed with Spring Webservices Module.
Note: I have an requirement to build Web Service for and consume Web Service from different application and I have never worked with Web Service in the past, I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not ?
Any guidance and suggestion for discussion kind of approach would be highly appreciated.
Thanks.
(...) I am looking at Spring WS option because both application are developed using Spring Framework, is this a good assumption to look for Spring WS or not?
It's not a wrong assumption (bad integration between Spring WS and Spring would be a total irony) but you should not exclude other stacks on the fact your applications are using Spring. JAX-WS stacks (like Apache CFX or JAX-WS RI) provide Spring integration as well.
Personally, I like JAX-WS (that I use for contract-first web services) and, while it's hard to be more specific without more details about your requirements, I simply don't think that Spring WS offers any advantages over JAX-WS and I would probably go for Apache CXF in your case.
Maybe have a look at what others are saying in this previous SO question (please read all answers, the accepted one is not really good in my opinion).
What are your protocol requirements? Do you have to use SOAP, or are you free to use your own XML marshalling over HTTP (e.g. a RESTful approach)?
If you must use SOAP, then see this guide I wrote to Spring WS web services. If you're free to use your own lightweight RESTful web services, then see this example I wrote on RESTful web services.
I wouldn't use Spring WS ONLY because of the reasoning you provide. You need to identify more functional requirments like:
Can you use markup (JSON, XML, etc.)
Should you provide content negotiation
Do you need to provide complex objects (i.e. SOAP as james suggests)
Are you providing a RESTful service
etc.
I've worked with web services a lot in the past few years and there seems to be a few major projects for creating them:
Apache Axis (primarily SOAP)
Apache CXF (primarily SOAP)
Jersey (REST)
Restlet (REST)
There are other offshoots like Spring WS, or even Spring MVC, but you need to evalute which will work best.
Personally I use Jersey a lot, which also provides Spring integration. Jersey also has an awesome HTTP client for consuming services, but don't confuse creating a web service as being akin to consuming a web service. They are separate workflows and you could use separate third-party projects for both (e.g. Apache HTTP Client for consuming, and Jersey for producing).
Spring WS might work best for you, but my advice would be don't use it just because the other applications use it...use whatever works best and fulfills your requirements.
I have a stand-alone, Swing application that uses Hibernate for its persistence layer. I need to extend this to a three-tier system, so that there will be multiple instances of the Swing application and a central server. The client is a stock trading platform, so it will contain a lot of business logic. The server will be responsible for mostly persistence operations and some business logic.
What would be the best way to implement the server for my needs? EJB3 or Spring? What is the best practice for Swing applications to interact with a server? I don't want to go with RMI since not only is it becoming obsolete but also there is no guarantee that the clients and the server will be on the same network.
If the client is a Java client, I don't see the point of using web services (and thus having the overhead of the object to XML serialization) and I would go for EJB 3.x.
For me, the major benefits (beyond performance and scalability) that you get with a good container are fault-tolerance and fail-over (both on the server side and client side, especially with Stateless Session Beans if they are idempotent). For a stock trading platform, this matters.
Also note that using EJB3 doesn't necessarily exclude using Spring for the glue (on the client side and/or the server side).
And if the need to expose your services as web services should arise (e.g. for another non Java client), just annotate them with JAX-WS annotations.
I don't want to go with RMI since not
only is it becoming obsolete
This isn't true at all. As long as Java is around, you'll have RMI.
And what do you think EJBs are using to communicate? It's RMI.
but also there is no guarantee that
the clients and the server will be on
the same network.
Personally, I'd prefer Spring. You can expose your service layer using web services or HTTP remoting.
Go with Spring and RMI. If your client and server are both Java it is the best solution with best performance and productivity.
Note that EJBs don't necessarily use RMI as the transport protocol. OpenEJB for example uses its own custom protocol. We get about 7300 TPS over the wire which is pretty good. There is a Spring integration as well so if you wanted, you could build the server with Spring and inject Spring beans into EJBs and vice versa:
http://openejb.apache.org/3.0/spring.html
Though this might appear as a duplicate of Java Web Services , I would like to know Where to start and to continue.In the past, I have invested so much of time to find where to start but I wasn't able to. There are so many jargons and chaos (at least for me!) while reading the pages about web services. There are so many terms - like JAX-RPC, JAX-WS, Axis, Rest, Servlet as WebService, EJB's as Web Service and other terms that I don't know. Can this User group consolidate and give a highlevel overview of Java Web Services which is easy to understand and follow? I appreciate your kindness and thanks for your help.
That's indeed a bit a jungle to understand web services. The wikipedia page is decent, but still lacks some elements.
I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.
A bloated term:
First, the term web service is used to refer to many thing. While many people use it to refer to SOAP-based web service, the term can be used to denote any service provided through a web interface; this is a source of confusion.
Implementation and design style:
SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describes the exchange of message and exception. SOAP grew from something simple to something very complicated with all the WS-* standards that have been added later. The most important are: WS-Policy, WS-Security, WS-Addressing, WS-Transaction. Another important spec is MTOM for large message.
RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
Stateless -- WS are usually stateless. Business processed sometimes rely on so-called correlation identifiers (with WS-Addressing) that are used to match requests and response together; this is the same idea like storing a session identifier in a cookie because HTTP is stateless.
Stateful -- There are some proposal to have stateful WS, but I don't know much about it.
Implementation and technology stacks:
Servlet -- The lowest-level way to implement a WS: you basically parse the request and spit the HTTP response all by yourself.
EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
Apache Axis -- Used to be a popular technology stack which is declining now.
Apache CXF -- Another popular choice.
JBossWS -- Yet another popluar choice.
JAX-WS -- The official web service stack from Sun, very good. So far I know, this replaces JAX-RPC which was simply renamed JAX-WS.
Related concepts and jargon:
WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation of the web service, in which case the WSDL can not always be customized as necessary
Profile -- To simplify this mess, they've introduced profiles which are groups of related specifications/capabilities that need to be supported for interoperability. The main one is WS-I Basic Profile.
UDDI and discovery -- It seems like some people thought the web service would be published in a public register so as to be discoverable by potential consumer. I don't think this vision gained much momentum.
The best explanation I know for "contract first" web services is Spring web service module.