Posts Tagged ‘Clients’

English: Gmail logo
Are you disheartened by Gmail’s lack of folders? Folders into which you can stick your emails; folders reminiscent of

drawers or trusty file systems; folders whither you can move messages, even automatically?

Well, they might not be called “folders”, but Gmail’s labels act a lot like folders do. Using filters, you can even have Gmail sort your incoming mail by sender, subject or other criteria to your custom folders — out of the Inbox.

Use Gmail as if It Had Folders and Filters

To make Gmail route certain mail to particular “folders”, bypassing your Inbox:

  • Click Create a filter.
  • Enter the desired criteria.
    • To filter all mail from somebody, type their email address in the From: field, for example.
  • Click Next Step ».
  • Make sure Skip the Inbox is checked.
  • Also check Apply the label:.
  • Select an existing label (folder) from the Choose label… menu or:
    • Select New label….
    • Type the desired name for the label (folder).
    • Click OK.
  • Optionally, check Also apply filter to conversations below to move existing messages matching your criteria to the folder.
  • Click Create Filter.

New messages matching your rules will arrive in their labels (i.e. folders) only. If you keep the Labels box on it and an eye on it, you’ll see labels with new messages highlighted.

Reference:http://email.about.com/od/gmailtips/qt/et_gmail_folder.htm

 

Download this Visual Studio 2005 project Download the Chat Server Application project (Visual Studio 2005)

This is the second part of a tutorial that teaches you how to create a C# chat application. In Part 1 – Building the Chat Clientwe’ve looked at how to create the chat application that connects to a chat server, and here we now look at how to build the chat server.

The Chat Server

The Chat Server application is a tad more complex than the Chat Client application because it needs to hold information on all the connected clients, await for messages from each and send incoming messages to all. I commented all the code so hopefully you won’t have any problems figuring it out without much commentary on the side from me.

Fire up a new instance of Visual Studio 2005 and in a new Windows Application project draw the following form:

Chat Server

The only controls we are interested in are the two TextBoxes (txtIp and txtLog) and the btnListen button. The IP address inside txtIp is the one where you want your chat server to be listening for incoming connections. You should use your local IP address, which if you’re not in a network it could be 192.168.0.1, but it’s best that you check using the ipconfig /all command in the MS-DOS Command Prompt window. The multi-line TextBox will hold information about connected clients and the messages that they are exchanging.

In the code view, start with the following using statements:

using System.Threading;

using System.Net;

using System.Net.Sockets;

using System.IO;

Move inside the class and declare a delagate which we will need in order to update the txtLog TextBox from another thread :

private delegate void UpdateStatusCallback(string strMessage);

Double-click the Start Listening button and you should arrive to it Click event. Have the event handler look like this:

private void btnListen_Click(object sender, EventArgs e)

{

// Parse the server’s IP address out of the TextBox

IPAddress ipAddr = IPAddress.Parse(txtIp.Text);

// Create a new instance of the ChatServer object

ChatServer mainServer = new ChatServer(ipAddr);

// Hook the StatusChanged event handler to mainServer_StatusChanged

ChatServer.StatusChanged += new StatusChangedEventHandler(mainServer_StatusChanged);

// Start listening for connections

mainServer.StartListening();

// Show that we started to listen for connections

txtLog.AppendText(“Monitoring for connections…\r\n”);

}

A couple of objects are being instantiated, including a ChatServer object. We will write the ChatServer class very soon, and you will see that it handles all the incoming connections. In turn, it will make use of another class that we will write, called Connection.
The next thing we do is to set up an event handler for the StatusChanged event, which is a custom event that we’re going to write very soon. It will inform us when a client has connected, a new message has been received, a client has disconnected, etc.
Finally the StartListening() method tells the ChatServer object to start listening for incoming connections.

Believe it or not, there are only a few more lines of code to go in this class. One of them is the event handler that we hooked earlier, and the other is the UpdateStatus() method that gets called when an update needs to be made to the form. It’s needed because we use Invoke() and the delegate we created earlier to make a cross-thread call (since the ChatServer will be working in a different thread):

public void mainServer_StatusChanged(object sender, StatusChangedEventArgs e)

{

// Call the method that updates the form

this.Invoke(new UpdateStatusCallback(this.UpdateStatus), new object[] { e.EventMessage });

}

private void UpdateStatus(string strMessage)

