Spring Bean Basics

1. If we want to access Beans in different XML Configuration files use ref tag bean attribute.
    example :

2.If we want to access Beans in same XML Configuration file use ref tag local attribute.
   example :

3..The ref tag can access bean in same or different XML file.For readability purpose we  use   local to refer to bean in same XML file.

4.In Spring there are 3 ways to inject values into  bean properties
  • Normal way :inject value using property tag.
        
               rest
         

  • Shortcut:inject value with "value" attribute.
         

  •  Using "p" schema  :  Inject values using P schemas an attributes.
         
               .....................................
              xmlns:p = http://org.springframework.com/schema/p
             
                p:name ="test" p:type = "rest"  />
        

              
5. In Large projects there are multiple configurations located at different folders for maintainability and modular.Better way to organize all spring bean configuration in single XML file and import all file resources.

 example: spring_combine.xml



.......................





Now Load all single XML file using

ApplicationContext context = new ClassPathXmlApplicationContext ("spring_combine.xml");


Then put this file under classpath

  classpath/spring_combine.xml

6. In Spring Framework,whenever a bean is used for only one particular property,it's  advise to declare it as an inner bean.And the inner bean is supported both in setter injection "property"
and constructor injection "constructor-arg".


 xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
 
  id="CustomerBean" class="com.test.common.Customer">
   name="person" ref="PersonBean" />
 
>   id="PersonBean" class="com.test.common.Person"> name="name" value="test" /> name="address" value="address1" /> name="age" value="28" /> >   >
In general, it’s fine to reference like this, but since the ‘test’ person bean is only used for Customer bean only, it’s better to declare this ‘test’ person as an inner bean as following :
 xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
 
  id="CustomerBean" class="com.test.common.Customer">
   name="person">
    class="com.test.common.Person">
     name="name" value="test" />
     name="address" value="address1" />
     name="age" value="28" />
   
> > > >
This inner bean also supported in constructor injection as following :
 xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
 
  id="CustomerBean" class="com.test.common.Customer">
  >
    class="com.test.common.Person">
     name="name" value="test" />
     name="address" value="address1" />
     name="age" value="28" />
   
> > > >
Run it
package com.test.common;
 
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
 
public class App 
{
    public static void main( String[] args )
    {
     ApplicationContext context = 
       new ClassPathXmlApplicationContext(new String[] {"Spring-Customer.xml"});
 
     Customer cust = (Customer)context.getBean("CustomerBean");
     System.out.println(cust);
 
    }
}
Output
Customer [person=Person [address=address1, age=28, name=test]]
  ref :http://www.mkyong.com/tutorials/spring-tutorials/
 7. 5 types of bean scopes supported :
  1. singleton – Return a single bean instance per Spring IoC container
  2. prototype – Return a new bean instance each time when requested
  3. request – Return a single bean instance per HTTP request. *
  4. session – Return a single bean instance per HTTP session. *
  5. globalSession – Return a single bean instance per global HTTP session. *
In most cases, you may only deal with the Spring’s core scope – singleton and prototype, and the default scope is singleton.
In Singleton scope getBean() returns only one instance.
In Proptotype scope for every call of getBean() returns new instance.
Scope can be declared 
  •    in XML configuration file by using "scope"  tag.
                 ex:
  •       Using annotaion
    @Service
    @Scope("prototype")
    public class CustomerService {.......}
      and Enabling the component scan by
      base-package="com.test.customer" />
     
8.     
Spring examples to show you how to inject values into collections type (List, Set, Map, and Properties). 4 major collection types are supported :
List,Set,Map and properties
configutraion file example :
  id="CustomerBean" class="com.test.common.Customer">
 
  
   name="lists">
   >
    >1
> bean="PersonBean" /> class="com.mkyong.common.Person"> name="name" value="testList" /> name="address" value="address" /> name="age" value="28" /> > > >   name="sets"> > >1> bean="PersonBean" /> class="com.test.common.Person"> name="name" value="testSet" /> name="address" value="address" /> name="age" value="28" /> > > >   name="maps"> > key="Key 1" value="1" /> key="Key 2" value-ref="PersonBean" /> key="Key 3"> class="com.test.common.Person"> name="name" value="testMap" /> name="address" value="address" /> name="age" value="28" /> > > > >   name="pros"> > key="admin">admin@nospam.com> key="support">support@nospam.com> > >   >   id="PersonBean" class="com.test.common.Person"> name="name" value="test2" /> name="address" value="address 1" /> name="age" value="28" /> >   > run it


import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
 
public class App 
{
    public static void main( String[] args )
    {
     ApplicationContext context = new ClassPathXmlApplicationContext("SpringBeans.xml");
 
     Customer cust = (Customer)context.getBean("CustomerBean");
     System.out.println(cust);
 
    }
}

Output
Customer [
 
lists=[
1, 
Person [address=address 1, age=28, name=test], 
Person [address=address, age=28, name=testList]
], 
 
maps={
key 1=1,
key 2=Person [address=address 1, age=28, name=test1], 
key 3=Person [address=address, age=28, name=testMap]
}, 
 
pros={admin=admin@nospam.com, support=support@nospam.com}, 
 
sets=[
1, 
Person [address=address 1, age=28, name= test1], 
Person [address=address, age=28, name=testSet]]
]
   

