Wednesday 29 June 2016

JAX-RPC vs JAX-WS vs JAX-RS


However practical use case difference and when to use what. Both, JAX-WS and JAX-RS have standard implementations. I have come up with the following differences:

RESTful services (Mostly web integration, mobile phone apps)

Integration over web will be easy with the REST. Popularly used with the AJAX calls.
Not verbose as SOAP services so need less bandwidth hence good to use for the mobile apps.
Web services are completely stateless so only for stateless services.
JAX-WS and JAX-RPC are SOAP based services. (Enterprise web services)

JAX-WS Java EE later versions support this and standards still evolving. - SOAP based services not preferred for mobile app communication because of heavy payload compare to rest. - More suitable for the enterprise web services where you need interoperability, transactions, message delivery and reliability.


JAX-RPC forget about this one. It is the old obsolete standard for Java Web Services

JAX-WS new standard for SOAP-Based web services (also is provided as a reference implementation)

JAX-RS stack for REST-full web services


JAX-WS uses asynchronous features from Java 5.0,J2EE5.0 JAX-RPC is primarily uses features from J2EE 1.4 and is supported in J2EE 5.0 also.

JAX-RPC has its own data mapping model,it covers many and those are not covered are mapped to javax.xml.soap.SOAPElement.

JAX-WS's data mapping model is JAXB that promises mappings for all XML schemas, which has got many advantages like one can use with XSD and using annotations without XSD, it is highly useful with large, complex XML and few limitations also.

There are some differences according Webservice specifications as the specifications has got changed and improved after JAX-RPC and hence Jax-WS got some more features.

One thing is common is both are confusing while using them with J2EE 5.0, JavaEE 6.x. The better is Jax-RS or Jersey for new implementations and re-designs. or You can continue with JAX-RPC or JAX-WS.

JavaEE7.0 promises new light weight, developer and tester friendly approaches for RESTful webservices.

Java Architecture for XML Binding (JAXB) is an XML-to-Java binding technology that simplifies the development of web services by enabling transformations between schema and Java objects and between XML instance documents and Java object instances



The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:


  • Clients are required to know procedure names;
  • Procedure parameters order, types and count matters. It's not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc...) on server side without breaking client implementations;
  • RPC style doesn't expose anything but procedure endpoints + procedure arguments. It's impossible for client to determine what can be done next.
  • etc...

On the other hand in REST style it's very easy to guide clients by including control information in representations(HTTP headers + representation). For example:

  • It's possible (and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;
  • Client implementations do not need to depend on particular procedure names and arguments. Instead, clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats (e.g. Atom, HTML, Collection+JSON, HAL etc...)
  • It's possible to easily change URIs without breaking clients as far as they only depend on registered (or domain specific) link relations;
  • It's possible to embed form-like structures in representations, giving clients the possibility to expose these descriptions as UI capabilities if the end user is human;
  • Support for caching is additional advantage;
  • Standardised status codes;
  • etc...
  • There are many more differences and advantages on the REST side.
REST is often compared with RPC, but the truth is they are not comparable entities. In the most common meaning REST is a concrete architectural style bound to the HTTP protocol, whereas RPC is a generic abstract protocol whose only contract is to perform remote method invocations.

All Collected from different blogs...Aggregated here...

Refer:
http://maxivak.com/rest-vs-xml-rpc-vs-soap/

Tuesday 14 June 2016

Update Ivy xml generated in Ivy publication in Gradle




How to update Version in Ivy xml generated in Gradle ?


Solution:

In Gradle it uses  groovy scripting API.
So think like groovy guy .
To update this Ivy XML::
  1. Go to  Interface IvyPublication
  2. Go to Method > IvyPublication>descriptor
  3. Where descriptor takes IvyModuleDescriptorSpec
  4. Go to above interface, u will find wihXML which returns XMLProvider
  5. XMLProvider has asNode() method which returns Root node.

Usage :
publishing {
publications {
       
Ivy(IvyPublication) {
organisation "$project.group"
                                module "$project.name"
                                revision "$project.version"
from components.java
descriptor.withXml {
asNode().info[0].appendNode("description", project.name)
asNode().dependencies.dependency.findAll{ it.@org.startsWith("com.group")}.each{ it.@rev = "$project.version" }
               }
             }
    }
    repositories {
       mavenLocal()

    }
}

Thursday 2 June 2016

Eclipse Static imports


There are two preferences that work together to enable this feature. The first one just needs verification:
  1. Go to Window > Preferences > Java > Editor > Content Assist.
  2. Make sure the option Use static imports (only 1.5 or higher) is enabled (it should be enabled by default, but it’s good to verify this anyway).
Here’s an example of how it should look:


Next you have to tell Eclipse which classes you’d like to add as static imports. Here’s how to do this:
  1. Go to Window > Preferences > Java > Editor > Content Assist > Favorites.
  2. Click New Type. This brings up a dialog where you can enter the fully qualified type.
  3. Enter org.junit.Assert and click Ok (you could also use the Browse… if you want to search for the type). Eclipse will add an entry to the list which reads org.junit.Assert.*.
  4. Click Ok on the preferences dialog to save and close the preferences.
Here’s what my list currently looks like:


You can add an entry for any other static import you’d like, even for a static Utils class you’ve written yourself.
Now, to test that it works you can add a JUnit test, type assertEquals, press Ctrl+Space and press Enter on the appropriate entry. Eclipse will now add the static import org.junit.Assert.assertEquals (or org.junit.Assert.*, depending on your Organize Imports preferences).
As I mentioned before, this only works for autocomplete and not for organise imports commands (eg. Ctrl+Shift+O), but it is already a lot better than having to enter the import yourself and should do the job most of the time.