I had recently started appreciating the WS without XML/Annotations a few weeks back, but to my surprise, the XFire implementation is no more supported in Spring 3.x hence I had to fall back on XML and Annotations.

I could come up with a working example of contract first WS development from here, and I was happy to see things working as expected, except for the inherent pain of seeing and using XML/Annotations.

This made me re-visit my understanding of whether to use java-first or wsdl-first approach for development.

I was initially a supporter of java-first simply due to my dis-liking for XML, now it seems a wsdl-first approach can keep the concentration of implementation towards the data structure of the messages that go to-and-fro.

That said, if I develop a java-first implementation, and give the 3rd party implementation team the link to the wsdl, does the 3rd party implementor stand to loose anything?

Either way’s even if they are using something other than java to consume the services, they have to wrap the response as per their conveneince, the only tradeoff that I seem to have is the structure of the wsdl message is not the fundamental change item, but the java method arguments become the items that define/control the change.

The only flexibility that I might be loosing here is the power of functional programming language, as-in imagine if a functional programmer implements a wsdl as per my current understanding, I question, does that programmers changing of the wsdl based on the arguments that come and go, affect(ease/pains) my implementation?

To conclude, do I stand to loose anything if I *still* go the java-first implementation way?

Your thoughts?

~rohit.

Android is a software stack for mobile devices….. that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

FYI: We’ll have posts on Android SDK and ENV. setup later…!

And now what is the …..? Android Application Fundamentals :

Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application.

Once installed on a device, each Android application lives in its own security sandbox:

• The Android operating system is a multi-user Linux system in which each application is a different user.
• By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
• Each process has its own virtual machine (VM), so an application’s code runs in isolation from other applications.
• By default, every application runs in its own Linux process. Android starts the process when any of the application’s components need to be executed, then shuts down the process when it’s no longer needed or when the system must recover memory for other applications.

And for that, I came across the linked jsp and the following code snippet in the footer jsp of the application:

      <%@include file="/WEB-INF/jsp/debug_session.jsp"%>

keep the debug_session.jsp as per the path defined in the above snippet.
To check all request & response variable while developing, just update the current url as:

http://localhost:8080/context-path/login.jsp?debug=jsp

And you can easily check all variable without trying to search them in the request object on your IDE, while debugging!

Here is the debug_session.jsp

~rohit.

And the pain of tracking the changes, without review/comments is unacceptable!

Hence with the motivation set in, this is the template that I could come up after a *lot* of thinking:

and here’s an instance of an entry derived from that template:

I have modified the actual text that was prepared for generality and not keeping office work in public!

Incase you have not already guessed, this instance deals with viewing artefacts for moderation.

While preparing this template, I was not cent percent aware of the domain that I was dealing with and also, I was new to this module, maybe that can work in favour of most people in similar situation!

What do you think? Does this template gives you the ability to cover all/most scenarios in your development story?

Feedback welcome!

~rohit.

And the successful implementaion was in two phases.

The first phase: Installing/Configuring the scripts for inclusion and second was testing them out!

Here comes the comparison of their usage:

Ease of finding share buttons.

Here LinkedIN fared last(it took me some time to reach the actual page)), while facebook came second last(it was simply not intuitive to see what changes were getting affected) and google just beat twitter for better placement of the generated script.

Basis: Easy finding + Instant display of customization + Zero extra effort.

Size of included JS

Here FB was last with 100+KB of script, while other three were quite okay, seemingly under 29KB all three combined.

Basis: Don’t know why FB is pushing so much client side javascripts?

Ease of understanding the tag’s

Here the clear winner is twitter, as they simple do a script include and use an anchor tag! It can not get simpler than this. Google came second by making it complex by adding their own custom tag. FB was ugly, while LinkedIN was pathetic, as there was not handle that I could find in their code!

Basis:I am a non-UI guy, so and anchor tag + js include sounds like I am at home!

Alignment on the UI

Twitter and Google fared quite well here, as placing them in a span/div tag, did not distort their buttons, whle FB and LinkedIN folks seems to have done a sloppy job here. Try putting a div around them and you might see their button’s vanishing at times!

Basis:I should be given complete freedom to place the button’s where I like’em.

Getting them to work!

All 4 of these scored 0 on this front. I wasted one whole day trying to figure-out the reason for these tag’s not working on localhost. Surprisingly they require a live public url for them to work fine!

