A webservice in general is a way of exposing the properties and methods through the Internet In other words, it’s an URL-addressable resource that programmatically returns information to clients who want to use it. A webservice is based on XML standards and has been implemented by different vendors like IBM, Sun Microsystems, CapeClear etc. Currently there is no official body, such as the W3C who have under taken the job of defining this fast evolving technology. Webservices have been foreseen as the future of computing over the web and are more pronounced in the .NET framework owing to its ease in development as well as consumption with or even without VisualStudio.NET. A webservice works on Simple Object Access Protocol (SOAP). Every call to the webmethod from the client’s machine is sent in the form of a SOAP envelope and result from the server is sent back in SOAP containing the result.

The facility of language interoperability that .NET offers within its Common Language Runtime (CLR) offers a new dimension to using webservices. Owing to these attractive features, .NET is predicted to take command of the client side computing market in the years to come. We can for sure get a feel on the nature of computing where you could develop and use applications in languages of your choice, at least in .NET environment.

In this article I plan to elaborate more on this aspect by
Developing a simple webservice in a normal text editor in C#.
Consuming the webservice described above through a console application written in VB.NET.

Although the application might seem complicated, it is fairly simple to achieve this objective. For the sake of better understanding, I have illustrated simple and straightforward examples. Let’s march in to out first step of our objective.

Creating a simple Webservice in C#
The webservice application provides a Web Method called Add, which takes in two integers as parameters and returns their sum as integer. The following code is typed in a simple text editor.

using System;
using System.Web.Services;

public class sumThis:WebService
{
	[WebMethod]
	public int Add(int a,int b)
	{
		int sum;
          sum=a+b;

		return sum;
	}
}

Note: MSDN documents imply that although language interoperability is supported within the .NET platform, it is advisable to use attributes like the ones described below to ensure type compliancy detection at compile time. In other words, these attributes help identify the types that are not recognized by the CTS at compile time. These attributes need to be included in the program prior to declaration of the class in the program.

//optional attributes to ensure type compliancy
// Assembly marked as compliant.
[assembly: CLSCompliantAttribute(true)]
// Class marked as compliant.
[CLSCompliantAttribute(true)]

Few pointers that one must pay attention to while developing a web service are:
The file must be saved as filename.asmx. The file can be checked for its proper syntax and its construct by opening it in a web browser.
It is not necessary to compile the web service (.asmx) file.
In case of developing a webservice in VB.NET one must use the construct instead of the regular construct [WebMethod] used in C#.

View of sumThis webmethod in the browser

If we were to use the webservice in a client’s machine, we need to create a proxy class or more commonly called stub file. The proxy class contains the details of the web method, the server it is contained in etc. This proxy class can be generated on the client’s machine by using the utility WSDL.exe which is packaged along with .NET SDK (Beta 2).

Consuming the Webservice in a Client’s machine using VB.NET

One of the highlights of this utility is one can generate the stub file by just specifying the ip address or the hostname that contains the web service. At the command prompt, the stub file can be generated as

WSDL http://[hostname of server] or [ip address of server] [/n:[namespace to be used in client's machine]] [/l: [language of proxy/C#]] /out:[output file name[.cs/.vb]]

My compilation string for the webmethod sumThis was

wsdl http://ora08.st.utoledo.edu/vijay/webservice/addService.asmx /n:myNamespace /l:vb /out:vbAddWebservice.vb

There are a other switches in the command which can be explored by issuing
WSDL /? at command prompt. We can inspect the output file for more details on the WebMethod.

Once the output file is obtained, we have to compile it using appropriate compiler to produce a DLL file (in my case the VB.NET’s compiler).

vbc /t:library /r:System.dll,System.web.services.dll,System.xml.dll vbAddWebService.vb

Note: The VB.NET compiler needs to be given the reference of System.dll too, which is not so in the case of C# compiler.

Now we are all set to create a client’s application that can access the webmethod Add defined in the webservice. In this example, the client application I conceived of is a simple console application written in VB.NET. The code for the application is as follows:

Imports System
'import the namespace assigned in WSDL compilation
Imports myNamespace

Module Module1
  Sub Main()
      'instantiating a object of the webservice

  Dim ob As New sumThis

       'Ask the user to input two value to add up
      Console.WriteLine("***ENTER TWO INTEGERS TO ADD***")
        Console.Write("FIRST INTERGER :")
        'inputing the values in variables
        Dim var1,var2 As Integer
        var1=Integer.Parse(Console.ReadLine())
        Console.Write("SECOND INTERGER :")
        var2=Integer.Parse(Console.ReadLine())

        'Obtain the answer and display
        Console.WriteLine("The Sum of {0} and {1} is {2}" var1,  var2,ob.Add(var1,var2))

  End Sub
End Module

Compile the above application at the command prompt asvbc /r:vbAddWebservice.dll,system.dll,system.web.services.dll,system.xml.dll testerCalc.vb

Test the application as a normal console application. And voila, we have an application that can communicate to a method from another server written in language different than that of the client’s development language, albeit on the same platform.

One can similarly develop and use webservices with ease in Visual Studio.NET. This example was intended to make clear that webservices could be used in simple console and other command line utilities with ease as any other application.

References:

1. Professional C# by Simon Robinson et al.
2. Create and Deploy a web service using C# Rajadurai P (csharphelp.com).
3. Professional ASP.NET by Richard Anderson et al.
4. MSDN Documentation from http://msdn.microsoft.com/net.
5. www.gotdotnet.com
6. www.webservices.org

To exchange structured and typed informationbetween peers in a decentralized, distributed environment using XML,SOAP presents an uncomplicated mechanism. SOAP defines a simplemechanism for expressing application semantics by providing a modularpackaging model and encoding mechanisms for encoding data withinmodules instead of defining any application semantics such as aprogramming model or implementation specific semantics. This allowsSOAP to be used in a large variety of systems ranging from messagingsystems to RPC.

An Overview to SOAP

SOAP, (the Simple Object Access Protocol), isXML syntax to exchange messages. Moreover, since it is XML, it isindependent from both language and platform. In addition, SOAP is afundamental part of .NET, Microsoft's new development platform, and tounderstand what SOAP is and how it works it will be important fordevelopers to move towards .NET.

In SOAP, there are four parts:

[Continued]

Simply,we can imagine, Web Services a component whose methods you can invokeusing an internet or intranet connection or a Web Service is acomponent that exposes its interface via Web. Web Services build on therecognition of XML in the open arena. Web Services use XML as the wayfor serializing data to receive from, or return to the client. A clientthat can parse XML can use the data returned, even the client and theWeb Service host are using the different operating system, or theapplications are developed with the different programming language. Wewill discuss on Web Services more lately in this article. Let us lookto full story.

WebServices are not necessarily will replace component development;components make a lot of sense in an intranet solution where theenvironment is controlled, and it does not make sense to escape purelyinternal objects through a less efficient web service interface. WebServices make interoperating easy and effective, but they are not asfast as a binary proprietary protocol such as DCOM. The problem withcomponents was facing when distributing them across the Internet. Inthis article, I assume that you have the knowledge of distributedcomponent technology and basic knowledge of middle-tier programming.

A Short History to <st1:city><st1:place>Enterprise</st1:place></st1:city> Programming Model

Theenterprise environment in which present companies now find themselveshas undergone major change over the last few decades. As USA and globalmarkets have opened up, so war has start, and in order to survive,companies have to make better and improved use of the tools at theirarea. In the early days of software world in the workplace,applications were confined to single computers, greatly limiting theproblem domain that they could operate in. Many early desktop solutionsrelied on local copies of the company?s databases being stored on eachcomputer, where they would be accessed and manipulated separately.

As thetechnology improved, and applications became more sophisticated,solutions to this arrangement started to appear based on an onlinecentral database accessed over a network. Often, the workload ofperforming the tasks requested by users is shared between the desktopmachines and the servers. This model knowing as distributed computing.

