Basically I am in the process of evaluating thrift for an upcoming project. What I am trying to achieve is to have my data layer written in Java which then serves (via thrift) a ror powered website as well as an iPhone application.
I have familiarised myseld with thrift's IDL and it seems a strong contender due to its efficiencies versus a RESTful service.
I would like to send the POJO via thrift however to do so I am currently having to convert the POJO to the thrift generated object before it can be used by the thrift service however I can't stop feeling there is a better way of doing this which doesn't involve having to do the conversion.
Are there any best practises to overcome this problem?
If you need any more specific information please let me know.
Swift can also do this - you can annotate your POJOs with both JPA and Swift annotations, then use Swift+Thrift to serialize them. Swift can generate Thrift IDL from the annotated classes for you to use elsewhere.
This is Swift: https://github.com/facebook/swift/
I think the best way is to implement the thrift IDL properly and map your structs against a hbm.xml. This way you can generate your POJO's throught thrift compiler, and can persist'em using hibernate.
Related
We have a big project which is composed by JEE modules, JAVA client applications, Android applications, and other self-made java projects.
Because of the variety of projects, we decided to make java libs projects and java entity projects which are common to JEE, Java client applications and Android applications in the goal of limit code redundancy between projects.
At the beginning, we only had Java Clients and Restfull web services on the JEE server side which were exchanging data using JAXB XML Binding API. So it was easy to use JAXB annotations on our Classes in the entity project (which is set as dependency on Java Client project and JEE projects). Both sides could easily encode and decode XML data with the same annotations.
Now that we have an Android app, I wanted to use the same way to exchange data. The thing is that JAXB is 'depreciated' on Android. So I found in Jackson lib that there is a JaxbAnnotation parameter for getting data which is bind with JAXB but I'm not convinced by the full compatibility of the solution.
I also tried using JSON binding since I saw that JSON-B will be the standard in JavaEE 8 but it seems that it needs JavaEE API classes and I don't think that it's good to add it to Android project.
So my question is: What is the best practice to exchange data between JEE Restfull web services and Android application using the same entity dependency (and same parsing API) and limiting the XML or JSON binding annotation on the entity objects?
I hope that you will well understand the problem.
Thank you.
Let's name your entities project entities-module. This project contains POJO classes annotated with JAXB annotations such as: #XmlElement, #XmlType, etc. Since, like you wrote, "JAXB is 'depreciated' on Android" you need to choose between: read JAXB annotations by other tools or create new customised POJO structure.
Read JAXB annotations by other tools
Jackson library has good support for JAXB annotations. All you need to do is to use jackson-module-jaxb-annotations module. It is easy to register and if you already use Jackson for serialising/deserialising JSON this is obvious choice. How to do that you can find reading answers for this question on SO: Using JAXB with Google Android.
Pros:
You do not need to create new POJOs schema.
In case of changes in Restful API you use next version of entities-module project.
Cons:
Problems with enabling JAXB on Android.
Performance issues linked with using heavy JAXB and Jackson module layers.
New module
Second choice is to create new module with POJOs and use faster and smaller library like SimpleXML.
Pros:
Better performance
No problems with building app with depreciated JAXB classes.
You can optimise structure: ignore unused fields, choose better types, etc.
Cons:
You need to create new module with new classes structure.
Learn and maintain new library
In case of changes in API you need to duplicate changes in few modules.
You need to take a look on above pros and cons list and decide what is the best for you.
I would like to also add two more options:
Replace JAXB annotations with Jackson annotations. Jackson has really good XML support beside great for JSON. It will enable for you easy support for JSON and XML formats in your API. Also, you can use Jackson library on Android.
Create new JSON API for Android app. Mostly, UI flows on Android app is different than on Web App and you will, probably, end up with that idea anyway.
Lets assume I develop two services called ProductAPI and OrderAPI.Both of them uses a Common Domain Model (common Entity hierarchy).
Both of the services are finally exposed as RCP (SOAP or REST).
The OrderAPI internally invokes ProductAPI.
In the case of the REST:
We can develop ProductAPI using JAX-RS and we can implement a "ProductAPI REST Client" to be used within OrderAPI to access ProductAPI.
This client can use the same class heirachy to deserialize the JSON into the same classes used in ProductAPI.
So,no indermediate format convertion.
In the case of SOAP:
We develop the ProductAPI using JAX-WS (or Axis2..etc) and expose the service in WSDL.
In this case, we have to implement a "ProductAPI SOAP Client" using the exposed WSDL.(may be using a stub generation tool using the exposed WSDL).
In this came the generated Classes are generated from the XSD definition in WSDL and we have to do additional format conversion if we want to use the same Common Domain Model classes.
My questions:
1) In the case of SOAP is there a way to skip this format conversion ?
2) In an enterprise application (like eCommerce) , is it a good practice to avoid this kind of middle data conversions for performance?
To move data between processes, the data needs to be serialized. You can certainly use a different and better format than SOAP for the serialized data, but if you already have SOAP, it will be more work.
Is it worth trading programmer effort for performance in this kind of project? My guess is no, since the performance will probably be good enough anyway. And if it isn't, the usual advice is to measure and identify bottlenecks before optimizing anything.
Hi : I've been using Jackson for JSON processing internally , and I want to serve these objects as Jsons to an external API (REST) (now, they are stored internally as java objects) .
The obvious implementation would be to write some kind of query engine that reads requests, retrieves objects from the underlying data store, and then serializes them into Jsons using Jackson.
However I'm starting to realize that there are APIs that already can be used to assemble such web services , taking care of a lot of the mundane details (security, query parsing, REST coordination) . For example, it appears that jersey annotations can be used to define REST services ....
So my question is : what are the state of the art in Java EE JSON based web services, and what do these services use as data stores (I.e. Plaintext? RDBMS? Object data services?)
Most importantly... what is the functional difference between the different apis for xml and json data mapping i.e. jersey/Jackson/JaxB ?
Aside from Jersey (and other JAX-RS impls like RESTeasy), which use Jackson, you might also benefit from using something like jDBI for binding relational data in POJOs first.
It does many things bigger ORMs (like Hibernate) do, but is simpler to use for most common tasks.
Or if you prefer Hibernate, use Jackson Hibernate module to handle some edge cases there may be when reading/writing POHOs as JSON.
There is a plugin for Jersey that will take your JAXB annotated objects and serialize them as JSON automatically. Jersey (JAX-RS) is a really good offering.
You can also use JPA annotations on the same objects and a JPA provider like Eclipse Link for a lot of your database needs. A basic relational database can handle most website's needs.
JAVA had released some specifications called JAX-RS to standardise the development of RESTfull web services using J2EE. These specifications are just the definitions and not the concrete implementation .
There are various implementations providers of these APIs(specifications). Jersey, RestEasy, RestLet, Apache-cxf are few such implementations which can be used to implement RESTfull services in JAVA.
Specifically to Jersey, It is not just limited to the implementation of the JAX-RS APIs. It is a framework which has its own set of APIs built by extending JAX-RS capabilities and provides additional capabilities to further ease the development of REST APIs in JAVA.
JAXB stand for Java architecture for XML binding which is another specification provided by JAVA to marshall and unmarshall Java objects to XML and vice versa. Again, Its just the specification and not the concrete implementation.
Coming to Jackson, It is just a JSON processor(typically one of the implementation of JAXB) used to marshall and unmarshall objects from Java to JSON. Jersey uses Jackson internally to convert Java objects to JSON and vice versa.
Jersey is an implementation of JAX-RS. You can think of JAX-RS as an Common interface build for RESTful Web Services. The implementation of this interface is provided by vendors. There are many implementation of this interface available like JERSEY and Rest-Easy. On the other hand Jackson is a Json Processor. It helps you in converting your objects to json and vice versa.
At work, we currently have a WSDL interface as well as a semi-RESTful interface that we're looking to expand upon and take it to the next level.
The main application runs using Servlets + JSPs as well as Spring.
The idea is that the REST and WSDL are interfaces for an API that will be designed. These (and potentially other things in future) are simply a method through which clients will be able to integrate with the interface.
I'm wondering if there are any suggestions or recommendations on frameworks / methodologies, etc for implementing that under-lying API or does it make sense simply to create some Spring beans which is called either by WSDL or REST?
Hope that makes sense.
Have a look at Eunicate it is great . You are using spring , Spring has had support of SOAP for a while and Spring 3 has support of REST (Creating and Consuming).
Your approach makes sense. Probably the most important advice is to make the external API layer as thin as possible. You can use Axis, Apache CXF, Jersey, etc. to handle the implementation of the REST or SOAP protocols, but the implementation of those services should just load the passed in data into a common request object, and pass that into a separate service that handles the request and returns a response object which the external API layer will marshall into the correct format for you.
This approach works especially well when you have a competitor providing similar services and you want to make it easy for their customers to switch. You just build a new external API that mirrors the competitors, and simply translates their format to your internal api model and provided your services are functionally equivalent, you're done.
This is a really late response, but I have a different view on this topic. The traditional way as we know it is to unmarshall xml to java and marshall java to xml. However if the wsdl changes then it would effectively be a structural change in the code which would again require a deployment.
Instead of the above approach if we list the fields mentioned in the wsdl in a presistent store, load the mappings in memory and prepare our structures based on these mappings we would have to have many less changes for this..Thus IMO instead of using existing libraries a configurable approach to unmarshalling and marshalling should be taken.
I'm developing a webapp with Java backend and Flash (pure ActionScript) frontend using BlazeDS.
I'm using the RemoteObject stuff to send objects, using custom serialization, where I need to implement Externalizable (Java) and IExternalizable (AS) interfaces. This works fine so far.
But now I need to send objects from Java to Flash, whose classes are generated with JAXB/XJC. Of course these generated Java classes don't implement the Externalizable interface, so it seems that I can't use my approach here.
One possibility seems to be writing a XJC plugin which makes the classes implement Externalizable. But this looks like a tough job...
Does anyone have a good idea how to solve this problem?
A couple of options:
build a set of objects on top of your JAXB generated classes. I would choose this option.
build a proxy on top of your JAXB generated classes which will serialize/deserialize accordingly each object. If your objects are implementing the Externalizable interface you can use the Dynamic Proxy API from Java, no need for dynamic code generation
modify the blazeds distribution. I would stay away from it, but it is doable.
I finally developed a JAXB/XJC plugin. (If someone's interested, just contact me.)
Works fine now.