Do Webservice support data reader ?

Do webservices support data reader?

No. However it does support a dataset.

What is UDDI?

UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.

UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.

At its core, UDDI consists of two parts.

First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.

Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.

The data captured within UDDI is divided into three main categories:

White Pages: This includes general information about a specific company. For example, business name, business description, and address.

Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.

Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.

You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.

What is SOAP and how does it relate to XML?

The Simple Object Access Protocol (SOAP) uses XML to define a protocol
for the exchange of information in distributed computing environments.
SOAP consists of three components: an envelope, a set of encoding
rules, and a convention for representing remote procedure calls.
Unless experience with SOAP is a direct requirement for the open
position, knowing the specifics of the protocol, or how it can be
used in conjunction with HTTP, is not as important as identifying
it as a natural application of XML.

Overloading Web Services

The procedure to solve this problem is very easy. Start each method with a Web Method attribute. Add Description property to add a description of web method and MessageName property to change web method name.


namespace TestOverloadingWebService

{

[WebService(Namespace = "http://tempuri.org/", Description=" <b> Function

overloading in Web Services </b>")]

public class OverloadingInWebService : System.Web.Services.WebService

{

[WebMethod(MessageName = "AddInt", Description = "Add two integer

Value", EnableSession = true)]

public int Add(int a, int b)

{

return (a + b);

}

[WebMethod(MessageName = "AddFloat", Description = "Add two Float

Value", EnableSession = true)]

public float Add(float a, float b)

{

return (a + b);

}

}

}

What is SOAP?

SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.

What are the consideration in deciding to use .NET Remoting or ASP.NET Web Services?

Remoting is a more efficient communication exchange when you can control both ends of the application involved in the communication process. Web Services provide an open-protocol-based exchange of informaion. Web Services are best when you need to communicate with an external organization or another (non-.NET) technology.

Can you give an example of when it would be appropriate to use a web service as opposed to a non-serviced .NET component?

When to use Web Service:

1. Communicating through a Firewall When building a distributed application with 100s/1000s of users spread over multiple locations, there is always the problem of communicating between client and server because of firewalls and proxy servers. Exposing your middle tier components as Web Services and invoking the directly from a Windows UI is a very valid option.

2. Application Integration When integrating applications written in various languages and running on disparate systems. Or even applications running on the same platform that have been written by separate vendors.

3. Business-to-Business Integration This is an enabler for B2B intergtation which allows one to expose vital business processes to authorized supplier and customers. An example would be exposing electronic ordering and invoicing, allowing customers to send you purchase orders and suppliers to send you invoices electronically.

4. Software Reuse This takes place at multiple levels. Code Reuse at the Source code level or binary componet-based resuse. The limiting factor here is that you can reuse the code but not the data behind it. Webservice overcome this limitation. A scenario could be when you are building an app that aggregates the functionality of serveral other Applicatons. Each of these functions could be performed by individual apps, but there is value in perhaps combining the the multiple apps to present a unifiend view in a Portal or Intranet.

When not to use Web Services:

1. Single machine Applicatons When the apps are running on the same machine and need to communicate with each other use a native API. You also have the options of using component technologies such as COM or .NET Componets as there is very little overhead.

2. Homogeneous Applications on a LAN If you have Win32 or Winforms apps that want to communicate to their server counterpart. It is much more efficient to use DCOM in the case of Win32 apps and .NET Remoting in the case of .NET Apps.