We Keep Coding

POJO Classes being serialized with no read/write usage

I am new to SPRING and was assigned to work on project currently under development. Unfortunately development of the project has been slow so people have come and gone so I cant ask them why some things were done a certain way.
The project is a web service using SPRING.
They are using a View - Controller - Service (interface & implementation) - DAO (interface & implementation) - POJO (class used to transport data structure across layers).
Every POJO I have checked implementations serialization. On closer examination and search of the code, none of the POJO's are ever written or read, either in the POJO itself or any other file. Which has lead me to ask why its being done.
The POJO's are populated from Oracle statements in the DAO, which bubble upto the view, and then will bubble back down to the DAO where they information from them are written to the database using Oracle statements. The POJO itself is not written into the database.
Does SPRING MVC or java web applications require serialization and it is being used in the background? Is it needed to transmit the data between server and client connections? Is there a good reason that all the POJO's are using it that someone new would not recognize?

Depends on technologies used in the layers as well as implementation details.
If persistence is done using JPA/Hibernate then POJOs most likely will need to be Serializable.
In case if the POJO is passed to view via servlet session and session replication is on then you need to have your POJOs Serializable.

Use of Java's default serialization is a normal way for regular POJOs.
Java specifies a default way in which objects can be serialized. Java classes can override this default behavior. Custom serialization can be particularly useful when trying to serialize an object that has some unserializable attributes.

This might not be the correct answer, but so far in my case it matches and explains what I am seeing. I have not seen this information mentioned else where, but the answer is well upvoted, has been around for awhile, and is from a high reputation user, so I am inclined to trust it.
There is an answer from another question where they mention something important.
As to the why you need to worry about serialization, this is because most Java servlet containers like Tomcat require classes to implement Serializable whenever instances of those classes are been stored as an attribute of the HttpSession. That is because the HttpSession may need to be saved on the local disk file system or even transferred over network when the servlet container needs to shutdown/restart or is being placed in a cluster of servers wherein the session has to be synchronized.
The application Im working on DOES use Tomcat, so if this is a restriction or behavior, then I can easily see why all the POJO's are created in this fashion, simply to avoid issues that might develop later, and is a result of experience having worked with this all before, and its that experience that I am lacking.

Are the use cases for translating Java to XSD different than translating XSD to java using JAXB?

I have seen similar questions saying that the direction to take (java to xsd or xsd to java) depends on your focus, in other words are you looking to create the perfect schema or perfect java design.
However I am curious to know if the use cases are the really same. A colleague of mind commented, "why would you want to go from java to xsd?", if you do that you have already created an implementation. Which sort of does beg the question, why would you start with hand written java, convert to xsd, and then eventually convert to generated java.
To try to ask it differently, does it really matter which route you take (java to xsd or xsd to java) , because in the end the artefact that you require is xsd, which can be converted adhoc to java when and if required.

Each approach has its pros and cons:
XML-To-Java:
PRO: The interface contract is a first class artifact. It is explicitly designed and coded. Expressing of constraints (e.g. number of times an element can/should appear) is directly and naturally supported by XSD.
CON: Degree of difficulty. In my experience, I have found that most professional Java developers tend not to be fluent in XML Schema. Thus there can be a learning curve.
Java-To-XML:
PRO: Fast, efficient development. Look at the JAX-RS and JAX-WS specs (implemented in tools such as Apache CXF). These APIs apply annotations to Java interfaces to produce web services. The web service contracts (i.e. the WDSL/WADL in XSD) are auto-generated by the web service framework. The advantage here is that Java developers can work entirely in Java. No need to learn XSD.
CON: Because the interface is generated, it is not a first-class artifact. It cannot easily be shared with consumers of your service. It also means that a Java developer could change part of the Java interface, and inadvertently change the service contract. I have seen this happen. A change to the structure of an object (which BTW is not even a method signature change) can alter the XSD.

External Systems Integration Best Practice

Quick question on what is the best practice for integrating with external systems.
We have a system that deals with Companies which we represent by our own objects. We also use an external system via SOAP that returns a Organization object. They are very similar but not the same (ours is a subset of theirs).
My question is, should we wrap the SOAP service via a Facade so we return only Company objects to our application, or should we return another type of object (e.g. OrgCompany), or even just use the Organization object in our code.
The SOAP service and Organization object are defined by an external company (a bank), who we have no control over.
Any advice and justification is much appreciated.

My two cents, Introducing external objects into application is always a problem. Especially during maintenance. A small service change might lead into big code change in the application.
It's always good to have a layer abstraction between the external service and application. I would suggest to create a service layer which will do the translation of external service object to your application domain objects and use them within the application. A clear separation / decoupling helps a lot in maintenance.
The below diagram depicts the above content.