Very dis-appointing!

Basis:I suppose I should be able to test on local how these buttons look for testing!

After getting them to work!

Al most all of these have a bug that if I delete the publicly promoted link/url/etc, the count does not seem to come down accordingly.Strange, but true.

No – Thank You!

For incorporating all of them I had to create a new id and register. I am glad I did it that ways, because LinkedIN was all over me pouring all their corporate tie-ups link/spam/trash all to me and making me a subscriber by default. Also reading the fine print LinkedIN seems like they are selling all infromations to 3rd party affiliates without a clear consent!

Going through FB and twitter settings was also a pain, did not go through details on +1!

Basis: No thanks for the spam!

The inclusion codes for each of these are available on these sites:

1/Google +1 2/Twitter  3/Facebook 4/LinkedIN

Well after checking out the code on a live public url, I suppose the feature would easily come out, but this was an interesting learning experience about how do folks at big public organizations code!

Twitter seems to be leading in this front by keeping it really simple!

~rohit.

Then motivated to defeat XML in my own war, and reducing its footprint in the codebase I am working on, I put on the searching glasses and XFire came to the rescue(credits to them for integrating WS in the most cleanest manner done with Spring, that I know of!)

Now that the plot is set, here’s simple how to:

Presumption: You have two different projects one is the WS other is the consumer of the WS.

Step 1/ Write your service and its implementation in the WS project.
(eg: XXXService/XXXServiceImpl for the project YYY)

Step 2/ Configure the usual project as a spring web project.

Step 3/ Add the following snippet into the web.xml(append incase you have contextConfigLocation predefined.). This makes your project XFire aware.

  
    contextConfigLocation  
    classpath:org/codehaus/xfire/spring/xfire.xml  

Step 4/ Expose the service as Http WS through XFire Exporter:

    
            
            
            
        XXXService    

Step 4.2/ Inject the Service Impl Bean.

Step 4.3/ Configure the Url for accessing the Service.

Step 5/ Deploy the WS project an tomcat/jboss.

Step 6/ Test using the soap url:: http://localhost:8080/YYY/XXXws?wsdl

Step 7/ Configure the XFire client on the other project as follows:

    
      XXXService    
      http://localhost:8080/YYY/XXXws?wsdl    

Step 8/ Inject it in your client

Step 9/ The client should be configured as::

public class WsClient{    private XXXService xxxService;}

Step 10/ Done!

Things to remember::
1/The Java Interface XXXService needs to be shared with the client.
One can overcome this by creating a third common project shared for the WS Provider and WS Consumer.

2/Any changes in the WS provider, would require re-deployment of the first project.
This is the least a java developer(xml unfriendly) can absolutely live with!

3/Once these configurations are done, forget that you ever need to look into the xml’s!
Also any change addition/removal of the methods that needs to be exposed will be purely a java exercise, without requiring to smell XML.
Well you won’t be able to find any xml!!!, thanks again to the wonderful folks at XFire!

PS: All these steps are written here with the help of http://xfire.codehaus.org/Spring+Remoting and implementing this in a production environment!

Hope this helps you in reducing the amount of unnecessary XML’s in your java projects!

~rohit.

We are one year young on this 19th day of January 2011.
Let us look back as to what we had planned to achieve and what all was materialized!

Any plans/suggestions are welcome.

~rohit.

Well, as my first attempt at defining IoC and DI, I made the following statement.

IoC is the concept and DI is the way of implementing that. Pretty neat, huh? But how do I go explaining this to anybody in greater depth?

Now, it seems I do have an answer, according to the book Spring In Action:

“IoC aims to offer a simpler mechanism for provisioning component dependencies (often referred to as an object’s collaborators) and managing these dependencies throughout their lifecycles.”

It further states that “IoC can be decomposed into two subtypes: Dependency Injection and Dependency Lookup.”

Now drilling down further, DL (Dependency Lookup) allows acquisition of a reference to a dependency, whereas in DI, the IoC container itself is injecting or providing those dependencies. One can draw an inference that the former scenario is allowing you to control how and when to acquire the dependency and in the second case the container is having the control over the dependency lifecycle.

So, the statement I made above is validated upto a certain extent.

Any further thoughts/comments on this would be certainly welcome.