Manyrecent enterprise solutions cover several distributed applications,where the workload is shared between client and server according to theenvironment of the task and the power of the client machine. Theseapplications, running on fast local networks, are prepared to beextended to provide access through the Internet. The Client-Server termis a little primitive for the networked systems establish in today?sworld of business, but the principal notion of a separation betweenclient and server is still applicable. Many such applications can stillbe thought of as client-server, although their original model is moresophisticated, such as the n-tier arrangement.

<st1:city><st1:place>Enterprise</st1:place></st1:city> Application Integration Architecture

EAIbuilds on proven middleware techniques such as message brokering anddata transformation, and introduces architectural components calledadapters for communication with applications and other data sources.EAI also incorporates business process modeling and workflow, metadatamanagement, security and system administration, and monitoring. Workingin concert, this set of services provides a robust environment forintegrating disparate applications within and across enterprises.

 <st1:city><st1:place>Enterprise</st1:place></st1:city> Distributed Computing

Insteadof running on a single computer, large-scale systems execute on anumber of different machines. One simple reason is to distributeprocessing. Other reasons for distributing functionality amongdifferent physical machines include the ability to separateuser-interface functionality from business logic, increase systemrobustness, and add security features. By separating user-interfacefunctionality from business logic, you can more easily partitionuser-interface development from business logic. This makes developmentand management of the code much easier. Once you have developed yourbusiness logic, you can reuse it later. For example, two differentuser-interface applications can make use of the same business logicwithout changes to the business-logic code.

Robustnessis another important reason for separating the user interface from theback-end business logic. In a client/server application, the server mayservice hundred clients. If one of these clients causes a generalprotection fault, it should not affect the execution of the server orthe other ninety-nine clients. In addition, when you split up userinterface, business, and data logic, you may add security features toyour system. For instance, your server can provide securityfunctionality that authenticates the client each time it connects tothe server. You can even add security logic to authorize everysubsequent request that the authenticated client sends. These reasonsmake distributed computing very elegant.

Thereare very benefits to this model, as we have seen from the substantialincrease in internet companies and internet/intranet applications inthe last few years.

Component Technology

Allthese mean, that the distributed computing uprising was taking place,importance of component technology was also rising. The idea supportsthis technology was interface based programming. A component wouldpublish a particular interface that could be used to interact with it.This interface was a contract that was guaranteed to remain in place.Other developers could, develop using these interfaces; confident thatfuture changes to the component would not break their code.

Thecomponent interfaces were in a binary standard, giving developers thechoice to use different programming languages for the component and theclient. COM/DCOM and CORBA have done very well in this arena.

="smallb
lack">On theother hand, Web Services are not necessarily going to replace componentdevelopment. Components make a lot of sense in an intranet solutionwhere the environment is controlled, and it does not make sense toexpose purely internal objects through a less efficient web serviceinterface. Web Services make interoperating easy and effective, butthey are not as fast as a binary proprietary protocol such as DCOM.

Distributedobject computing extends an object-oriented programming system byallowing objects to be distributed across a heterogeneous network, sothat each of these distributed object components interoperate as aunified total. These objects may be distributed on different computersthroughout a network, living within their own address space outside ofan application, and yet appear as though they were local to anapplication. <o:p></o:p>

Three of the most popular distributed object paradigms are Microsoft's Distributed Component Object Model (DCOM), OMG's Common Object Request Broker Architecture (CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI).Now we will have some more information about COM/DCOM, COM+ and CORBAfor clean understand component and distributed programming techniques.

COM/DCOM, COM+

Component-baseddevelopment has become the software concept, with its own conferences,magazines, and consultants. However, the original component technology,and the one that is by far the most widely used, is Microsoft'sComponent Object Model (COM). Introduced in 1993, COM is now a maturefoundation for component-based development, and it is the rareapplication for Windows and Windows NT that does not use COM in someway. With its integrated services, and its excellent tool support fromMicrosoft and others, COM makes it easy to develop powerfulcomponent-based applications.

Fromits original application on a single machine, COM has expanded to allowaccess to components on other systems. Distributed COM (DCOM),introduced in 1996, makes it possible to create networked applicationsbuilt from components. Available on various versions of UNIX, IBMmainframes, and other systems, DCOM is used today in applicationsranging from innovative medical technology to traditional accountingand human resources systems. Once a bleeding edge technology,distributed components have gone mainstream, and the primarytechnologies enabling this are COM and DCOM.

A COM server can create object instances of multiple object classes. A COM object can support multiple interfaces,each representing a different view or behavior of the object. Aninterface consists of a set of functionally related methods. A COMclient interacts with a COM object by acquiring a pointer to one of theobject's interfaces and invoking methods through that pointer, as ifthe object resides in the client's address space. COM specifies thatany interface must follow a standard memory layout, which is the sameas the C++ virtual function table. Since the specification is at thebinary level, it allows integration of binary components possiblywritten in different programming languages such as C++, Java and VisualBasic. <o:p></o:p>

Theevolution of Microsoft component services continues with COM+. Byenhancing and extending existing services, COM+ further increases thevalue these services provide. COM+ includes: <o:p></o:p>

?         A publish and subscribe service- Provides a general event mechanism that allows multiple clients to"subscribe" to various "published" events. When the publisher fires anevent, the COM+ Events system iterates through the subscriptiondatabase and notifies all subscribers. <o:p></o:p>

?         Queued components- Allows clients to invoke methods on COM components using anasynchronous model. Such as model is particularly useful in onunreliable networks and in disconnected usage scenarios. <o:p></o:p>

?         Dynamic Load balancing – Automatically spreads client requests across multiple equivalent COM components. <o:p></o:p>

?         Full integration of MTS into COM- Includes broader support for attribute-based programming,improvements in existing services such as Transactions, Security andAdministration, as well as improved interoperability with othertransaction environments through support for the Transaction InternetProtocol (TIP). <o:p></o:p>

COM+builds on what already exists?it is not a revolutionary departure.Microsoft component services provide an infrastructure for buildingenterprise applications, and enterprises seldom welcome revolutions intheir infrastructure. However, software technology cannot stand still.The goal, then, must be to provide useful innovations that make iteasier to create great applications without disrupting what is alreadyin place. By extending and further unifying the existing componentservices, COM+ does exactly this.<o:p></o:p>

Takenas a whole, Microsoft component services provide a powerful, flexible,and easy-to-use platform for building distributed applications. Nothingelse available offers the same level of integration, broad toolsupport, and solid services.

CORBA

Youmay read this on several CORBA articles; CORBA is a distributed objectframework proposed by a consortium of hunderds companies called theObject Management Group (OMG). The core of the CORBA architecture isthe Object Request Broker (ORB) tha

t acts as theobject bus over which objects transparently interact with other objectslocated locally or remotely. A CORBA object is represented to theoutside world by an interface with a set of methods. A particularinstance of an object is identified by an object reference. The clientof a CORBA object acquires its object reference and uses it as a handleto make method calls, as if the object is located in the client'saddress space. The ORB is responsible for all the mechanisms requiredto find the object's implementation, prepare it to receive the request,communicate the request to it, and carry the reply if any back to theclient. The object implementation interacts with the ORB through eitheran Object Adapter (OA) or through the ORB interface. <o:p></o:p>

?         CORBA objects can be located anywhere on a network.

?         CORBA objects can interoperate with objects written on other platforms.

?         CORBA objects can be written in any programming language for which there is a mapping from IDL to that language.