{

// Updates the log with the message

txtLog.AppendText(strMessage + “\r\n”);

}

And we’re done. Done with the Form1 class, of course. You should now create another file (I called mine ChatServer.cs) and inside it make sure you have all these using statements:

using System;

using System.Collections.Generic;

using System.Text;

using System.Net;

using System.Net.Sockets;

using System.IO;

using System.Threading;

using System.Collections;

We’ll need to use an event that notifies the form class when a new client has connected, disconnected, sent a message, etc. In order to create our own custom event, we need to first define its arguments. More exactly we want a string argument that tells us what type of event has occured (user has connected, user has disconnected, user x says y, etc..) If you’re not familiar with events and delegates you might want to read the Delegates and Events in C# tutorial from a week ago. Here is the class that gets and sets the event arguments:

// Holds the arguments for the StatusChanged event

public class StatusChangedEventArgs : EventArgs

{

// The argument we’re interested in is a message describing the event

private string EventMsg;

// Property for retrieving and setting the event message

public string EventMessage

{

get

{

return EventMsg;

}

set

{

EventMsg = value;

}

}

// Constructor for setting the event message

public StatusChangedEventArgs(string strEventMsg)

{

EventMsg = strEventMsg;

}

}

Moving on, outside this class we declare the actual delegate for the event handler:

// This delegate is needed to specify the parameters we’re passing with our event

public delegate void StatusChangedEventHandler(object sender, StatusChangedEventArgs e);

And now before we actually get to fire this event, we define the ChatServer class, in all its glory. Remember this is the class that we used back in Form1.cs:

class ChatServer

{

// This hash table stores users and connections (browsable by user)

public static Hashtable htUsers = new Hashtable(30); // 30 users at one time limit

// This hash table stores connections and users (browsable by connection)

public static Hashtable htConnections = new Hashtable(30); // 30 users at one time limit

// Will store the IP address passed to it

private IPAddress ipAddress;

private TcpClient tcpClient;

// The event and its argument will notify the form when a user has connected, disconnected, send message, etc.

public static event StatusChangedEventHandler StatusChanged;

private static StatusChangedEventArgs e;

// The constructor sets the IP address to the one retrieved by the instantiating object

public ChatServer(IPAddress address)

{

ipAddress = address;

}

// The thread that will hold the connection listener

private Thread thrListener;

// The TCP object that listens for connections

private TcpListener tlsClient;

// Will tell the while loop to keep monitoring for connections

bool ServRunning = false;

// Add the user to the hash tables

public static void AddUser(TcpClient tcpUser, string strUsername)

{

// First add the username and associated connection to both hash tables

ChatServer.htUsers.Add(strUsername, tcpUser);

ChatServer.htConnections.Add(tcpUser, strUsername);

// Tell of the new connection to all other users and to the server form

SendAdminMessage(htConnections[tcpUser] + ” has joined us”);

}

// Remove the user from the hash tables

public static void RemoveUser(TcpClient tcpUser)

{

// If the user is there

if (htConnections[tcpUser] != null)

{

// First show the information and tell the other users about the disconnection

SendAdminMessage(htConnections[tcpUser] + ” has left us”);

// Remove the user from the hash table

ChatServer.htUsers.Remove(ChatServer.htConnections[tcpUser]);

ChatServer.htConnections.Remove(tcpUser);

}

}

// This is called when we want to raise the StatusChanged event

public static void OnStatusChanged(StatusChangedEventArgs e)

{

StatusChangedEventHandler statusHandler = StatusChanged;

if (statusHandler != null)

{

// Invoke the delegate

statusHandler(null, e);

}

}

// Send administrative messages

public static void SendAdminMessage(string Message)

{

StreamWriter swSenderSender;

// First of all, show in our application who says what

e = new StatusChangedEventArgs(“Administrator: ” + Message);

OnStatusChanged(e);

// Create an array of TCP clients, the size of the number of users we have

TcpClient[] tcpClients = new TcpClient[ChatServer.htUsers.Count];

// Copy the TcpClient objects into the array

ChatServer.htUsers.Values.CopyTo(tcpClients, 0);

// Loop through the list of TCP clients

for (int i = 0; i < tcpClients.Length; i++)

{

// Try sending a message to each

try

{

// If the message is blank or the connection is null, break out

if (Message.Trim() == “” || tcpClients[i] == null)

{

continue;

}

// Send the message to the current user in the loop

swSenderSender = new StreamWriter(tcpClients[i].GetStream());

swSenderSender.WriteLine(“Administrator: ” + Message);

swSenderSender.Flush();

swSenderSender = null;

}

catch // If there was a problem, the user is not there anymore, remove him

{

RemoveUser(tcpClients[i]);

}

}

}

// Send messages from one user to all the others

public static void SendMessage(string From, string Message)

{

StreamWriter swSenderSender;

// First of all, show in our application who says what

e = new StatusChangedEventArgs(From + ” says: ” + Message);

OnStatusChanged(e);

// Create an array of TCP clients, the size of the number of users we have

TcpClient[] tcpClients = new TcpClient[ChatServer.htUsers.Count];

// Copy the TcpClient objects into the array

ChatServer.htUsers.Values.CopyTo(tcpClients, 0);

// Loop through the list of TCP clients

for (int i = 0; i < tcpClients.Length; i++)

{

// Try sending a message to each

try

{

// If the message is blank or the connection is null, break out

if (Message.Trim() == “” || tcpClients[i] == null)

{

continue;

}

// Send the message to the current user in the loop

swSenderSender = new StreamWriter(tcpClients[i].GetStream());

swSenderSender.WriteLine(From + ” says: ” + Message);

swSenderSender.Flush();

swSenderSender = null;

}

catch // If there was a problem, the user is not there anymore, remove him

{

RemoveUser(tcpClients[i]);

}

}

}

public void StartListening()

{

// Get the IP of the first network device, however this can prove unreliable on certain configurations

IPAddress ipaLocal = ipAddress;

// Create the TCP listener object using the IP of the server and the specified port

tlsClient = new TcpListener(1986);

// Start the TCP listener and listen for connections

tlsClient.Start();

// The while loop will check for true in this before checking for connections

ServRunning = true;

// Start the new tread that hosts the listener

thrListener = new Thread(KeepListening);

thrListener.Start();

}

private void KeepListening()

{

// While the server is running

while (ServRunning == true)

{

// Accept a pending connection

tcpClient = tlsClient.AcceptTcpClient();

// Create a new instance of Connection

Connection newConnection = new Connection(tcpClient);

}

}

}

