I am relatively new to the Java ecosystem and I am trying to determine what frameworks are available that can do some or all of the following:
Expose POJO's over the network using a variety of technologies
Be able to switch the transport layer (HTTP, TCP, UDP)
Supports different message formats (SOAP, JSON, Binary)
Supports Web Services, REST, and RPC
I want to be able to support using multiple of these communication mechanisms using the same code base (for example using RPC in behind the firewall for efficiency, but exposing the same objects via REST for public consumption). For those familiar with the .NET framework, I'm looking for something of a unified communication framework like the Windows Communication Foundation.
So far I have found tools like Jersey (JAX-RS) that works for REST and Axis2 which is more Web Services oriented but also has some REST support. But I haven't found something as flexible and configurable as WCF. Does that even exist in the Java world? What would be the closest thing to it?
Thanks.
You may want to take a look at Apache Camel which will allow you switch and transform easily as well as supporting a variety of transports natively and having out of the box integration for some popular frameworks.
Additionally if you're looking for a platform to build concurrent and highly fault tolerant applications around, akka is worth a look.
For webservices related stuff I would look at Apache CXF which integrates nicely with Apache Camel, Activiti, Mule and more.
In general though you will find that the Java ecosystem has a lot more options and ways to do certain things (for better or worse). Also keep in mind that you can work with non-Java but JVM based libraries as well.
Related
First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability
This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.
I'm debating whether I should use java RMI or standard Java networking for an application i'm working on.
The app will be a networked system that has heartbeat sensors and failsafe-features. So it's a 3-tiered system, with at least a DB and java application.
So if my Database fails on one machine, I'd like the 2nd machine to "sense" this.
I'm a bit confused about Java RMI, whether it's worth it to learn it.
Or if I use standard Java networking , I can do the same as RMI? I mean, if I really know the Java networking well.
Thanks!
These days it is pretty easy to set up web services using SOAP or REST. With REST you can use XML or JSON messages without really having to know all about it. All these types of services can be accessed from .NET code or PHP or Javascript. (Well ... SOAP is sort of a pain except in .NET and Java. //personal opinion )
Spring can help you set up a service and a client interface to it is pretty easy. Fairly close to standard Annotations on bean classes and business methods define the interfaces and Spring does the heavy lifting. (I'm talking about Spring Web Services and not the Spring Remoting, though that would work as well. Spring Remoting isn't much better than RMI IMHO.)
You can also use Jersey (JAX-WS) or Jackson (Parse JSON) to do the remoting. Standard Annotations on bean classes and what-not build the interfaces. CXF will do JAX-WS and JAX-RS as well. Those are Java standards for building services and clients that communicate via remote messages.
Alternatively there are eclipse tools for generating both sides of the remote interface. All are tied to some framework (Axis-2 or CXS are some). Its sort of a code generation thing.
You might want to look into these a bit and see which one resonates with the way you look at things.
I know that I prefer all of these over using RMI. But I haven't used RMI directly in a long time.
RMI is higher level protocol compared to the bare TCP/IP support in Java via Socket class that you seem to refer to as "Java networking". If the only thing your system does is sending heartbeats and there are just few nodes you should choose RMI for simplicity reasons. As all of the participants are JVMs there is no need for any interop and extra libraries to support that and as the number of participants is limited there is no need to consider anything fancy.
We have a Swing application. Now I need to set up a Java EE server that provides some services to these Swing clients on a LAN.
What is the best practice to implement this, considering that client and server communicate in both ways?
If the clients are in the LAN and you are programming both sides I would take RMI. Because it is much more performant than Webservices. I think it is the native way for communication with a Java EE Server.
Perhaps you should create Facade classes on the server-side which are providing the services.
Using JAX-RS with implementations like Jersey or Apache CXF with XML or JSON data format is a decent option.
If you need flexibility, go with Spring remoting, as it abstracts the remoting layer, so an eventual change of implementation keeps your hands clean.
I use HTTP Invoker, beacuse it's lightweight and uses java serialization, so it's a good choice for Java client -> Java server communication.
The downside of HTTP Invoker, in contrast to RMI, is that you always get new instances of objects from the server, so if an object sent from the client is changed on the server, the change won't be reflected in the client instance.
Good info is here: Considerations when choosing a technology
I would advice using Webservices.
RMI - This is pretty fine for Java applications, but it's general interoperatibility is imho low. If i imagine that you would like to switch from Swing to other technology or add another client not written in Java, RMI would be nightmare then.
Web services - It does not cover both directions communication. It's fine for Swing - Java EE, but you would have to do also some WS (or any other exposing mechanism) on Swing side which would take care of Java EE - Swing communication. E.g. like REST on Java EE and XML-RPC on Swing.
You can also think of using ESB.
I would suggest Spring RPC or maybe EJB 3 if you have a Java EE server and prefer to stick to standards of Java EE specification
Web Services are not binary and therefor will suffer from performance issues.
I am new for SOA.i want to known how to implement SOA in Java.i am go through various sites that only deals with the concept,it don't give clear idea about the implementation details,for using SOA in Java.plz provide an details for how to implements SOA.
Thanks
SOA is about design principles (some might even say it's a paradigm) and less about tools and implementation, so it is difficult to fire up your IDE and "implement an SOA".
Because SOA is bigger and complexer than, say, a design pattern, most sources on the subject only deal with the theory and do not discuss implementation details.
If you understand the concept and know Java, then you can start implementing on top of existing frameworks (see other answers), by reusing existing components, or, if you are feeling I-want-to-write-a-C-compiler-from-scratch-y, you can try to design and code your very own SOA from the ground up.
Check out the Axis 2 web site on Apache:-
axis2
This is a mature well thought out SOAP framework which is widly deployed.
As well as the soap client and server componemtns there are a number of development tools
with will enable you to SOAPify an existing java class, or, generate the Java class stubs from a SOAP WSDL definition.
Take a look at Apache Servicemix:
Apache ServiceMix is an open source
ESB (Enterprise Service Bus) that
combines the functionality of a
Service Oriented Architecture (SOA)
and an Event Driven Architecture (EDA)
to create an agile, enterprise ESB.
Additionally, the latest major release of ServiceMiix is built on top of OSGi - a "module system and service platform for Java".
SOA is a thinking, it’s an architectural concept, and web service is one of the technical approaches to complete it. Web services are the preferred standards to achieve SOA.
If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which is your own wrapper and will wrap your custom systems and expose the systems functionality in a generic fashion to the external world.
In SOA we need services to be loosely coupled. A web service communicates using the SOAP protocol which is XML based, which is very loosely coupled. It answers the what part of the service.
you can use Axis2 web services to implement it.
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.