Difference between SOAP and RESTful Webservices



SOAP:

1. Developer View: Object oriented 
2. Standards Based: Yes .

SOAP web services are based on SOAP and WS-* specifications

For acquiring security tokens,it uses WS-Trust.

For conveying security tokens, it uses WS-Security

For defining policy, it uses WS-Policy

For suppoting distributed ACID transactions, it uses WS-AtomicTransaction and WS-Coordination

For acquiring interface definitions, it uses WS-MetadataExchange

For providing end-to-end reliability, it uses WS-ReliableMessaging

For establishing security context, it uses WS-SecureConversation

3. Security: SSL, WS-Security .

WS-Security provides end-to-end security covering message integrity and authentication 

4. Transactions : WS-AtomicTransaction 
5. Reliability : WS-ReliableMessaging 
6. Performance: Good 
7. Caching : No
8. Message Size : Heavy, has SOAP and WS-* specific markup
9. Message Communication protocol : XML
10. Message Encoding :Yes

SOAP Web Services support text and binary encoding
11. Service Description :WSDL
12. Human intelligible Payload :No 
13. Developer Tooling :Yes

Complexity of SOAP Web Services dictates the need for using frameworks to facilitate rapid application development.
14. Orientation :Wraps business logic
15. Abbreviation: SOAP stands for Simple Object Access Protocol 
16. Who is using SOAP? Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well. 
17. Simplicity: No
18. Transport protocol support: HTTP, SMTP, JMS

Multiple transport protocol support makes SOAP Web Services flexible

REST:

1. Developer View: Resource Oriented
2. Standards Based: No
3. Security: SSL
4. Transactions : No
5. Reliability :Application specific
6. Performance: Better

Caching and lower message payload makes RESTful web services performance efficient and scalable
7. Caching : GET operations can be cached
8. Message Size : Lightweight, no extra xml markup
9. Message Communication protocol : XML, JSON, other valid MIME type .

This flexibility of REST makes its extremely useful in providing consumer need specific message payloads 
10. Message Encoding : No

RESTful encoding is limited to text 
11. Service Description : No formal contract definition

In REST, no formal way to describe a service interface means more dependence on written documentation
12. Human intelligible Payload : Yes 
13. Developer Tooling : Minimal or none

REST on the other hand due to its simplicity can be developed without any framework
14. Orientation : Accesses resources/data 
15. Abbreviation: REST stands for Representational State Transfer
16. Who is using REST? All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.
17. Simplicity: Yes
18. Transport protocol support: HTTP


Areas where SOAP based WebServices is a great solution:


Asynchronous processing and invocation: If application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging etc.
Formal contracts: If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
Stateful operations: If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing. 

Areas where RESTful WebServices are a great choice:


Limited bandwidth and resources: Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
Totally stateless operations: If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is suitable.
Caching situations: If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.







REST is almost always going to be faster. The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence. 


REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.


In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option.

1) REST is more simple and easy to use than SOAP
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's.
4) REST supports different format like text, JSON and XML while SOAP only support XML.
5) REST web services call can be cached to improve performance.
 



ref :https://sites.google.com/site/interviewsharing/asp-net/difference-between-soap-and-restful-webservices

http://javarevisited.blogspot.com/2012/01/rest-web-services-framework-interview.html

Agile Methodology

What Is Agile?

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, itÂ’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.

Where Did Agile Come From?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.
ItÂ’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. CouldnÂ’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?

Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.

ref:http://agilemethodology.org/
http://www.versionone.com/Agile101/Agile_Development.asp


Design Principles

1.Identify the aspects of your application that vary and separate them from what stays the same.

2.Program to an interface, not an implementation.

3.Favor composition over inheritance.

4.Classes should be open for extension, but closed for modification.

-The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Observer Pattern
� The Observer Pattern defines a one-to-many relationship between objects.
� Subjects, or as we also know them, Observables, update Observers using a common interface.
� Observers are loosely coupled in that the Observable knows nothing about them, other than that they implement the Observer Interface.
� You can push or pull data from the Observable when using the pattern (pull is considered
more “correct”).
� Don’t depend on a specific order of notifcation for your Observers.
� Java has several implementations of the Observer Pattern, including the general purpose java.util.Observable.
� Watch out for issues with the java.util.Observable implementation.
� Don’t be afraid to create your own Observable implementation if needed.
� Swing makes heavy use of the Observer Pattern, as do many GUI frameworks.
� You’ll also find the pattern in many other places, including JavaBeans and RMI.


Decorator pattern

The Decorator Pattern attaches additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending functionality.

� Decorators have the same supertype as the objects they decorate.
� You can use one or more decorators to wrap an object.
� Given that the decorator has the same supertype as the object it decorates, we can pass
around a decorated object in place of the original (wrapped) object.
� The decorator adds its own behavior either before and/or after delegating to the object it
decorates to do the rest of the job.
� Objects can be decorated at any time, so we can decorate objects dynamically at runtime
with as many decorators as we like.