Overwhelmed? It’s really not that complicated if you take it line by line and read the comments. It starts by defining two hash tables. These two hash tables will hold the username and the TCP connection associated with it. We need two of them because at one point we’ll want to retrieve the TCP connection by giving the username, and at some other point we’ll want to retrieve the username by giving the TCP connection. The 30 defines how many users the chat server can hold at one given point, but you can easily go into hundreds if needed, without worrying about a performance decrease.

The AddUser() method is obvious – it adds a new user to the hash tables, and thus to our list of connected chat clients. The RemoveUser() method does the opposite. The OnStatusChanged will fire the StatusChanged event, which is right now handled inside Form1.cs. Thus, it’s our way of updating the form with the latest message from inside this ChatServer object.

The SendAdminMessage sends an administrative message to all connected clients. You can see how it loops through the hash table and attempts to send them the message. If the message didn’t get through, they probably disconnected and we then remove them. This is very similar to what the SendMessage() method does, only that this time it sends a message from a specific chat client to all the others.

The StartListening() method is the one we called inside Form1, and it’s the fire starter, the instigator. It defines the first needed objects and starts a new thread that keeps listening for connections, and that is the KeepListening() method. And that’s where our story continues, because if you look inside the KeepListening() method you will see we create a new object of type Connection. That’s because each user connected to our server will have its own instance of Connection. If there are 10 users currently connected, there will be 10 instances of the Connection object. So let’s look at the final class of our chat server:

// This class handels connections; there will be as many instances of it as there will be connected users

class Connection

