Web services are revolutionizing Internet by enabling applications to speak a common language: XML. While Web services technology enables execution of remote functions, it does not provide a robust infrastructure for handling information. As solution of this problem this article describes concepts of web services with messaging.

Web Services Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across Web. Web services perform functions, which can be anything from simple requests to complicated business processes.

How it is differ from web application Where current web enables users to connect to applications, web services architecture enables applications to connect to other applications. A web service is therefore a key technology in enabling business models to move from B2C (Business to Consumer) to B2B (Business to Business).

Web Services provide companies with a standards-based technology to simply integrate applications, share information with partners, and provide access to enterprise systems through a variety of devices.

Where is problem? An enterprise-class application that communicates with Web services must ensure that data can be handled appropriately.

When employing Web services, one must ask questions like: Can our application scale to increased messaging demands? If our application crashes, is Web service’s data lost? How do we connect our Web-services-facing applications to back-end systems? These problems are created but unfortunately not solved through Web services architecture. Web services must be combined with additional technology called Messaging for robust enterprise messaging.

Messaging Concept Messaging provides high-speed, asynchronous, program-to-program communication with guaranteed delivery.

A simple way to understand what messaging does is to consider voice mail (as well as answering machines) for phone calls. Before voice mail, when someone called, if the

receiver could not answer, caller hung up and had to call back later to see if receiver would answer at that time. With voice mail, when receiver does not answer, caller can leave him a message; later receiver (at his convenience) can listen to messages queued in his mailbox. Voice mail enables caller to leave a message now so that receiver can listen to it later, which is often a lot easier than trying to get caller and receiver on phone at same time. Voice mail bundles (at least part of) a phone call into a message and queues it for later; this is essentially how messaging works.

In enterprise computing, messaging makes communication between processes reliable, even when processes and connection between them are not so reliable.

There are two main defacto messaging standards for enterprise computing:

1. The Java 2 Platform, Enterprise Edition (J2EE) includes Java Message Service

API (JMS).

2. The Microsoft .NET Framework SDK (.NET) includes System.Messaging

namespace for accessing MicroSoft Message Queue (MSMQ).

Well, early last week I went hunting for something that would be my help desk and give me live support. I had some pretty strict requirements because I am not always sitting in front of my computer. I needed it to work like my present contact system and have live help built right in. I finally found something that works for me.

It's called helpcenterlive and if you do a search for it, you will find it in a heart beat. I was a little disappointed at first because even though it was free, I kept closing window by mistake. Today I started going through all of features, and I actually went to their website and roamed through their forum. I found out that they have an application that sits on your desktop and works just like browser.