The problem here is that this is a "complicated" problem that requires the knowledge of several (very difficult) technical areas. Maybe you think that this is "just playing around with xml" but the truth is that it isn't, especially if the server supports multiple users in parallel. Every network related task is difficult if we are speaking about a reliable correct solution and almost everything that is network related involves multithreading that is one of the most difficult topics in programming. Very few people can implement correct, well designed, maintainable multithreading. You should study the building blocks separately before putting them together to form something useful.
Building blocks in the order in which you should start learning:
- blocking and async socket based networking techniques (TCP)
- serialization (easy in java)
- simple xml manipulation or any other kind of server side tasks
Multithreading: You can say that you have a clue if you can solve the following problems effectively, you and others must be satisfied with the solution even from a design perspective:
- multithreaded merge sorter
- a gui program that copies a file in the background, the gui includes a progressbar, a cancel and pause button
Network programming is a very-very difficult topic, the same problem can be solved in several ways, often the right solution is a hybrid of techniques. Blocking, single/multi-threaded async, blocking interface implemented with single-threaded-async internals, ...
- Blocking socket handling is easier, but you can implement reliable blocking socket programs only with the knowledge of at least single-threaded async socket programming.
As your first networking program put together a client server program pair in which the client connects to the server, uploads a file and then disconnects. The server must handle only one client, and after receiving the file it can exit. Later as a next step put in error handling, if the data transfer stops for more than 1 minutes on either side (predefinied time, I usually use 10-15 mins) then treat the connection as dead. This can happen for example if the client or server freezes, and often if the network connection dies physically while the tcp communication is idle. With simple blocking sockets you can easily get stuck. To introduce this error handling you have to be familiar with single threaded async socket programming (select function, WSAWaitForMultipleEvents) or there are some nonportalbe socket options to avoid this with simple blocking sockets. Later you can improve the feature set of the server, it doesn't quit after serving the client, it accepts another client and serves them serially. Later the server can serve the clients in parallel - depending on the kind of server side tasks and the requirements (for example requests/second, number of parallel clients) you will have lot of possibilities to play around if you have good networking/multithreading knowledge.
Serialization: Networking is often about sending a request from the clients, performing the requests on the server and then sending back the result. To send the parameters and receive the result you have to convert them to binary format because often these parameters/results are objects (especially in java) and you simply can not send objects over communication channels. Converting the objects to sendable binary format is serialization, and the reverse of the process is deserialization. This is very easy in java.
How to combine the above components into a networking program? Networking from the perspective of client side is often like performing a function call:
* on the client side you pack together (serialize) the parameters of the "function call"
* you send the parameters through the communication channel (socket, pipe, shared memory, ...) to the server
* on the server side you unpack the data, you convert the binary stuff to "objects" again if needed (deserialization)
* using the unpacked data you execute the server side code/logic that is often single threaded, multithreading is needed only by the networking engine if support of multiple parallel clients is a must. Executing the server side logic with the incoming parameters outputs the result of the "functioncall" needed by the client.
* you convert (serialize) the result to binary stuff to be able to send it back to the client over the communication channel to the client
* on the client side you receive the result of the "function call" and unpack (deserialize) it for use
In your case (xml manipulation) you have to decide what are your "function calls" and sometimes in case of server/client side programming you have to introduce server side state with login (session) that is usually alive while the connection is active or in case of stateless connection (for example http) the session expires with timeout if the last request received by teh server was too long ago (session expiration time). If there is not strong connection between two "function calls"/network requests of the client than server side state management (session) isn't needed. For example your function calls are the following:
- upload xml
- delete xml
- download xml
But if your "function calls" are the following:
- upload xml
- open xml
- write previously opened xml
- close xml
... then there is a relation between different function calls, the server must know about the "previously opened xml" and this state must be stored along with your connection state/session info but this is something more advanced, an additional well separated layer on top of the networking layer/communication channel layer.
As you see if your software design is good you can replace the building blocks with different solutions, if there is good separation between the solutions of different problems/tasks. Such an important building block is the "communication channel". In my networking programs it is often possible to replace the client side communication channel with a special "null" communciation channel that is nothing more that a piece of code that receives the serialized incoming parameters from the clinet and instead of sending them over network it deserializes the data and calls the server side logic directly. Of course the server side logic is statically linked to my program and the "server" in this case is single threaded single user. This is often called "in-proc" server and allows you to debug a lot of kind of bugs easily by being able to debug the client and server side code together.
Use google to find learning material about the building blocks. Progress in order, don't want to build something complicated without knowing the basics. The most important part of software development is the good design and good separation between the building blocks (Separation of concerns
] usually with interfaces or at least theoretically when deciding where to put the solution of different problems in your code) when it is reasonable.
EDIT: In java you can simplify the coding of the network part with pre-baked solutions (like rmi) but it is still nice thing to understand how networking stuff works inside. Even in case of pre-baked solutions its important to understand how multithreading works and by using pre-baked solutions you often narrow down the types of networking techniques you can implement. The best to start network programming is by using a "low-level" programming language (C,C++,pascal) that gives access to the berkeley socket api, in java you have access only to a subset of the capabilities provided by the native networking api of your operating system. Of course this is not an issue if you are okay with pre-baked solutions and frameworks and you are not interested in the details.