{

TcpClient tcpClient;

// The thread that will send information to the client

private Thread thrSender;

private StreamReader srReceiver;

private StreamWriter swSender;

private string currUser;

private string strResponse;

// The constructor of the class takes in a TCP connection

public Connection(TcpClient tcpCon)

{

tcpClient = tcpCon;

// The thread that accepts the client and awaits messages

thrSender = new Thread(AcceptClient);

// The thread calls the AcceptClient() method

thrSender.Start();

}

private void CloseConnection()

{

// Close the currently open objects

tcpClient.Close();

srReceiver.Close();

swSender.Close();

}

// Occures when a new client is accepted

private void AcceptClient()

{

srReceiver = new System.IO.StreamReader(tcpClient.GetStream());

swSender = new System.IO.StreamWriter(tcpClient.GetStream());

// Read the account information from the client

currUser = srReceiver.ReadLine();

// We got a response from the client

if (currUser != “”)

{

// Store the user name in the hash table

if (ChatServer.htUsers.Contains(currUser) == true)

{

// 0 means not connected

swSender.WriteLine(“0|This username already exists.”);

swSender.Flush();

CloseConnection();

return;

}

else if (currUser == “Administrator”)

{

// 0 means not connected

swSender.WriteLine(“0|This username is reserved.”);

swSender.Flush();

CloseConnection();

return;

}

else

{

// 1 means connected successfully

swSender.WriteLine(“1”);

swSender.Flush();

// Add the user to the hash tables and start listening for messages from him

ChatServer.AddUser(tcpClient, currUser);

}

}

else

{

CloseConnection();

return;

}

try

{

// Keep waiting for a message from the user

while ((strResponse = srReceiver.ReadLine()) != “”)

{

// If it’s invalid, remove the user

if (strResponse == null)

{

ChatServer.RemoveUser(tcpClient);

}

else

{

// Otherwise send the message to all the other users

ChatServer.SendMessage(currUser, strResponse);

}

}

}

catch

{

// If anything went wrong with this user, disconnect him

ChatServer.RemoveUser(tcpClient);

}

}

}

It doesn’t look too complicated, does it? There’s the constructor that initializes the TcpClient object, then there’s CloseConnection() which is called when we want to get rid of a currently connected client, and finally there’s AcceptClient() which checks for the username validity and if all is fine, it adds the user to the hash tables. If anything goes bad, it removes the user.

I’ll leave you chew on the code for a while now. It’s pretty much as easy as it can get for a C# based chat/server application, but that also means it can use more error handling. Also if you have any suggestions to improve the code or to fix a bug, feel free to post a comment below.

Chat Server Application

Download this Visual Studio 2005 project Download the Chat Client Application project(Visual Studio 2005)

Building a Chat Server and a Chat Client

To no avail I’ve been searching the web for a good C# chat client/server application that is not thousands of lines of code long. The only simple ones I could find were flawed or very buggy, but then again I tried to combine the good parts of all the tutorials I found into one application, and one tutorial that you can see here today. We are going to build a fairly larger application (a few hundred lines of codes) than the ones we’re used to here on Geekpedia, but we’re still going to keep it simple. In fact, there will be two applications: one is a chat server, that handles incoming connections, stores them in hash tables, and distributes new messages to everyone connected, and the other is of course, the chat client, which connects to the server, sends messages and listens for incoming messages. A little knowledge of C#’s networking objects, multi-threading, events and delegates will definitely help you understand this tutorial more easily. A good way to start learning about delegates, events and creating client-server applications is to read the Delegates and Events in C# tutorial first.
The chat server will be able to accept as many chat clients as allowed by the hash table (and you are able to define the limit of the hash table yourself), and it will also track all the messages that are going back and forth in its own chat window, so you should be able to scale this code to a full blown chat application as long as you add the necessary error handling and the bells and whistles.

 

The client application

The client application is, as you might have expected, the simpler one, since all it has to do is to attempt to connect to the chat server, request an username, start listening for messages and sending its own, and finally disconnecting.
Start Visual Studio 2005 and create a new C# Windows Application. I’ve given mine the obvious “Chat Client” name.

Chat Client Form

The first two TextBoxes (txtIp and txtUser) will hold the IP address of the server we want to connect to and the desired username. Before testing out this code keep in mind to change this IP address to the one of the computer in your network that runs the client. If you read the Delegates and Events in C# tutorial, you probably assume you can run the chat application and the server application on the same machine, without needing two different computers connected through a network or the Internet. And you would be right.
The Connect (btnConnect) and Send (btnSend) buttons are obvious, they’re for connecting to the server and sending messages. The large multi-line TextBox is named txtLog and it is where all the messages will be shown.The small TextBox at the bottom is called txtMessage and it is where the message to be sent to the server will be typed.

Now that we’re done with the actual design of the form, we can finally code. Since we will be making use of networking, streaming and threading objects, start by adding the following using statements:

using System.Net;

using System.Net.Sockets;

using System.IO;

using System.Threading;

We’re going to declare most of our objects inside the class, as private, since we don’t need them accessible from anywhere else outside the class:

// Will hold the user name

private string UserName = “Unknown”;

private StreamWriter swSender;

private StreamReader srReceiver;

private TcpClient tcpServer;

// Needed to update the form with messages from another thread

private delegate void UpdateLogCallback(string strMessage);

// Needed to set the form to a “disconnected” state from another thread

private delegate void CloseConnectionCallback(string strReason);

private Thread thrMessaging;

private IPAddress ipAddr;

private bool Connected;

And now that we have them declared, let’s put them to use. Let’s start with the btnConnect_Click event which can be automatically generated if you double click on the Connect button. Inside it we’re going to check whether or not we are connected to a server. If we are, we should call the method that initializes the connection, otherwise we call the method that closes the connection, also specifying a reason why to it:

private void btnConnect_Click(object sender, EventArgs e)

{

// If we are not currently connected but awaiting to connect

if (Connected == false)

{

// Initialize the connection

InitializeConnection();

}

else // We are connected, thus disconnect

{

CloseConnection(“Disconnected at user’s request.”);

}

}

All simple so far, so let’s move to InitializeConnection():

private void InitializeConnection()

{

// Parse the IP address from the TextBox into an IPAddress object

ipAddr = IPAddress.Parse(txtIp.Text);

// Start a new TCP connections to the chat server

tcpServer = new TcpClient();

tcpServer.Connect(ipAddr, 1986);

 

// Helps us track whether we’re connected or not

Connected = true;

// Prepare the form

UserName = txtUser.Text;

 

// Disable and enable the appropriate fields

txtIp.Enabled = false;

txtUser.Enabled = false;

txtMessage.Enabled = true;

btnSend.Enabled = true;

btnConnect.Text = “Disconnect”;

 

// Send the desired username to the server

swSender = new StreamWriter(tcpServer.GetStream());

swSender.WriteLine(txtUser.Text);

swSender.Flush();

 

// Start the thread for receiving messages and further communication

thrMessaging = new Thread(new ThreadStart(ReceiveMessages));

thrMessaging.Start();

}

Nothing too complicated happens in there. The IP address is parsed from the TextBox into an IPAddress object, and then we open a TCP connection to that address. The port is 1986 but it makes no difference as long as its free. We then prepare the controls on the form by disabling some and enabling the others. We also change the caption of btnConnect to now say Disconnect. Through a stream, we then tell the server which username we want, and immediately after that we start a new thread that calls the method ReceiveMessages() which will listen for incoming messages from now on. By putting this in a separate thread, our application is still fully usable while it is listening for messages from the server and keeping the connection alive.

It’s time to see what the ReceiveMessages() method is all about:

private void ReceiveMessages()

{

// Receive the response from the server

srReceiver = new StreamReader(tcpServer.GetStream());

// If the first character of the response is 1, connection was successful

string ConResponse = srReceiver.ReadLine();

// If the first character is a 1, connection was successful

if (ConResponse[0] == ‘1’)

{

// Update the form to tell it we are now connected

this.Invoke(new UpdateLogCallback(this.UpdateLog), new object[] { “Connected Successfully!” });

}

else // If the first character is not a 1 (probably a 0), the connection was unsuccessful

{

string Reason = “Not Connected: “;

// Extract the reason out of the response message. The reason starts at the 3rd character

Reason += ConResponse.Substring(2, ConResponse.Length – 2);

// Update the form with the reason why we couldn’t connect

this.Invoke(new CloseConnectionCallback(this.CloseConnection), new object[] { Reason });

// Exit the method

return;

}

// While we are successfully connected, read incoming lines from the server

while (Connected)

{

// Show the messages in the log TextBox

this.Invoke(new UpdateLogCallback(this.UpdateLog), new object[] { srReceiver.ReadLine() });

}

}

A new stream reader is hooked up to the TCP client. It will listen for incoming messages. But first of all, we read the first line coming from the server. The reason for that is that we know the first line contains a response telling us whether or not we connected successfully. Two reasons why we might’ve not connected successfully are if we attempted to use an username that is already taken, or if we attempted to use Administrator as the username, which is reserved for obvious purposes. The first character of the response given by the server tells us through a 1 that the connection was successful, and through a 0 if it was unsuccessful. And in that case, it also reads a reason as to why it was unsuccessful. That reason starts at the 3rd character of the message, since the first one is the number, and the second one is a pipe character. For example: 0|Username is already in use. Now you can see why if the first character is not a 1 we read the string that starts at the 3rd character and ends at the end of the line.

