SOAP

Motivation for learning (problem & outside events that effected to learn about this topic )
When I did Software Development Frameworks, there was a requirement in the assignment to use the Web Services. Our group developed a website for a hotel in Maldives. We decided to use web services to get weather information from the Department of Meteorology website. So as once they update the weather, from our website also the weather gets updated. But we all had a problem, in identifying how to use it. We had no idea about what language or the platform that they have used to develop the weather information website. Somehow we were able to complete, as some of our group members knew about a good way to do it. But when it comes to me, I am totally clueless.

When I develop software I have to rely on calling different procedures to provide functionality. So I will have to put all the procedures into an object. These objects should be created in a way that this can be reused in the future for different systems for different developers. But what happens when the objects are platform specific? As objects created for one platform cannot access the objects of another platform. Calling methods from objects through the internet is difficult. Hence the current distributed technologies require the use of special ports to transmit their data. Most of the corporate firewalls block all the other ports except port 80, which is the default port for HTTP. Most of the administrators fear opening up the other ports, which could pose a potential security problem. So with all these problems how can applications communicate through internet?
To make this happen there is a need for a :
• Platform independent way to call methods located on diverse distributed systems.
• A firewall-friendly way to make the remote call procedures over internet.
• A technology which is light weight and easy to use and cater for the problems.

What is SOAP
(insight Solution)
SOAP is a solution for this. It is a Simple Object Access Protocol that allows accessing an object through the net. It is a platform and language independent communication XML based protocol. Or more simply: SOAP is a protocol for accessing a Web Service and it cold be expressed as SOAP = XML + HTTP. And SOAP is able to leap through firewalls in a single bound. This is possible because it uses XML documents which can easily be transported via HTTP through firewalls without security risks. Furthermore it is light weight and easy to understand and use.

A soap Transaction
(plan of achieving the solutions encountered)
SOAP solves the problems through the use of this plan.

• Messages are sent in a familiar request/response fashion.
• SOAP defines an XML structure to call a method and pass the method through parameters.
• It also defines an XML structure to return values that were requested.
• SOAP defines an XML structure to return the error values (faults) if the service provider cannot execute the requested method.
• Here is a typical diagram that illustrates how SOAP work.

A SOAP transaction begins with an application making a call to a remote procedure. The SOAP client script then encodes the procedure request as an XML payload and sends it over the transport protocol to a server script. The server parses the request and passes it to a local method of the remote object, which returns a response. The response is encoded as XML by the server and returned as a response to the client, which parses the response and passes the result to the original function.


SOAP Syntax

(SOAP Building Blocks and Rules)

• A SOAP message is an ordinary XML document containing the following elements:
• A required Envelope element that identifies the XML document as a SOAP message
• An optional Header element that contains header information
• A required Body element that contains call and response information
• An optional Fault element that provides information about errors that occurred while processing the message

Syntax Rules
Here are some important syntax rules:

• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

The SOAP Message

• HTTP: Responsible for sending SOAP messages back and forth. It’s the equivalent of a postman carrying the SOAP envelope in his hand to the destination.
• SOAP Header: The optional SOAP Header element contains application specific information (like authentication, payment, etc) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. It tells the receiving system how to handle the incoming message without requiring the receiver to look inside and deduce the content is SOAP content. If a SOAP server is ready to use, you just need to determine if the server adds anything when this header is present.
• A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path.
• The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.
• Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines one element inside the Body element in the default namespace.
• ENVELOPE: Creating a SOAP message is a bit like writing and mailing a letter. Once you’ve created a SOAP message, put it in a SOAP envelope and write instructions on the front.

Here’s what a SOAP envelope looks like:

The ellipses (three dots) indicate where the letter and other content goes.
This is the third set of tags you’ll need. The ,

, and tags (case-sensitive!) are all specified for you by the SOAP standard—they describe the pieces of the envelope that surrounds the SOAP data, even though the envelope is technically separate from the data you’re actually trying to send. The whole thing is called a “SOAP message.”

Skeleton of a SOAP Message.



xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

...
...


...
...

...
...









A SOAP message must always have an Envelope element associated with the "http://www.w3.org/2001/12/soap-envelope" namespace.
If a different namespace is used, the application must generate an error and discard the message.

The encodingStyle Attribute
The SOAP encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements. A SOAP message has no default encoding.

Syntax
soap:encodingStyle="URI"

USING SOAP In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter will be returned in the response. The namespace for the function is defined in "http://www.example.org/stock" address.


The SOAP REQUEST

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn



xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">


IBM



>


The SOAP Response

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


Standard SOAP Fault Codes

The optional SOAP Fault element is used to hold error and status information for a SOAP message. An error message from a SOAP message is carried inside a Fault element.
If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.

The standard SOAP fault codes include:

• Version Mismatch
• Misunderstand: specify which header blocks were not understood
• Server: error can’t be directly linked to the processing of the message
• Client: there is a problem in the message (e.g. invalid authentication credentials.
• Misunderstood Header

What SOAP doesn’t do?

• The SOAP specification doesn’t define how the requestor or the responder send and receive messages.

• The implementation of sending and receiving is up to the developer.

• The SOAP doesn’t define how a message will create an instance of an object and execute the method. Implementation details are left to the software developer or a third party software vendor.

Conclusion(Knowledge Acquisition)

This journal has helped me to gain knowledge on SOAP, and I learnt about how to use it for requesting and sending responses for applications.

SOAP is a protocol for passing messages. The most common arrangement for SOAP messages is a request/response pair, basically a question and answer. HTML form submission is also a request-response pair. SOAP is to form submission a bit as if Microsoft Windows is to DOS. DOS does a basic job, which is great if that’s all you want. Windows is more complicated, but once you have learned the detail, it’s more powerful too. You can mimic SOAP concepts with plain HTML forms, but for the real thing, learn the SOAP syntax and buy some three-phase power tools.
• In the deployment of the web services the SOAP acts as a:
• Listener to receive message
• Proxy to take message and translate it into an action to be carried out
• Application code to implement that action

SOAP in short:
• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls

There is a lot more in SOAP. But I am sure that I will not need to learn the whole SOAP inorder to understand all of it.

Total Hours Spent in learning: 11 Hours 45 mins

Builder Pattern

Learning Journal on Builder Pattern

Author: Aiesha Adnan

Motivation for Learning(Problem)
In the class I learned about the Factory pattern.This pattern defines an interface for creating an object, but let subclasses decide which class to instantiate. However it doesnot have a mechanism to separate the construction of complex object from its representations and provide more complex objects.The Factory patterns idea is about what is created.Not how it is created. Therefore I had an idea to learn about a design pattern which provides the step by step procedure in creating the final product,depending on data,where I will have more control over a product that is build. Then I came across the Builder Pattern which is coming under creational pattern, which can show me the details of the objects that I create ,which is absent in factory pattern.

What is Builder Pattern(insight Solution)
The Builder Pattern assembles a number of objects, such as display widgets, in various ways depending on the data. Furthermore, since Java is one of the few languages where you can cleanly separate the data from the display methods into simple objects, Java is the ideal language to implement Builder patterns.
The builder pattern can be used when
• You need to keep the algorithm of creating a complex object separate from the parts that make it up.
• The construction process must allow different representations for the object that’s constructed
This is what I am exactly looking for.

Implementing Builder pattern(plan of achieving the solutions encountered)

Decide if a common input and many possible representations (or outputs) is the problem at hand.
Encapsulate the parsing of the common input in a Director class.

1. Design a standard protocol for creating all possible output representations.
2. Capture the steps of this protocol in a Builder interface.
   
3. Define a Builder derived class for each target representation.
   
4. The client creates a Director object and a Builder object, and registers the latter with the former.
   
5. The client asks the Director to "construct".
   
6. The client asks the Builder to return the result.

Understanding the Structure of Builder Pattern

Creating a director
The Director in the pattern is represented by Waiter . The director ensures that the steps are executed in the right order. In our case the director, an experienced Waiter , knows the order in which the steps must be executed in order to ensure that the pizza is made properly and orders the pizza builder to carry out each step in turn. So he may call the pizza builder and tell him to get going, then call out the following instructions in the constructor of this class which the pizza builder must execute in the following order.

/** "Director" */
class Waiter
{
private PizzaBuilder pizzaBuilder;
public void setPizzaBuilder(PizzaBuilder pb)
{
pizzaBuilder = pb;
}
public Pizza getPizza()
{
return pizzaBuilder.getPizza();
}
public void constructPizza()
{
pizzaBuilder.createNewPizzaProduct();
pizzaBuilder.buildDough();
pizzaBuilder.buildSauce();
pizzaBuilder.buildTopping();
}
}

Note something very important here though. The PizzaBuilder has a communication problem and only gets along with people he has known for a long time. So we shield the PizzaBuilder from the flightiness of the Specialist PizzaBuilder and he only deals with the PizzaBuilder who has been around since the restaurant started. So in reality, he speaks to the Specialist PizzaBuilder through the PizzaBuilder . He never knows the specialist PizzaBuilder on duty and doesn't care. Now the PizzaBuilder implements the step that she can, but passes on the specialized steps to the Specialist. In so doing, we get our pizza made, but without any direct contact between the PizzaBuilder (Director) and Specialist PizzaBuilder (Abstract Builder). This is just as well because they are easily offended and the fact that the PizzaBuilder cannot remember their names is very offensive to each of them.

Creating a Builder

The Abstract-Builder in the pattern is represented by a PizzaBuilder,who knows ALL the steps which are needed for composing the complex object. Because all our specialist PizzaBuildersare familiar with the steps needed for making the pizza, it ensures that there is expertise in all the steps to be executed. The PizzaBuilder interviews all specialist Pizza Builders before they can be employed in the restaurant. She ensures that the Specialist PizzaBuilder is expert in all the steps which are specific to the kind of pizza they are supposed to be making. The Abstract Builder source code shows the steps.It doesn’t need to be in order.Note also that some of the steps are already filled in.


/** "Abstract Builder" */
abstract class PizzaBuilder
{
protected Pizza pizza;

public Pizza getPizza()
{
return pizza;
}
public void createNewPizzaProduct()
{
pizza = new Pizza();
}

public abstract void buildDough();
public abstract void buildSauce();
public abstract void buildTopping();
}

Creating the concrete builder

Each type of product (pizza) which can be created is tied to one specialist Pizza Builder. He knows how to carry out each of the steps in the general recipe for the particular type of pizza he makes and so we can consider him to be an extension of the Pizza Builder. However each pizza Builder can make only the type of pizza which he specializes in. So here I have have the HawaiianPizzaBuilder and SpicyPizzaBuilder.Here HawaiianPizzaBuilder can make Hawaiian Pizza and the SpicyPizzaBuilder must know how to carry out all the steps which apply to the making of a Spicy Pizza . In reality he only needs to know the steps that the SpicyPizzaBuilder and the HawaiianPizzaBuilder needs to know are represented in the source code of each class. The specialist PizzaBuilder can override the PizzaBuilder . Since knowledge of the steps must reflect all the steps as outlined by the PizzaBuilder, it ensures that the Specialist PizzaBuilder is in a position to do all the steps. The great thing though is that we can customize the pizza we make by changing the Specialist PizzaBuilder we use to make it. Because all specialists know the steps relevant to their pizza, it ensures our pizza is made completely. Each specific PizzaBuilder in this example reflects the role of the concrete-builder in the Builder pattern. Note very importantly, that in this example, the specialist PizzaBuilder do not know the order in which the steps are carried out. As we will see, the PizzaBuilder knows the order of the steps and will take care of the sequencing requirement.



/** "ConcreteBuilder" */
class HawaiianPizzaBuilder extends PizzaBuilder
{
public void buildDough()
{
pizza.setDough("cross");
}
public void buildSauce()
{
pizza.setSauce("mild");
}
public void buildTopping()
{
pizza.setTopping("ham+pineapple");
}
}


/** "ConcreteBuilder" */
class SpicyPizzaBuilder extends PizzaBuilder
{
public void buildDough()
{
pizza.setDough("pan baked");
}
public void buildSauce()
{
pizza.setSauce("hot");
}
public void buildTopping()
{
pizza.setTopping("pepperoni+salami");
}
}

Creating the Product

The complex object in our example is the pizza and it reflects the role of the concrete product in the builder pattern. Remember each concrete product is built by only one builder. In fact selecting the builder is in effect, selecting the product. So when we select the SpicyPizzaBuilder , we are guaranteed to get back a Spicy pizza .


/** "Product" */
class Pizza
{
private String dough = "";
private String sauce = "";
private String topping = "";

public void setDough(String dough)
{ this.dough = dough; }
public void setSauce(String sauce)
{ this.sauce = sauce; }
public void setTopping(String topping)
{ this.topping = topping; }
}


Creating the Client

The client in the pattern is similar to the customer of the restaurant. In the case of the customer, an order for a particular type of pizza (or concrete product) is made. The client in the pattern knows all about the available products and knows which concrete-builder is responsible for each product. In fact the customers customers even know the names of the specialist pizzaBuilders who work for the restaurant and the type of specialty pizza that they make.In the class below the customer orders for a “hawaiianPizza”,look at the codes.

/** A customer ordering a pizza. */
class BuilderExample
{
public static void main(String[] args)
{
String top = "pepperoni+salami";


Waiter waiter = new Waiter();
PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder();

waiter.setPizzaBuilder( hawaiianPizzaBuilder );
waiter.constructPizza();

Pizza pizza = waiter.getPizza();

}
}

Implementation issues to consider ( their solutions too)

• Assembly and construction interface (interface must be general enough, intermediate access may be needed).
• Why no abstract class for products? (usually, the products are too Different)
• Empty methods as default in Builder (clients only override operations of interest.

Conclusion
Through this learning journal I have gained the knowledge of the the builder pattern and the differences between builder pattern and abstract factory pattern.
The intention of the Builder Pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations.

The builder pattern process
The "director" invokes "builder" services as it interprets the external format. The "builder" creates part of the complex object each time it is called and maintains all intermediate state. When the product is finished, the client retrieves the result from the "builder".
Since Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

Significant differences between builder and Factory and Abstract Factory Pattern.

• The factory pattern defers the choice of what concrete type of object to make until run time.
The builder pattern encapsulates the logic of how to puttogether a complex object so that the client just requests a configuration and the builder directs the logic of building it.
• The factory is concerned with what is made, the builder with how it is
made.

Abstract factory is similar to builder in that it too may construct complex objects. The primary difference is that the Builder pattern focuses on constructing a complex object step by step. Abstract factor's emphasis is on families of product objects(either simple or complex).

• Builder returns the product as the final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

Total Hours Spent in learning: 13 Hours 10 minutes

Singleton Pattern

Singleton Pattern
Author: Aiesha Adnan

This is my second journal, which i like to share with those who are looking for ways to use Singleton Pattern.

Motivation for learning (problem )
Design patterns are a new technique that is taught in this unit. Creational pattern deals with object instantiation. Factory pattern is the pattern I studied during the lectures. There are other patterns like Singleton Pattern that comes under the creational pattern. Currently I have no knowledge in this pattern. Besides, I have to apply design patterns in my assignments. I have no idea what it is. Therefore, I feel I should have knowledge in this pattern, if I am to use design patterns in the applications that I develop. Therefore I decided to learn about the single pattern, its structure, how to use it in java.

What is Singleton pattern? (insight Solution)
The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.Java Singleton pattern belongs to the family of design patterns, that govern the instantiation process. Therefore it ensures that at any time there can be only one instance of a singleton(object).

Implementing Singleton pattern (plan of achieving the solutions encountered)
There is actually only one class that needs to be written specially to implement the Singleton pattern. A second client class will always be involved take make requests from the singleton.

Preventing direct instantiation
In order to prevent the direct instantiation create a class with the constructor marked as private. Therefore, those other classes cannot create a new instance.
public class SingletonObjectDemo{
private static SingletonObject singletonObject;

//Note that the constructor is private
private SingletonObjectDemo (){
// Optional Code
}

Using the singleton object
This is the client, which will use this pattern. It creates an object of the singleton object and use it.

public class SingletonObjectDemo{
public static void main(String args[]){

//create the Singleton Object..
SingletonClass obj = SingletonClass.getSingletonObject();

System.out.println("Singleton object obtained"); }
}

Overcoming some practical problems

1. Thread Problems
As with the current way of implementing the access method can be called twice from two different places simultaneously which will lead to the creation of more than one object at a time. It could happen that the access method may be called twice from 2 different classes at the same time and hence more than one singleton object being created. If this happens this would definitely violate the singleton pattern principles. Therefore, add the synchronized keyword to he method as below.

public static synchronized SingletonClass getSingletonObject()

2. Cloning
It is still possible to create a copy of copy of the Object by cloning it using the Object’s clone method.such as below.

SingletonObjectDemo clonedObject = (SingletonObjectDemo) obj.clone();

This again violates the Singleton Design Pattern's objective.Inorder to deal with this, it is necessary to override the override the Object’s clone method which throws a CloneNotSupportedException exception.This will ensure that cloning is not supported.

public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}

Final Implementation

class SingletonClass{

private static SingletonClass singletonObject;

/** A private Constructor prevents any other class from instantiating. */
private SingletonClass(){
// Optional Code
}

public static synchronized SingletonClass getSingletonObject()
{
if (singletonObject == null){
singletonObject = new SingletonClass();
}
return singletonObject;
}

public Object clone()throws CloneNotSupportedException
{

throw new CloneNotSupportedException();
}

}
//this is the client program.
public class SingletonObjectDemo{
public static void main(String args[]){
// SingletonClass obj = new SingletonClass(); Compilation error not allowed

//create the Singleton Object..
SingletonClass obj = SingletonClass.getSingletonObject();

System.out.println("Singleton object");
}
}

Finally, there is an output, which indicates that the object is created.

Consequences of using it.

Singleton pattern can be used in any application which requires an object to be instantiated only once at a time.
Singleton pattern is best when developing a Java Help Module in a project can use a singleton pattern as at any time the developers can use with only one main Help object and use the same object in different screens.

Another usage would be to create a connection pool, which will help to avoid the wastage of resources where, a singleton pattern can be used to maintain a single connection object, which can be used throughout the java applications.
• State objects are often Singletons.
• Singletons are often preferred to global variables because:
o They don't pollute the global namespace (or, in languages with namespaces, their containing namespace) with unnecessary variables.

Conclusion
This journal has helped to understand the singleton pattern structure and how it can be implemented. Singleton pattern provides easy ways for unique object instantiation. In java, it is simple to create a singleton pattern. In the future projects I would be happy to apply singleton pattern.
Total Hours Spent in learning: 12 Hours 30 minutes

Xtreme Programming

LEARNING JOURNAL ON XP - WEEK 1

AUTHOR : AIESHATH ADNAN

(this is my first journal, i would like to share it with people who wants to know the basics of Xp)

Date
11/07/2007

What’s Happening
Motivation for learning (problem )----What I think about that (Reflections)
In the second year, I did a project for Information Technology project. This project involved developing an Information System.Inorder to develop the information System, Waterfall model was used. We were able to complete the project. However we faced some problems, like:
• Idealized, does not match reality well.
• Once a stage is finished, some members like the analyst has no more work to do.
• Does not reflect iterative nature of exploratory development.
• Unrealistic to expect accurate requirements so early in project
• System was delivered late in project, delays discovery of serious errors
• Difficult to integrate risk management
• Difficult and expensive to make changes
• Significant administrative overhead, costly for small teams and projects
Since then I have been thinking what could be the model, which I can use to overcome the above-mentioned problems of the waterfall model. Then I came across Extreme Programming (XP), which can be a solution to the problems mentioned above. , I decided to learn about it and here I represent what I learnt.

11/07/2007
What is Extreme programming?(insight solution)
Extreme programming is a software development paradigm encompassing on a set of rules and practices that occur within the context of four framework activities: planning, designing, coding and testing.

11/07/2007 What are the steps in it?(plan of achieving the solutions encountered)

The solution to the problems I faced can be overcome by applying these steps, which are the four framework activities in Extreme programming.

Planning:

The planning phase begins the client providing the functional requirement as a set of user stories. These user stories can be printed or written on card. The user stories include the functions and their priority level to the client. The client can write new user stories at anytime in the development.
The project meets for release planning. The project team evaluates the story an assigns cost, which is measured in development weeks. There by at the end of the meeting a release plan is produced which indicates iteration plans for each individual plan. Once the first project release has been delivered, the Xpers computes the project velocity. The release plans are always modifiable.

Design
The designing of the system architecture follows the KIS (keep it simple) principle. I find that the design phase of XP is very different from in other development methodologies like waterfall model. The software in object-oriented context, XP encourages using the CRC cards. If a difficult design has been identified a spike solution is created. A spike solution is an operational prototype of that portion of the design.. Xp encourages using a construction and a design technique called refactoring. In Xp, the design is viewed as a passing artifact
that can and should be continually modified as the construction follows.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure. I think that this is unique to XP.

Coding
In Xp before the coding begins, the team should develop a series of unit tests. AS with the unit tests the developer will be able to identify what must be done to pass the unit test.
Again, another unique concept in coding pair programming.Xp recommends that two people work together in the same workstation to create code for a story. During the coding, the developers cannot add anything extra. This means if the developer has something, innovative it cannot be added. Once the pair programmers complete their code, all the codes from other developers are integrated.

Testing
As already indicated in the coding a unit test has to be created before the coding. Just like some of the other development methodologies, Acceptance testing has to be carried out in XP. One or more automated acceptance testing must be created to verify that the user code has been written correctly.

12/07/2007---What is the practical problem associated it?

As with the knowledge I have gained, I discussed it with some friends. They agreed with me to develop a simple Active Ad that analyses the content of a webpage and identifies some key terms.
One of the friends served as the customer, while none of us served as the XP coach. Although I had some knowledge in Xp’s practices and values, I took this opportunity as a challenge, to see how Xp is implemented in real world.
We discussed briefly how the Xp works. There were two user stories. Planning the Game was completed by Production code was written using pair programming.

12/07/2007----Problems identified----
1. Although the customer was always available, there were times that we made assumptions for some parts
2. We also had the difficulty of the concept of the collective ownership: as we were reluctant to fix the errors in the code written by the others.
3. During pair programming, sometimes when one member codes, the other gets bored.
4. As with the integration, most of us tried to collect the codes, rather than integrating and testing it. This brought much confusion during the integration.

No body was confident with the product. As everyone has innovative ways to enhance the product.

15/07/2007---What could be the potential solutions?

Even though the product was developed, I believe that there was only one deficiencies in our application. That is our team’s inadequate introduction to Xp’s Values and practices. Consequently, the following changes could be applied to make it effective.

1. Communicate and get feedback from the customers and the team whenever there is a problem.
2. Make the developers understand that Collective Ownership is something important in Xp.There is no harm in doing that.
3. Allocate time for each developer to work with codes, while the other has to think about the problems that will encounter with the codes. When there is boredom, give sometime for the developer allow the coder to take breaks.
4. IF Xp is a new concept to the team, to start the project choose volunteers

5. Devote some time within the team to discuss in detail the Xp practices and values separated by the team functions. Such as for the developers it is always good to explain the concept of pair programming


13/07/2007---(Knowledge and Learning Acquisition)----

For developers, XP allows to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent time each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.
For the Customer (often a Product Manager), XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.
For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention