What, exactly, are Web services? Simply put, they're a new approach to an old idea--a set of interface specifications that don't care about transport mechanism, hardware architecture or OS. We define Web services as "an XML-based interface specification for distributed software to communicate over a network." They're a serendipitous convergence of the distributed computing and Web paradigms. Web-based applications are easy to use but short on processing capabilities. Distributed-computing software can be a nightmare to configure and use, but is capable of powering the enterprise. Web services encompass the best of both worlds: an easy to use and understand interface based on existing Web technologies atop a robust, distributed-computing architecture.
The How
Deploying Web Services can be tricky. Contrary to the hype from your favorite vendor, this is a new, somewhat bumpy way of doing things. The general steps are: write a Web service in your favorite development environment; generate the Web services wrapper from the source code (Microsoft .Net will do this step for you if you let it); generate a server deployment package and the server's WSDL (Web Services Definition Language) definition from the Web services wrapper; generate a client "stub" package from the server's WSDL file; and deploy and test your Web service.
Of course, to test it you'll have to write a client, so the next step is to write a client using the client "stub" file to generate the interface class. Sounds like a lot of work, huh? Luckily most of the process is automated when you use Apache/Tomcat and Microsoft IIS/.Net.
Step By Step: How a Web Service is Called
1. A client application requests a URI (universal resource identifier) using a SOAP-encoded message.
2. The Web server realizes the requested URI is a Web service and passes the request to your application (normally through an application server directly for .Net).
3. Your application services the request and passes it back to the Web server.
4. The Web server sends a response to the requester with the results of your Web service encoded in SOAP format in the body.
The WSDL specification offers a system-independent way for your application to say, "If you want to talk to me, here's how you have to do it." System independence comes from writing the definition in an XML-formatted file. The SOAP (Simple Object Access Protocol) specification, on the other hand, lets your application communicate with client applications. WSDL says, "When you call me, you should have X, Y and Z." SOAP is how X, Y and Z get to the application, and how it returns its response.
Most SOAP exchanges take place over HTTP, and most Web services define HTTP as their "transport mechanism," but this is by no means required. WSDL can set any of several transport mechanisms as the way to call your application and how your applications can respond. For example, you may have a Web services client that says, "Close out the books for the year," and sends the request over HTTP. A year-end close-out is no trivial task, and obviously you're not going to wait with your Web browser for the task to end. Therefore the application may say in WSDL, "If we're closing out the books, the response mechanism will be SMTP; I'll send an e-mail to the boss letting him know when we're done."
Server stubs are the small pieces of code that tell the application server about your application and let the server communicate with your app. Client stubs tell the client application about your interfaces in a system-dependent manner--they are generated from WSDL, which is system-independent, so think of them as the clients' translation of your interfaces into their programming language.
You can create a WSDL file for Web services by using one of many free applications. "Java2wsdl" (from Apache.org) for Java Web services and "WSDL.exe" for .Net Web services are the two most popular generators and will take a written application and generate the WSDL file for it. From this WSDL file you can then generate server and client stubs to use with projects to deploy and access your Web services.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
2009 IT Salary Survey: Meager Raises, Solid Prospects
Though raises are notably smaller than a year ago, and job security’s shrinking, IT careers are looking safer than many others in this economic downturn. Get all the findings in InformationWeek's 2009 IT Salary Survey. Available FREE for a limited time.
REPORTS
ANALYTICS
Follow 