The this.Invoke() calls tell the form to update itself. We can’t directly update the form elements ourselves from this method because it’s in a separate thread (remember we called it using ThreadStart()) and cross-thread operations are illegal.

Finally, the while (Connected) loop keeps calling the srReceiver.ReadLine() method which checks for incoming messages from the server.

Next comes the method that we kept calling using this.Invoke() – all it does is to update the txtLog TextBox with the latest message:

// This method is called from a different thread in order to update the log TextBox

private void UpdateLog(string strMessage)

{

// Append text also scrolls the TextBox to the bottom each time

txtLog.AppendText(strMessage + “\r\n”);

}

So far we’ve seen how to receive messages from the server, but nothing about how to send them. When do we want to send a message? When the Send button is clicked or when the Enter key is pressed while txtMessage has the focus. This should be hooked up to the Click event of the btnSend button:

// We want to send the message when the Send button is clicked

private void btnSend_Click(object sender, EventArgs e)

{

SendMessage();

}

And this needs to be hooked up to the KeyPress event of txtMessage:

// But we also want to send the message once Enter is pressed

private void txtMessage_KeyPress(object sender, KeyPressEventArgs e)

{
// If the key is Enter

if (e.KeyChar == (char)13)

{

SendMessage();

}

}

You can see that both of them make a call to SendMessage, which we are going to see next:

// Sends the message typed in to the server

private void SendMessage()

{

if (txtMessage.Lines.Length >= 1)

{

swSender.WriteLine(txtMessage.Text);

swSender.Flush();

txtMessage.Lines = null;

}

txtMessage.Text = “”;

}

Quite simple, isn’t it? It just checks for the number of lines to be greater or equal to 1, and then writes that line to the TCP connection through the StreamWriter object. Calling Flush() ensures that the messages are being sent right away.

We seem to be almost done with the client application. But let’s not forget that when btnConnect was clicked, if we were already connected, we called a method called CloseConnection() – what happened to that? Well here it is:

// Closes a current connection

private void CloseConnection(string Reason)

{

// Show the reason why the connection is ending

txtLog.AppendText(Reason + “\r\n”);

// Enable and disable the appropriate controls on the form

txtIp.Enabled = true;

txtUser.Enabled = true;

txtMessage.Enabled = false;

btnSend.Enabled = false;

btnConnect.Text = “Connect”;

 

// Close the objects

Connected = false;

swSender.Close();

srReceiver.Close();

tcpServer.Close();

}

The form is being brought back to the not-connected state, and the TCP connection and streams are being closed. But what happens if the user doesn’t click Disconnect and just closes the application while the connection with the server is alive? We surely don’t want to leave the connection open like this till it dies by its own. Thankfully there is the ApplicationExit event that fires when the application closes, and that’s where we can close our connection. To hook up the event change your Form1 constructor to the following:

public Form1()

{

// On application exit, don’t forget to disconnect first

Application.ApplicationExit += new EventHandler(OnApplicationExit);

InitializeComponent();

}

And here is the event handler that does the actual disconnection:

// The event handler for application exit

public void OnApplicationExit(object sender, EventArgs e)

{

if (Connected == true)

{

// Closes the connections, streams, etc.

Connected = false;

swSender.Close();

srReceiver.Close();

tcpServer.Close();

}

}

Believe or not, we’re done with the chat client application. You should be able to compile and run it now, but of course there’s nothing to connect to because we haven’t developed the server. But that comes next in C# Chat: Part 2- Building the Chat Server. Here’s a little teaser of our applications in action, with the server in the shadow of the two:

Chat Clients

Web Services – Web Services Tutorials

Posted: January 12, 2012 in Random Posts
Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

In this section of the Web Services tutorial you will be familiarized with the Web Services.

Introduction

The next generation of distributed computing has arrived. A Web service is a unit of managed code that can be remotely invoked using HTTP, that is, it can be activated using HTTP requests.

Historically speaking, remote access to binary units required platform-specific and sometimes language-specific protocols. For example, DCOM clients access remote COM types using tightly coupled RPC calls. CORBA requires the use of tightly coupled protocol referred to as Internet Inter-ORB Protocol (IIOP), to activate remote types. Enterprise JavaBeans (EJBs) requires a Remote Method Invocation (RMI) Protocol and by and large a specific language (Java). Thus each of these remote invocation architectures needs proprietary protocols, which typically require a tight connection to the remote source.

One can access Web services using nothing but HTTP. Of all the protocols in existence today, HTTP is the one specific wire protocol that all platforms tend to agree on. Thus , using Web services, a Web service developer can use any language he wish and a Web service consumer can use standard HTTP to invoke methods a Web service provides. The bottom line is that we have true language and platform integration . Simple Object Access Protocol (SOAP) and XML are also two key pieces of the Web services architecture.

What is a Web Service

Web services constitute a distributed computer architecture made up of many different computers trying to communicate over the network to form one system. They consist of a set of standards that allow developers to implement distributed applications – using radically different tools provided by many different vendors – to create applications that use a combination of software modules called from systems in disparate departments or from other companies.

A Web service contains some number of classes, interfaces, enumerations and structures that provide black box functionality to remote clients. Web services typically define business objects that execute a unit of work (e.g., perform a calculation, read a data source, etc.) for the consumer and wait for the next request. Web service consumer does not necessarily need to be a browser-based client. Console-baed and Windows Forms-based clients can consume a Web service. In each case, the client indirectly interacts with the Web service through an intervening proxy. The proxy looks and feels like the real remote type and exposes the same set of methods. Under the hood, the proxy code really forwards the request to the Web service using standard HTTP or optionally SOAP messages.

Web Service Standards

Web services are registered and announced using the following services and protocols. Many of these and other standards are being worked out by the UDDI project, a group of industry leaders that is spearheading the early creation and design efforts.

Universal Description, Discovery, and Integration (UDDI) is a protocol for describing available Web services components. This standard allows businesses to register with an Internet directory that will help them advertise their services, so companies can find one another and conduct transactions over the Web. This registration and lookup task is done using XML and HTTP(S)-based mechanisms.

Simple Object Access Protocol (SOAP) is a protocol for initiating conversations with a UDDI Service. SOAP makes object access simple by allowing applications to invoke object methods or functions, residing on remote servers. A SOAP application creates a request block in XML, supplying the data needed by the remote method as well as the location of the remote object itself.

Web Service Description Language (WSDL), the proposed standard for how a Web service is described, is an XML-based service IDL (Interface Definitition Language) that defines the service interface and its implementation characteristics. WSDL is referenced by UDDI entries and describes the SOAP messages that define a particular Web service.

ebXML (e-business XML) defines core components, business processes, registry and repository, messaging services, trading partner agreements, and security.

Implementing Web Services

Here comes a brief step-by-step on how a Web service is implemented.

  • A service provider creates a Web service
  • The service provider uses WSDL to describe the service to a UDDI registry
  • The service provider registers the service in a UDDI registry and/or ebXML registry/repository.
  • Another service or consumer locates and requests the registered service by querying UDDI and/or ebXML registries.
  • The requesting service or user writes an application to bind the registered service using SOAP in the case of UDDI and/or ebXML
  • Data and messages are exchanged as XML over HTTP

Web Service Infrastructure

Even though Web services are being built using existing infrastructure, there exists a strong necessity for a number of innovative infrastructures. The core architectural foundation of Web services are XML, XML namespaces, and XML schema. UDDI, SOAP, WSDL, ebXML and security standards are being developed in parallel by different vendors

Web Services Technologies and Tools

There are a number of mechanisms for constructing Web services. Microsoft has come out with a new object-oriented language C# as the development language for Web services and .NET framework. Microsoft has an exciting tool called Visual Studio .NET in this regard. The back end database can be Microsoft SQL Server 2000 in Windows 2000 Professional.

Sun Microsystems has its own set of technologies and tools for facilitating Web services development. Java Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJB) architecture and other Java 2 Enterprise Edition (J2EE) technologies play a very critical role in developing Web services.

There are a number of tools for developing Web services. They are Forte Java IDE, Oracle JDeveloper, and WebGain Studio.

Sun Microsystems has taken an initiative called Sun ONE (Open Network Environment) and is planning to push Java forward as a platform for Web services. It is developing Java APIs for XML-based remote procedure calls and for looking up services in XML registries – two more JAX family APIs: JAX/RPC (Java API for XML Remote Procedure Calls) and JAXR (Java API for XML Registries). These will wrap up implementations of Web services standards, such as SOAP and UDDI.