Developersuse CORBA to distribute applications across client-server,peer-to-peer, 3-tier, n-tier, Internet/Intranet etc. networks. Insteadof having hundreds of thousands of lines of code running on mainframecomputers with dumb terminals, smaller, more robust applications thatcommunicate between file servers and workstations are now necessary. Tokeep this distribution of applications simple, a plug-and- playarchitecture is necessary to distribute the client-server (CS)applications. Although the computing trend seems to be towardsthe peer-to-peer computing. The developer then can write apps that workindependently across various platforms and diverse networks. The idea behind CORBA is a software intermediary that handles and disperses access requests on data sets. This intermediary is referred to as an Object Request Broker (ORB).The ORB interacts and makes requests to differing objects. It sits onthe host between the data and the application layer (that is, one levellower than the application layer (level 7 in the OSI model). An ORBnegotiates between request messages from objects or object servers andthe affiliated data sets.

Limitation of DCOM and CORBA

Perhaps,we can talk about all other distributed object technologies such asSun?s RMI (Remote Method Invocation) protocol. However, this article?sobjective is not talk all detail about existing technologies.Therefore, we choose two strongest alternatives to discuss what theproblem on existing gear was. In that case, let us talk about why weneed a new technology. Unfortunately, existing technologies have somecruel limitations that have dissatisfied or at least more complex,several existing projects.

Thebiggest problem about DCOM and CORBA were both are platform specific.Both were not easy integrating with each other. You may create a kindof bridge that process translates messages from one to other. However,this system already has some difficulty because of DCOM and CORBAfunctionality, data types etc. An important key barrier iscommunication over the Internet. The distributed communicationtechnologies described earlier have a symmetrical requirement, meaningthat both ends of the communication link would typically need to haveimplemented the same distributed object model. In Internet, nobody canpromise that both ends of the communication link will have implementedthe same distributed object model. Promising this on the Internet isrisky and normally just impossible.

Anotherissue about limitation is Firewalls and Proxy servers. DCOM and CORBAare not firewall and proxy friendly. Both architectures typically forcethem to listen to port numbers, which this is may not be withoutproblems or usually known. The challenge with proxy servers is thatclients using these protocols typically require having a directconnection to the server. In general, firewalls does not givingpermission (in case of security) keeps open many ports, except someusually used ones. For instance, these ports are HTTP and SMTP.

Furthermore,as CORBA and DCOM are respectable protocols, the business world has notyet moved completely to one in exacting. All sides pointing out theother?s shortcoming mark the lack of worldwide commerce recognition.With other words, some models, for example DCOM, CORBA as well as RMIfor Java, work very well in an intranet environment. These technologiesprovide components to be invoked over network connections, as a result,make possible distributed application development. In a pureenvironment each of these works well, but interoperating with the otherprotocols, none is very successful. For example, using DCOM, Javacomponents cannot be called, and COM objects cannot be invoked usingRMI. Attempting to use these technologies over the Internet presentseven more difficulty. Firewalls often block access to the requiredTCP/IP ports, and because they are proprietary formats both the clientand server must be running compatible software.

An Architectural Overview to Web Services

Althoughthis time we talked about several issues about Web Services also talkedabout is the Web Services shortly. One of the most important rewards ofthe XML Web services architecture is that it allows programs developedin different programming languages on different platforms tocommunicate with each other in a standards-based technique. There aretwo different methods to work with Web Services; to allow access tointernal system functionality, exposing them to the outside world andas a client, or consumer of external Web Services. In this model, WebServices are used to access functionality from any tier in anapplication. This provides the possible of any distributed systemexposed on the Internet to be incorporated into a custom application.

Ingeneral, the architecture of a Web Service divided into five logicallayers such as Data Layer, Data Access Layer, Business Layer, BusinessFa?ade and Listener. The Listener is nearest to client, and the layerfurthest from the client is the data layer. The business layer isfurther divided in to two sub layers named Business logic and

Businessfa?ade (this mean is an elevation at front side). Any physical datathat the Web Service requires is stored in the data layer. Above thedata layer is the data access layer, which presents a logical vision ofthe physical data to the business logic. The data access layer isolatesbusiness logic from changes to the underlying data stores and ensuresthe integrity of the data. The business fa?ade provides a simpleinterface, which maps directly to operations exposed by the WebService.

Businessfacade block is constantly used to provide a dependable interface tothe underlying business objects and to isolate the client from changesto the underlying business logic. When it is present, it liveswhichever involving the client and the business logic or involving theWeb service projects and the business logic layers.

Thebusiness logic layer provides services for the business fa?ade?s use.All the business logic might be implemented by the business fa?ade in asimple Web Service, which would interact directly with the data accesslayer. Web Service client applications interact with the Web Servicelistener. The listener is responsible for receiving incoming messages,which contain requests for services, parsing the messages, anddispatching the requests to the appropriate methods in the businessfa?ade.

This architecture is very similar to the n-tierapplication architecture defined by Windows DNA. The Web Servicelistener is equivalent to the presentation layer of a Windows DNAapplication. The listener is responsible for packaging the responsefrom the business fa?ade into a message and sending that back to theclient, if the service returns a response. The listener also handlesrequests for Web Service contracts and other documents about the WebService. By adding a Web Service listener parallel to the presentationlayer and providing it the access to the existing business fa?ade, itis easy to migrate a Windows DNA application to a Web Service. Whileweb browser clients can continue to use the presentation layer webService client applications will interact with the listener. 

<o:p> </o:p>

Web Services Stack

We canstart to talk with HTTP (HyperText Transfer Protocol); with thiscommunication protocol, it is possible to send information from onepoint on the Internet to another point. The information that is sentover the wire can be structured by using XML (eXtensible MarkupLanguage). The XML protocol defines the format and the semantics of theinformation. XML is a fundamental foundation for the later layers. SOAP(Simple Object Access Protocol) is a protocol that defines how toinvoke function calls from objects that live in different environments.

Duringusing SOAP, it is possible to defeat problems that are move up whentrying to integrate different operating systems, object models, andprogramming languages. With SOAP, it turns into possible for the firsttime to easily integrate different category of business processes.

HTTP,XML, and SOAP can be seen as the core layers for Web Services. Theselayers define how Web Services have to interact with each other. Thesethree protocols have been accepted by the W3C (World Wide WebConsortium, http://www.w3.org/) as standards.

Theprotocol WSDL (Web Services Description Language) describes how tocommunicate with a Web Service. In the WSDL definition, different typesof communication (bindings) are allowed. Its one thing to havedeveloped a Web Service, but it is another to earn money with it aswell. In order to do this, we need a central market place where we canpublish our Web Service, so other parties can find it and use it. Thisis where UDDI (Universal Description, Discovery and Integration) comesin.

WebServices technology can be generally classified into three keyassemblies, Description Stack, Discovery Stack and Wire Stack. Thedescription stack deals with a wide range of technologies that describeWeb Services in order to facilitate their common use for businessprocess modeling and workflow composition in B2B relationships. Thediscovery stack deals with technologies that allow for directory,discovery, and inspection services. The wire stack consists oftechnologies that provide the steam for the runtime engines of WebServices.

Building Blocks

Let usstart like this; Web Services are building blocks for constructingdistributed Web-based applications in a platform, object model, andMultilanguage manner. Web Services are based on open Internetstandards, such as HTTP and XML, and form the basis of Microsoft'svision of the programmable Web. What are the ?Building Blocks? SOAP,WSDL and UDDI.

SOAP

Let?s, we will put general information over SOAP as a fundamental building block of Web Services.

SOAP isa standard way of serializing that the information needed to invokeservices located on remote systems as a result, which the informationcan be sent over a network to the remote system in a format the remotesystem can understand, regardless of what platform the remote serviceruns on or what language it is written in. Fundamentally, SOAP is anXML-based protocol that is designed to exchange structured and typedinformation on the Web. SOAP can be used in combination with a varietyof existing Internet protocols and formats including HTTP, SMTP, andMIME and can support a wide range of applications from messagingsystems to RPC.

SOAPaddresses the issue of passing information to and from remoteapplications through firewalls.  Firewalls, as the paper points out,often prohibit remote communication through ports other than somepredefined, well-known ports, reserved for a specific purpose.  Thisbecomes an issue as most distributed protocols do not use assignedports, but dynamically select them.  The solution, as implemented byMicrosoft's SOAP technology, is to pass a call to a remote processthrough port 80, the port assigned for HTTP traffic.  The remote callsare attached on top of the HTTP protocol using XML to define the formatof the request or response messages. Among the advantages of thistechnology is clearly the ease at which firewall complications can beavoided.  Cross platform compatibility also comes to mind, althoughthis wasn't discussed beyond a passing comment in the article.  Adrawback might be in some inefficiency as port 80 is a commonly usedport used for all web traffic through the server.<o:p></o:p>

SOAPhas been developed to solve an aging problem with developingapplications for the Internet: interoperability. Imagine a world whereyou can access objects and services on remo

te (or local) servers in aplatform-independent manner. Today?s world is infected with differentoperating systems, different firewalls, different methods of makingremote procedure calls, and different platforms. In order tointeroperate across the Internet both the client and server need tounderstand each others security types and trusts, service deploymentschemas, and implementation details, not to mention speak the sameplatform language (e.g. COM to COM, ORB to ORB, EJB to EJB, etc.).  WithSOAP, an end to all of this platform-specific confusion has arrived.Based on the already industry wide accepted IETF HTTP standard and W3CXML standard, SOAP bridges the opening between competing object RPCtechnologies and provides a light-weight messaging format that workswith any operating system, any programming language, and any platform.

There are three main parts in the SOAP architecture.<o:p></o:p>

?         An envelope that describes the contents of a message and how to process it.

?         A set of encoding rules for expressing instances of application-defined datatypes.

?         A convention for representing remote procedure calls and responses.

<o:p> </o:p>

Simplydeclared, SOAP provides a technique to access services, objects, andservers in a completely platform-independent mode. By SOAP, you willcapable of query, invoke, communicate with, and otherwise handleservices provided on remote systems without regard to the remotesystem?s location, operating system, or platform.

SOAP byitself provides a way to exchange messages with Web Services, but itdoes not provide a way to find out what messages a Web Service mightwant to exchange. It also, does not give you any way of finding WebServices or negotiating with them. <o:p></o:p>

WSDL<o:p></o:p>

The WebServices Description Language (WSDL) along with SOAP, form theessential building blocks for Web Services. WSDL is an XML-based formatfor describing Web Services. It describes which operations Web Servicescan execute and the format of the messages Web Services can send andreceive. A WSDL document can be consideration of as a contract betweena client and a server. With WSDL-aware tools, you can also automatethis process, enabling applications to simply integrate new serviceswith little or no manual code. WSDL therefore represents a cornerstoneof the web service architecture, because it provides a common languagefor describing services and a platform for automatically integratingthose services.

Whilemost WSDL documents are used in RPC-style request/response pairs, WSDLas well supports one-way messages. WSDL supports the same four types ofoperations that SOAP messages accomplish that request-response,solicit-response, one-way, and notification.

UDDI

UDDI (Universal Description, Discovery, and Integration) is the building block that will enable businesses to quickly, easily and dynamically find and transact businesswith one another using their preferred applications. With differentway, UDDI is an XML-based registry for businesses worldwide to listthem on the Internet. Its ultimate goal is to streamline onlinetransactions by enabling companies to find one another on the Web andmake their systems interoperable for e-commerce. UDDI is often comparedto a telephone book's white, yellow, and green pages. The projectallows businesses to list themselves by name, product, location, or theWeb services they offer. <o:p></o:p>

TheUDDI focus is on providing large organizations the means to reach outto and manage their network of smaller business customers. The biggestissues facing UDDI are ones of acceptance and buy-in from businessesthemselves, and implementation issues of scalability and physicalimplementation.

TheUDDI Consortium, established by hundreds of companies, emerged inresponse to a series of challenges posed by the new Web Services model.These challenges included the how do you discover Web Services, howshould information about Web Services be categorized. These challengesalso included how do you handle the global nature of Web Services, howdo you provide for localization and how can interoperability beprovided, both in the discovery and invocation mechanisms. In addition,it included how you could interact with the discovery and invocationmechanisms at runtime.

Infavor of UDDI to provide the foundation for Web Services registries,therefore, it had to serve two primary roles within the Web Servicesmodel such as Service publication and service discovery.

Describing Web Services

We justtalk about WSDL, now we will discuss describing Web Services as anintroduction. We will not go deeply issues in this article, becausethis article already considering you have minimum more than beginnerinformation.

DescribingWeb Services needs a language such as WSDL. Since SOAP?s conception,the designers planned for it to support a type system the one theychose was XML Schema. The SOAP specification enables you to describetype information in one of two manners. The first way relies on the useof the xsi: type attribute within your SOAP messages. In this manner,each message can be self-describing so that the receiving endunderstands how to interpret the message parameters and theirassociated types.

Thesecond manner enables the sender and receive

r to rely on some from ofschema to be referenced from an external but unspecified source. Inthis manner, the sender and the receiver are interacting based on awell-defined contract of types.

An XMLschema alone does not inform all the information that we needconcerning a Web Services. However, SOAP serialization is troubled, andXML schema datatype is sufficient. On the other hand, other feature toWeb Services need to be addressed therefore, WSDL was created.

WSDL isan XML language, which uses several layers of abstraction to describeWeb Services in a modular technique. Furthermore, WSDL has a vocabularythat enables us to create independent datatype definitions, abstractmessage definitions, and service definitions. After they are defined,the abstractions can be bund to concrete message formats, transportprotocols, and endpoints to complete the overall package.

Essentially,WSDL defines an XML grammar that describes Web Services as collectionsof communications endpoints that are able to exchange messages witheach other. However, the Microsoft implementation requires another fileto map the invoked Web Service operations to COM object method calls.This additional file is expressed in the Web Services Markup Language(WSML), which is Microsoft?s proprietary language for this particularpurpose. Besides, the Microsoft SOAP Toolkit generates WSML filesautomatically.

Publishing Web Services

Whatdoes mean publishing Web Services? UDDI uses WSDL as a descriptionlanguage. WSDL documents can be organized as service implementation andservice interface documents. The service implementation document mapsto the UDDI businessService element, while the service interfacedocument maps to the tModel elements. The first step in publishing aWSDL description in a UDDI registry is publishing the service interfaceas a tModel in registry.                                   <o:p></o:p>

TheUDDI registry is not only run by Microsoft also IBM and Ariba are alsocontrolling repositories. This means that if we post information withone, then it is replicated on all databases held by those companies.Each of the independent repositories have the same interface to giveany outside organization or individual the opportunity to postinformation to UDDI using the UDDI Publish Web Service and search UDDIusing the UDDI Inquire Web Service.

Oncethe tModel has been published, businesses that wish to provide servicesas defined in the tModel implement Web Services based on the WSDLdefinition. These services are accessible through a URL, and businessesthen publish this information in the UDDI registry ? the service URL iscontained in the Binding Template of the service that the businesspublishes.

ThePublishing allows several activities such as registration of newbusiness and services, deletion of existing services of businesses andmanagement of security on the business data. The Publisher API isintended for software programmers or Independent Software Vendors whowould like to publish their web services to a UDDI node.

UDDIdata structure has two functions that they named save and delete. Thesefunctions from the Publication API that allows the user to modifyexisting entries in the registry and create new ones by using the savefunctions. The delete functions completely remove the given datastructure. This API is used primarily as a means of creating andupdating business and service information that the end user isauthorized to modify.

Althoughthe UDDI registry allows you to access all the functionally ofpublishing and finding services programmatically through XML and SOAP,IBM and Microsoft supply a Web Interface as well so that you can accessall this functionality from a Web browser.

Thisarticle only intends to give you a sophisticated overview of WebServices, WSDL, UDDI and related objects to help you to understandfuture articles. You learned how to work a Web Service. You alsoreceived a high-level overview of Web Services Architecture. On theother hand, you had some introduce information about describing andpublishing Web Services.

This tutorial teaches you how to “consume” a simple web service, Circle24_WorldTime, that allows you to find the time in major cities around the world using C#.

This tutorial is for beginners to the C# language, .NET and XML web services and therefore will not go into great detail nor explain in depth how XML web services work. This also assumes that you do not have Visual Studio.NET.

Download WorldTime.zip

What you need:

.NET SDK (get it here).

A text editor (I am using Notepad).

In this tutorial we will be creating a program that asks the user for the name of a city and then gets the time and date for that city. Here is the output of the completed program:

Enter City: New York
07:01 PM Friday, Jul 12 2002
Press any key to continue . . .

We will be using a web service called Circle24_WorldTime. The web service has one method called GetTime(string City) of which you pass a string containing the name of a city. If will return the current date and time of that city.

The fist step is to create a web service proxy. The proxy acts as a “mediator” between your program and the web service. The proxy is create using a tool called wsdl.exe. This program generates C# code for the WSDL of the web service. First you have to understand what WSDL is.
Here is the official (W3C) explanation:

“WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). -W3C

Basically, the WSDL describes the methods that the web service supports and how to access them, hence its name Web Service Description Language

The address of the WSDL for Circle24_WorldTime is located at http://upload.eraserver.net/circle24/worldtime/worldtime.asmx?WSDL

To generate the code for the proxy type this into the command line:

wsdl http://upload.eraserver.net/circle24/worldtime/worldtime.asmx?WSDL

if done correctly this should be displayed:

Now you need to compile it. Type this into the command line:

csc /t:library WorldTime.cs.

This will create a DLL called WorldTime.dll.

Now we will start programming. Create a file called Time.cs and add the following code.
NOTE: Time.cs MUST be in the same directory as WorldTime.dll.

The code:

You must now compile Time.cs. In the command time type:

csc /r:WorldTime.dll Time.cs

My output was as follows:

C:\Programming\csharp\WorldTime>csc /r:WorldTime.dll Time.cs
Microsoft (R) Visual C# .NET Compiler version 7.00.9466
for Microsoft (R) .NET Framework version 1.0.3705
Copyright (C) Microsoft Corporation 2001. All rights reserved.

This will generate Time.exe.

The result from running Time.exe on my computer

C:\Programming\csharp\WorldTime>Time.exe
Enter City: Auckland
02:20 PM Saturday, Jul 13 2002

Well done, you have consumed your first web service. Now you can integrate the many free web services that are avalible on the net within you apps.

"smallbl
ack">I hope this tutorial was informative and easy. Please email me with comments, corrections or help relating to this article or ideas for other articles.

Written by Paul William

References:

Circle24_WorldTime documentation: http://upload.eraserver.net/circle24/worldtime/worldtime.asmx

W3C WSDL: http://www.w3.org/TR/wsdl

Thanks to Cander for help.

Since trying to work on a web-service seemsdifficult to new users and inexperienced programmers, this articlepresents a step-by-step method to form a simplest and shortestweb-service in C#.

We'll start off with a web-service in C#.

1.On the start page, click on the New Project button.

After that you'll see the following dialoguebox. Choose Visual C# Project as Project Type, and ASP.NET Web Serviceas Template. If it is your first Web Service, the name would do justfine. But you can name it anyway you want. Then, click OK.

Next you'll see a dialogue box with title Creating New Project.

It'll take a while to create folders of the web service, so there is no rush.

In case if you don't see this dialogue box,there is no need to panic. The next screen is where you ultimately haveto reach, either directly, or through the above dialogue box.

Click on the marked link in the snapshot below.

Now you'll come across some real code. Puttingcuriosity aside, forget about the rest of the code and concentrate onmaking a simple, shortest web service. To do that, scroll down towardsthe end of the code. There you'll see a chunk of code commented, asshown below.

Remove the double slashes (single line comments in C#) from all the enclosed lines.Your code would look like this.

That's all for the coding stuff. Now to compile it, Press F5.

If you've been an obedient reader, the next Window appeared "is" a web service. It would look something like below.

So you see, creating a web service isn't so difficult after all. Hope this would give you some hope to work on Web Services.

INTRODUCTION

Web Services has been the most revolutionaryaspect of the .NET framework developed by Microsoft. This articlepresents the three different modes through which data can be accessedviz. through web services, stored procedures and SQL Query using thepower of ADO.NET and XML.

Accessing Data through Stored Procedures/SQL Queries

Case: Displaying Data in a Data Grid through SQL Query involves the following main steps:

Step 1: //Open the connection object to connect to the Data Base

SqlConnection sqlConn = new SqlConnection("Database=****;Server=****; uid = **; pwd=***");
//***- Pass the required details

sqlConn.Open ();

Step 2:

//Create the sqlcommand object and set the command
//type
SqlCommand sc = new SqlCommand ();
sc.Connection = sqlConn;
sc.CommandType = CommandType.Text;
//Change this to CommandType.StoredProcedure to
//access thru Stored procedure

Step 3:

//set the command text
sc.CommandText = "Pass the SQL Query or STOREDPROCEDURE NAME";
/* For ex- "SELECT FunctionalAreaMaster.vFunctionalArea,nMinimumExperience,nMaximumExperience
FROM FunctionalArea Or Test_StoredProcedure in case of Stored Procderues */

Step 4:

//create the data set and data adapter object
DataSet ds = new DataSet();
SqlDataAdapter myReader = new SqlDataAdapter(sc);
//fill the data adapter object with the data set
myReader.Fill(ds);

//set the grid data source as the data table
dgdFunctionArea.DataSource = dtblFunctionalArea;
//fill the data grid with details
for(int i =0;i < ds.Tables[0].Rows.Count;i++)
{
dtblFunctionalArea.LoadDataRow(arrstrFunctionalArea,true);
dgdFunctionArea[i,0] = ds.Tables[0].Rows[i].ItemArray[0].ToString();
dgdFunctionArea[i,1] = ds.Tables[0].Rows[i].ItemArray[1].ToString();
dgdFunctionArea[i,2] = ds.Tables[0].Rows[i].ItemArray[2].ToString();
}

Refer FillDataThruSpOrSQlQuery.cs for source code

Case: Displaying Data in a Data Grid through Web Service involves the following main steps:

//create the web service object to access web method
MaintainData.DataFill obj = new MaintainData.DataFill();

//Call the web method thru the above created object(say GetDetails here) and pass the
//required xml string and collect the result in the form of xml in a string variable

string strViewResult = obj.GetDetails("PasstheXMLString");
//For ex- //<A><B>BE</B><B>MBA</B></A>
obj = null;

//here pass the above string to the method which will parse the xml from the string
//passed and returns a xml element object
XmlElement XmlElementViewResult = GetDocumentElement(strViewResult);

//xmlelement returned will have Records tag if there are records else some other tag(this
//depends on the tag returned from the data tier)
if(XmlElementViewResult.GetElementsByTagName("Records").Count > 0)
{
//now fill the rows in data grid by running the loop number of times there are childnodes
for (int intRow=0;intRow < XmlElementViewResult.ChildNodes.Count;intRow++)
//row
{
//first fill the data table and then the respective cell in the data grid
dtblFunctionalArea.LoadDataRow(arrstrGeneral,true);
dgdGeneral[intRow,0] = XmlElementViewResult.GetElementsByTagName("SpecialisedArea").Item(intRow).InnerText;
dgdGeneral[intRow,1] = XmlElementViewResult.GetElementsByTagName("MinExperience").Item(intRow).InnerText;
dgdGeneral[intRow,2] = XmlElementViewResult.GetElementsByTagName("MaxExperience").Item(intRow).InnerText;
}
}

Refer FillDataThruWebService.cs for complete source code

Note:

To run the above files include these files ina project (create a new one or add to the existing one)and then buildthe solution , then debug and run in VS.NET.

This second article in this series dedicated to Web services comes as asequel to the first one in which I started to tell you how you couldbuild different kind of clients and services using MS SOAP Toolkit,Apache SOAP for Java and .NET Framework. In the last article I mentioned something about the incompatibilitybetween a MS SOAP client and an Apache SOAP server (the infamousxsi:type). As far as I know the version 2.2 didn't solve this problem,which is Apache SOAP Server is still expecting all parameters to have atype specified. But, the good news is that there is a work around tothis problem. Many of you sent me e-mails asking how to do this. Wellit is fairly simply. Apache SOAP Server and clients Do you remember the Apache SOAP server we wrote last time? Wellanother good news is that you don't have to change anything inside theserver. You only need to change the deployment descriptor. Let me tell you more about the workaround before writinganything. The major difference between MS implementation of SOAP andApache for Java's is that the former relies on WSDL files to fullydescribe the service when the latter doesn't. This is why in theinitial implementation of the Apache SOAP for Java the type is requiredto be specified for each parameter. The server has no other mean toknow the type of the parameters unless is specified in the call. In theMS implementation the WSDL file has enough information and the servercan figure out even if the call tells nothing about this. Now, the solution to our problem is: when you deploy yourservice you can specify the type mapping of each parameter in yourmethods. The Java service uses this whenever there isn't enoughinformation in the method call. So you must add a mappings section to your deployment script. I modified the deployment descriptor for our service.

<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:MyService ">
?
<isd:mappings>
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="" qname="x:num1"
xml2JavaClassName="org.apache.soap.encoding.soapenc.DoubleDeserializer"/>
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="" qname="x:num2" xml2JavaClassName="org.apache.soap.encoding.soapenc.DoubleDeserializer"/>
</isd:mappings>
?
</isd:service>

That's all.Believe it or not that's all you have to change. The MS STK clientdoesn't need any change either. The same mention for the .NET client,don't change anything. This will complete our incursion to building clients and services(simple ones) using the three major frameworks available. I mustmention here that there are other frameworks for building SOAP serversand clients so don't be shy and publish source code and information sowe can all learn about them. I remember seeing among people on SOAPBuilders discussion group another name: Glue. They were at beta versionlast time a checked their web site but I'm sure they will quickly bereleasing their product. Generic client for Web Services Ok so now we know hot to build a web service when we have enoughinformation about the service itself: we are either the developers ofthe service or good friends with the developer, so we can get the?signature? of the service at the time we write the client. Now, suppose you want to build a client that is able to call a serviceknowing only the name of the methods or something similar. My examplewill try to add two numbers searching a Math service and calling themethods. A more practical example could be a stock checker or somethingsimilar. The steps I follow are: - search the UDDI and findbusinesses which can help me solve my problem. The way we find thebusiness is not standardized since there isn't a set of categories withbusinesses. For example we'll make the convention that Math businesseswill be stored under Math category. Next we'll query for the URL wherethe web service stores the WSDL file. This is the first step to finalize our solution. I'll skip the code forthis section since UDDI and related APIs are the subject of a futurearticle. - Once we have the WSDL file we'll parse this file and find outinformation about the web service. Based on this information we'llbuild a SOAP request. To build a soap request I used the low level APIin STK since we don't know from the beginning how many parameters theservice will call. And here is the code:

Option Explicit

Function BuildOperation( _
ByVal WSDLFileName As String, _
ByVal WSMLFileName As String, _
sOperation As String) As CWSDLOperation

Dim Reader As WSDLReader
Dim EnumService As EnumWSDLService
Dim Service As WSDLService
Dim EnumPort As EnumWSDLPorts
Dim Port As WSDLPort
Dim EnumOperation As EnumWSDLOperations
Dim Operation As WSDLOperation
Dim EnumMapper As EnumSoapMappers
Dim Mapper As SoapMapper
Dim Fetched As Long

Dim objWSDLOperation As CWSDLOperation
Dim objOperationPart As COperationPart
Dim bAddParts As Boolean

Set objWSDLOperation = New CWSDLOperation

Set Reader = New WSDLReader
Reader.Load WSDLFileName, WSMLFileName

Reader.GetSoapServices EnumService

EnumService.Next 1, Service, Fetched
Do While Fetched = 1

Service.GetSoapPorts EnumPort

EnumPort.Next 1, Port, Fetched
Do While Fetched = 1

Port.GetSoapOperations EnumOperation

EnumOperation.Next 1, Operation, Fetched
Do While Fetched = 1

//check to see if the operation is here
bAddParts = False
If InStr(1, Operation.soapAction, "." + sOperation) > 0 Then
With objWSDLOperation
Set .m_Parts = New Collection
.m_PortAddress = Port.address
.m_SoapAction = Operation.soapAction
End With
bAddParts = True

Operation.GetOperationParts EnumMapper

EnumMapper.Next 1, Mapper, Fetched
Do While Fetched = 1

If bAddParts Then
Set objOperationPart = New COperationPart
objOperationPart.m_Name = Mapper.partName
Call objWSDLOperation.m_Parts.Add(objOperationPart)
End If

EnumMapper.Next 1, Mapper, Fetched
Loop

End If

EnumOperation.Next 1, Operation, Fetched
Loop

EnumPort.Next 1, Port, Fetched
Loop

EnumService.Next 1, Service, Fetched
Loop
Set BuildOperation = objWSDLOperation

End Function

Function buildBuildOperation() parses the WSDL file and gathers information about theservice: name, parameters, namespaces used, etc and finally returns aCWSDLOperation object. With this information we can move next to build the SOAP requestand invoke the web service. The service is invoked by calling Executemethod on CWSDLOperation object. In my example the Execute method willsimply print the result of the add operation. In my example the rule I applied for finding the right methodand passing the parameter is pretty simple but in a real applicationyou can implement more sophisticated mechanisms or assume there are fewpatterns for each method naming. Here is the code for the CWSDLOperation class.

Option Explicit

Private Cons

t WRAPPE
R_ELEMENT_NAMESPACE = ""

Public m_PortAddress As String
Public m_SoapAction As String
Public m_Parts As Collection

Public Sub Execute()
If m_SoapAction <> vbNullString Then
On Error GoTo ErrorHandler

Dim Serializer As SoapSerializer
Dim Reader As SoapReader
Dim Connector As SoapConnector

Dim part As COperationPart
Dim sMethod As String, sNamespace As String

Set Connector = New HttpConnector
Connector.Property("EndPointURL") = m_PortAddress
Connector.Property("SoapAction") = m_SoapAction
Connector.BeginMessage

Set Serializer = New SoapSerializer
Serializer.Init Connector.InputStream

sMethod = Mid$(m_SoapAction, InStrRev(m_SoapAction, ".") + 1)
sNamespace = Left$(m_SoapAction, InStr(m_SoapAction, "/action") – 1)

Serializer.startEnvelope
Serializer.startBody
Serializer.startElement sMethod, sNamespace + "/message/", , "m"

For Each part In m_Parts
Serializer.startElement part.m_Name
Serializer.writeString "20"
Serializer.endElement
Next

Serializer.endElement
Serializer.endBody
Serializer.endEnvelope

Connector.EndMessage

Set Reader = New SoapReader
Reader.Load Connector.OutputStream

If Not Reader.Fault Is Nothing Then
MsgBox Reader.faultstring.Text, vbExclamation
Else
Debug.Print Reader.RPCResult.Text
End If
End If

Exit Sub

ErrorHandler:
MsgBox "ERROR: " & Err.Description, vbExclamation
Err.Clear
Exit Sub
End Sub

COperationPart class is very simply:

Option Explicit

Public m_Name As String

If you want tosimplify the code you can substitute the COperationPart class with aString variable. There are more fields that can be added to theCOperationPart class but I removed them for simplicity of the code. Theother information available in the WSDL file for a OperationPart are: - elementName - callIndex - elementType - messageName - isInput - partName - xmlNameSpace - comValue - parameterOrder To test the sample application you need to build 2 simple Web serviceswith STK MathLib1 and MathLib2. MathLib1 implements add method andMathLib2 implements addNumbers method. Both methods accept 2 parametersas double values. After you create these two web services change the namespace inone of them so something else than default, so you replicate a realsituation. Create a VB project, add the two classes, than add a form, onthe form add a button and insert the following code in his click event.

Private Sub cmdCallServices_Click()
Call BuildOperation("C:\work\xarea\soap\MathLib\MathLib1\MathLib1.WSDL", _
"C:\work\soap\MathLib\MathLib1\MathLib1.WSML", "add").Execute
Call BuildOperation("C:\work\xarea\soap\MathLib\MathLib2\MathLib2.WSDL", _
"C:\work\soap\MathLib\MathLib2\MathLib2.WSML", "add").Execute
End Sub

Compile and you are ready to go!

I hope this article will help better understand web services and SOAP.

First, let's start off by creating a very simple webservice.

Creating A Webservice

1.Create a folder named Webservice under wwwroot

2. Create a File

<%@ WebService Language="c#" Class="AddNumbers"%>

using System;
using System.Web.Services;
public class AddNumbers : WebService
{
[WebMethod]
public int Add(int a, int b){
int sum;
sum = a + b;
return sum;
}
}

3.Save this file as AddService.asmx [asmx-> file extension]

4.Now the webservice is created and ready for the clients to use it.

5. Now we can call this webservice using

http://ip address/Webservice/Addservice.asmx/Add?a=10&b=5

This will return the result in XML format

Deploying the Webservice in the Client Machine

1.At the command prompt:

WSDL http://ip address ofthe site/WebService/MathService.asmx /n:NameSp /out:FileName.cs]
-This will create a file called FileNmame.cs .

WSDL -> WebServices Description Language (This is an application available at C:\Program

Files\Microsoft.NET\FrameworkSDK\Bin)

NameSp -> Name of the NameSpace which will be used in client code for deploying the webservice.

2.Compilation

CSC /t:library /r:system.web.dll /r:system.xml.dll CreatedFile.cs

This will create a dll with the name of the public class of the asmx file.( In our case, it is "AddNumbers.dll" )

CSC is an application available at C:\WINNT\Microsoft.NET\Framework\v1.0.2914

3.Put the dll file inside WWWRooT\BIN [Create a BIN Folder in WWWRoot]

Making use of WebService in client asp/aspx page

<%@ import Namespace = "NameSp" %>
<script language = "c#" runat = "server">
public void Page_Load(object o, EventArgs e){
int x = 10;
int y = 5;
int sum;
//Instantiating the public class of the webservice
AddNumbers AN = new AddNumbers();
sum = AN.Add(x,y);
string str = sum.ToString();
response.writeline(str);
}
</script>

Note

It is advisable to

1. Copy the .asmx file to the foldercontaining WSDL aplication (C:\ProgramFiles\Microsoft.NET\FrameworkSDK\Bin) before creating cs file.

2. Copy the created .cs file to the folder containing CSC application

(C:\WINNT\Microsoft.NET\Framework\v1.0.2914) before compliling it.

This article will try to explain the how you can build web servicesand/or clients with any of the three languages: .NET, MS SOAP Toolkitand Java. But the real point of the article is to show you how you canbuild clients for web services from any of above-mentioned languages. Not long ago .NET was released and many of usjumped on to write ASP.NET web sites, C# programs or Web Services. Iwas really amazed by the relatively easy way someone can write a webservice with .NET. I previously had written some web services with MSSOAP Toolkit and Apache SOAP for Java. And then someone asked me towrite clients using different languages for those web services. Itproved to be not trivial. Although SOAP is now a standard, differentimplementations of web services are using it in ways that sometimemakes the interoperability with other SOAPs hard if not impossible. My sample application is a very simple webservice with one method: addNumbers. As you already deducted it willadd two numbers and return the result. The name of the application isHello2 and the source files are attached to this message. STK Service and Clients First let?s write the Web Service using the MS SOAP Toolkit with an ASP listener and an ISAPI listener as well. The addNumbers method in the Visual Basic class is:

Public Function addNumbers(ByVal NumberOne As Double, ByVal NumberTwo As Double) As Double
addNumbers = NumberOne + NumberTwo
End Function

Using the WSDLGen.exe wizard you can generate the ISAPI listener, theASP listener or both (not at the same time, of course). I choosed togenerate both the ASP and the ISAPI listener, so I named my WSDL filesHello2ASP.WSDL respectively Hello2Isapi.WSDL. Now let?s write some clients for this Hello2 web service. STK Client The first client is aVisual Basic client using high level API in SOAP Toolkit. Create a VBproject add a form and then a button. The code bellow is executed whenthe button is hit.

Private Sub cmdDoTest_Click()
Const WS_URL = "http://localhost/Hello2/Hello2Isapi.WSDL"

Dim objHello2ISapi As SoapClient
Dim nResult As Double, NumberOne As Double, NumberTwo As Double

On Error GoTo catch_err
Set objHello2ISapi = New SoapClient
Call objHello2ISapi.mssoapinit(WS_URL)

NumberOne = 10
NumberTwo = 25
nResult = objHello2ISapi.addNumbers(NumberOne, NumberTwo)
MsgBox nResult

cleanup:
Set objHello2ISapi = Nothing
Exit Sub

catch_err:
MsgBox Err.Description
Resume cleanup
End Sub

As you cansee the client is pretty simple and there are no problems. All thedetails like building the SOAP request message and parsing the resultSOAP message is hidden from the programmer.WS_URL is the URL of the service. The high level API in SOAP Toolkitneeds a WSDL file so this URL points to one of the WSDL files. At thispoint it doesn?t matter which one you provide. Though, the performanceis better with the ISAPI listener. Java Client The second client we?ll write for our Hello2 server is a Java client. Iused for this the Apache SOAP 2.1. You can download it for free fromhttp://xml.apache.org/soap/index.html.

The Java class file for the ASP listener is listed bellow.

import java.io.*;
import java.util.*;
import java.net.*;
import org.w3c.dom.*;
import org.apache.soap.util.xml.*;
import org.apache.soap.*;
import org.apache.soap.encoding.*;
import org.apache.soap.encoding.soapenc.*;
import org.apache.soap.rpc.*;
import org.apache.soap.transport.http.SOAPHTTPConnection;

public class testClient {

public static void main(String[] args) throws Exception {

URL url = new URL ("http://localhost/Hello2/Hello2.asp");

SOAPMappingRegistry smr = new SOAPMappingRegistry ();
StringDeserializer sd = new StringDeserializer ();
smr.mapTypes (Constants.NS_URI_SOAP_ENC, new QName ("", "Result"), null, null, sd);

// create the transport and set parameters
SOAPHTTPConnection st = new SOAPHTTPConnection();

// build the call.
Call call = new Call ();
call.setSOAPTransport(st);
call.setSOAPMappingRegistry (smr);

call.setTargetObjectURI ("http://tempuri.org/message/");
call.setMethodName("addNumbers");
call.setEncodingStyleURI ("http://schemas.xmlsoap.org/soap/encoding/");

Vector params = new Vector();
params.addElement(new Parameter("NumberOne", Double.class, "10", null));
params.addElement(new Parameter("NumberTwo", Double.class, "25", null));
call.setParams(params);

Response resp = null;
try {
resp = call.invoke (url, "http://tempuri.org/action/Hello2.addNumbers");
}
catch (SOAPException e) {
System.err.println("Caught SOAPException (" + e.getFaultCode () + "): " + e.getMessage ());
return;
}

// check response
if (resp != null && !resp.generatedFault()) {
Parameter ret = resp.getReturnValue();
Object value = ret.getValue();

System.out.println ("Answer–> " + value);
}
else {
Fault fault = resp.getFault ();
System.err.println ("Generated fault: ");
System.out.println (" Fault Code = " + fault.getFaultCode());
System.out.println (" Fault String = " + fault.getFaultString());
}
}
}

As you cansee the url variable points to the ASP listener. To point the Javaclient to the ISAPI listener make the following change: URL url = new URL ("http://localhost/Hello2/Hello2Isapi.wsdl"); .NET Client Now it is time to writea .NET client for our Hello2 Web service. Using the WSDL.exe tool from.NET Framework Beta 2 you must generate a proxy class for our service.Execute following command. wsdl http://localhost/Hello2/Hello2Isapi.wsdl This will generate Hello2Isapi.cs file. Thisis the .NET proxy class using C# (this is the default language used).Check out the params for wsdl.exe to generate the proxy using VB.NET oranother language.Now compile the proxy using csc.exe /t:library Hello2Isapi.cs It?s time to write the .NET client, which usesthe proxy class to access the Hello2 web service. Here is the code forthe C# client.

using System;

public class Hello2ISapiClient {
public static void Main() {
Hello2Isapi srv = new Hello2Isapi();
double res = 0, num1 = 10, num2 = 25;

res = srv.addNumbers(num1, num2);

Console.WriteLine("{0}+{1}={2}", num1, num2, res);
}
}

Compile the client using Hello2IsapiClient.cs /refere nce:Hell o2Isapi.dll and run it with Hello2IsapiClient. At this point we have a MS SOAP Toolkit web service and three clients written with: SOAP Toolkit, Java respectively .NET Apache SOAP for Java Service and Clients Let?s move on now and write the same service using Apache SOAP for Java. Here is the service:

package samples.MyService;

import java.util.*;
import org.w3c.dom.*;
import org.apache.soap.util.xml.*;

public class MyService {
public double addNumbers(double num1, double num2) {
return num1+num2;
}
}

I used thename MyService for my service and I added it to the samples package.This way you don?t need to add a context into the Tomcat server. Justdeploy the service into SOAP using the following deployment descriptorfile:

<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment" id="urn:myservice-service" checkMustUnderstands="false">
<isd:provider type="java" scope="Application" methods="addNumbers">
<isd:java class="samples.MyService.MyService" static="false"/>
</isd:provider>
</isd:service>

I won?t explain here how to set up Apache SOAP into Tomcat since there is enough guidance in the Apache SOAP documentation. Apache SOAP Client It?s time to write the clients for this service. The first one is written using Java. Here is the code:

package samples.MyService;

import java.io.*;
import java.util.*;
import java.net.*;
import org.w3c.dom.*;
import org.apache.soap.util.xml.*;
import org.apache.soap.*;
import org.apache.soap.encoding.*;
import org.apache.soap.encoding.soapenc.*;
import org.apache.soap.rpc.*;

public class client {
public static void main(String[] args) throws Exception {
if (args.length != 3
&& (args.length != 4 || !args[0].startsWith("-")))
{
System.err.println("Usage:");
System.err.println(" java " + client.class.getName() +
" [-encodingStyleURI] SOAP-router-URL nameToLookup");
System.exit (1);
}

// Process the arguments.
int offset = 4 – args.length;
String encodingStyleURI = args.length == 4
? args[0].substring(1)
: Constants.NS_URI_SOAP_ENC;
URL url = new URL(args[1 - offset]);
Double num1 = new Double(args[2 - offset]),
num2 = new Double(args[3 - offset]);

SOAPMappingRegistry smr = new SOAPMappingRegistry();
BeanSerializer beanSer = new BeanSerializer();

System.out.println(encodingStyleURI);
System.out.println(url);
System.out.println(num1);
System.out.println(num2);

// Build the call.
Call call = new Call();

call.setSOAPMappingRegistry(smr);
call.setTargetObjectURI("urn:MyService");
call.setMethodName("addNumbers");
call.setEncodingStyleURI(encodingStyleURI);

Vector params = new Vector();

params.addElement(new Parameter("num1", Double.class, num1, null));
params.addElement(new Parameter("num2", Double.class, num2, null));
call.setParams(params);

// Invoke the call.
Response resp;

long nErrors = 0;
Calendar cal = Calendar.getInstance();
Date startTime = cal.getTime(), endTime;

try {
resp = call.invoke(url, "");
}
catch (SOAPException e) {
System.out.println("i=" + i);
System.err.println("Caught SOAPException (" +
e.getFaultCode() + "): " +
e.getMessage());
return;
}

// Check the response.
if (!resp.generatedFault()) {
Parameter ret = resp.getReturnValue();
Object value = ret.getValue();

//System.out.println(value != null ? "\n" + value : "I don't know.");
}
else {
Fault fault = resp.getFault();

System.err.println("Generated fault: ");
System.out.println (" Fault Code = " + fault.getFaultCode());
System.out.println (" Fault String = " + fault.getFaultString());
}

cal = Calendar.getInstance();
endTime = cal.getTime();
System.out.println("Start time="+startTime);
System.out.println("End time="+endTime);
System.out.println ("Errors=" + nErrors);

}
}

As you can see the code is pretty straightforward. No problems expected since the same SOAP library is used.The code for a STK client is bellow: STK Client There are errors in both high level and low level clients because xsi:type is required in Apache SOAP for Java. .NET Client Due to the same issue a .NET client won?t work either. .NET Service and Clients .NETFramework Beta 2 is the newest technology and changes are expected tohappen from Beta 2 to the final release. Major changes already havebeen made when Beta 2 was released. This is no surprise since Microsofthad warned developers that might happen. Writing a web service with .NET is very simpleand can be done in several ways. I choose to write my web service in C#using a ASMX file. Here is the content of the file.

<%@ WebService Language="C#" Class="MyService" %>

using System;
using System.Web.Services;

[WebService(Namespace="http://www.catalin.com/webservices/")]
public class MyService: WebService {
[ WebMethod(Description="return the sum of two numbers")]
[System.Web.Services.Protocols.SoapRpcMethodAttribute(
"http://www.catalin.com/webservices/addNumbers",
RequestNamespace="http://www.catalin.com/webservices/",
ResponseNamespace="http://www.catalin.com/webservices/")]
public double addNumbers(double numberOne, double numberTwo) {
return numberOne + numberTwo;
}
}

Theadvantage of using a ASMX file is that no compilation is needed so ahot deployment can be done.Place the file into a virtual directory under IIS. You can test theservice with your IE with http://localhost/testdotnetws/myservice.asmx.NET Client
Writing a client for this service is similarwith the .NET client we write earlier. When generating the proxy filespecify the WSDL file withhttp://localhost/testdotnetws/myservice.asmx?WSDL. This is the way .NETframework creates the WSDL file on-demand.

STK Client
Using the high level APIwould be a faster solution but there are some issues there and Icouldn?t solve them out so I used the low level API. The client code isnot difficult. The only trick is to enable the .NET service for RPCtype of calls. Thanks to Christian Weyer who helped me with this issue.Look at the web service code and notice theSystem.Web.Services.Protocols.SoapRpcMethodAttribute attribute for ourmethod. Without this attribute the default type of conversation in .NETis ?message?.

Java Client
In the java client you?ll have to modify the url as follows:

<

p>URL url = new URL ("http://localhost/aspnet_test/myservice/myservice.asmx");

Compile and run.

I hope this short trip to the web service world was helpful for those of you who are involved in web services development.

Happy SOAP-ing!