Your decision here is how you want to manage external code dependencies in your application. Some factors that should play into your decision:
1) How often will the API change, and what's the expected nature of the changes?
2) What's the utility of your application outside its depdencies? If you removed the SOAP service dependency, would your app still serve a purpose?
A defensive approach is to build a facade or adapter around SOAP service, so that your code only depends on your object model. This gives you a lot of control and a relatively loose coupling between your code/logic and the service. The price that you pay for this control is that when the SOAP contract changes, you must also usually also change a layer of your code.
A different approach is to use the objects you're getting from the WSDL directly. This is beneficial when it doesn't make sense to introduce a level of indirection in your application between the client code, i.e. your application is just a feeder into a different system and the whole point of the app is to stuff the Organization object into a JMS pipeline or something similar. If the SOAP API contract never changes and you don't expect the output of your app to change much, then introducing an extra layer of indirection will just hinder the readability of your codebase long term.
Most j2ee developers tend to take the former approach in my experience, both because of the nature of their applications, and wanting to separate their application logic from the details of the data source.
hope this helps.

I can't think of any situation where it's good to use the objects that another company controls. The first thing you should do is bridge those objects into your own. Also, by having your own objects, you can expand their functionality beyond the one that is provided by the third party you connect to (for example if in the future you need to talk to more than one Company object provider)
Look at the Adapter pattern.

I'd support Sridhars suggestion, I'd like just to add that for translating external service objects to your application domain you can use Dozer :
http://dozer.sourceforge.net/documentation/mappings.html

I typically always Adapt externally defined domain objects to an internal representation.
I also create a comprehensive suite of tests against the external domain object, that will highlight any problems quickly if the external vendor produces a new release.

The Enterprise service bus Architecture might be useful here
Its primary use is in Enterprise Application Integration of
heterogeneous and complex landscapes.
(from Wikipedia)
I would check out open source Mule if you are looking for an open source solution

Annotating REST web service in Java EE 6

I am making a web service with Java EE 6. From what I understand you can annotate either the local interface with the #Path/#GET etc. annotations or the no-interface bean. I wonder if it is common to make two interfaces; one for the web services with the annotations and another one for the local interface? Or do you just add them on the local interface?

If I understand your question, your asking if you should define an interface just for specifying the annotations. I'm not sure what the advantages would be of doing this, unless you had a really complex project and foresee yourself replacing the Web service annotations with another library. This library would have to be on its virtual deathbed in terms of future support, or there would need to be clear evidence that our CTO would be changing technologies for me to consider this strategy.
For most projects, this seems to be somewhat of an overkill, especially if you already have an interface defined for your controller that you can add those annotations to. As a colleague on your project, I wouldn't want to have to check 3 different files for annotations for 1 class, unless there was a very compelling reason to do so.
With that said, if you wanted to add the annotations to your interface or your subclass, this is supported in this example. However, I think you would want to be sure to create a clear standard, either all your REST annotations are on the interface or all of your annotations are on the subclass. Mixing and matching them could get confusing for someone new to the project.
Without actually seeing your code and how complex it is, I can't tell you which method would be best for your project. The important thing is to balance consistency with flexibility. In summary, Java gives you plenty of rope, which equals flexibility, but you can also hang yourself with that rope if you're not careful. :)

SOAP to Restlets strategy for multiple methods

I've been working with the Restlet library for the last couple weeks and from what I can see it is fairly impressive. The ability to be able to define a common interface for consumption by both the client and server surpasses any messy soap frameworks I've worked with.
However, something has been plaguing my mind that I just can get past:
Is there a good way to define Restlets with many methods?
My primary use case is that I have a soap web service that has 10-15 or so methods in it. As I see it, if I wish to translate this over to a Restlet I will need to separate this out into 8-15 interfaces depending on which methods become get methods vs post or put - I don't think you can have more than one verb method (get, post, put, etc) per interface. This seems like a cumbersome and clumsy solution.
I've thought of using some type of factory\map technique to mitigate this - but I wanted to make sure I'm not missing something better first.
Thanks

Even though coming from a SOAP background, it might be surprising, what you observe it actually a good thing because your web API is becoming more and more RESTful.
In REST/HTTP, methods are standard and limited (by design) and to compensate we create as many resources/URis as necessary.
Regarding JAX-RS, it doesn't have the same client/server uniformity. I would recommend staying with the core Restlet API in general as it is more powerful/extensible.
If you could list your method names, that would help suggest a proper mapping to HTTP resource and methods, I'm not sure you need that many interfaces in the end. Even if this is the case, there server-side implementation will be easy and more maintainable which also has benefits.
Hope this helps

There's a JAX-RS extension for Restlet. JAX-RS provides the #Path annotation that is used identify the URI of the resource. Paths can be attached either to the type or to a method. Routing should be then done by the container instead of explicitly defining router rules.