IBM also for its part has already developed a suite of early-access tools for Web services development. They are Web Services Toolkit (WSTK), WSDL Toolkit, and Web Services Development Environment (WSDE).

Apache Axis is an implementation of the SOAP (“Simple Object Access Protocol”) submission to W3C.

From the draft W3C specification:

SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

Apache Axis is an Open Source SOAP server and client. SOAP is a mechanism for inter-application communication between systems written in arbitrary languages, across the Internet. SOAP usually exchanges messages over HTTP: the client POSTs a SOAP request, and receives either an HTTP success code and a SOAP response or an HTTP error code. Open Source means that you get the source, but that there is no formal support organization to help you when things go wrong.

Conclusion

For the last few years, XML has enabled heterogeneous computing environments to share information over the Web. It now offers a simplified means by which to share process as well. From a technical perspective, the advent of Web services is not a revolution in distributed computing. It is instead a natural evolution of XML application from structured representation of information to structured representation of inter-application messaging.

Prior to the advent of Web services, enterprise application integration (EAI) was very difficult due to differences in programming languages and middleware used within organizations. This led to the situation where interoperability was cumbersome and painful. With the arrival of Web services, any application can be integrated as long as it is Internet-enabled.

It is difficult to avoid the popularity and hype that is surrounding Web services. Each software vendor has some initiative concerning Web services and there is always great speculation about the future of the market for them. Whichever way it turns out, Web service architectures provide a very different way of thinking about software development. From client-server to n-tier systems, to distributed computing, Web service applications represent the culmination of each of these architectures in combination with the Internet.

Creating webservices in NetBeans.

In this example program I will show you how you can make webservices in the Netbeans IDE. NetBeans IDE provides necessary GUI Tool to help the developers to quickly develop and deploy web services.

In this example we will

a) Develop webservices

b) Test the webservice

c) Develop client and call the webservice there

d) Finally deploy and test the application

Web Service can be added in a Web project or in Ejb project. Netbeans IDE helps the developers to easily develop and test the webservices.
It’s easy to make the Web Service program in Netbeans, which has Glassfish server by default.

Web Service program in Web Project

In Netbeans take new web project in figure 1

Web Services Example

Figure 1

Give project name webservice1 as shown in figure 2

Web Services Example

Figure 2

Select the server name in figure 3

Web Services Example

Figure 3

Now Rt Click on the Web Service project in figure 4

Select New->WebService

Web Services Example

Figure 4

Now give the name of the Web Service and package name figure 5

Web Services Example

Figure 5

Now In design view of Web Service click on Add Operation in figure 6

Web Services Example

Figure 6

Here give the operation name and parameter name and type as shown in figure 7

Web Services Example

Figure 7

Now in source view change the return null to return “hello ”+name as in figure 8

Web Services Example

Figure 8

Now Rt Click on the project and deploy it on the server as in figure 9

Web Services Example

Figure 9

It will deploy the war file on to the server

Now test the web service program

Rt click on the MyWebService in web services folder and select Test Web Operation as in figure 10

Web Services Example

Figure 10

It will open the Web Service program in browser as in figure 11

Web Services Example

Figure 11

Click on WSDL File in blue color .It will open the WSDL file in the browser as in figure 12

Web Services Example

Figure 12

Now as in fig type the roseindia in the text field and click on show button as in figure 13

Web Services Example

Figure 13

It will return hello roseindia

It also give the SOAP request and SOAP response pf the Web Service as in figure 14

Web Services Example

Figure 14

Now make the client file.Client file can be java servlet , jsp and standalone java file

Start a new web project as in figure 15.

Give project name as Webservice1-client

Web Services Example

Now Rt. Click on the project select NewàWeb Service client

Here now select the WSDL file of the Web Service as in figure 15

Click on the Browse.

Web Services Example

Now select the webservice1àMyWebService

Web Services Example

Figure 15

It creates the Client environments for the Web Service in the given project

Now make a Client file by just taking a new Jsp file as in figure 16

Web Services Example

Figure 16

Give the file name as client.jsp

Rt click in client.jsp file code and select Web Service Client resources –>Call Web Service Operation in figure 17

Web Services Example

Figure 17

Select the web service project ->web service file->web service port->operation name as in figure 18

Web Services Example

Figure 18

Change the name =”null” to name=”roseindia” as in figure 19

Web Services Example

Figure 19

Rt click in client.jsp and select run client.jsp

Web Services Example

Download Code