WebServices in c# ASP.Net

URL Rewrite

2011-05-09T09:38:00.002-07:00

IIS URL Rewrite 2.0 enables Web administrators to create powerful rules to implement URLs that are easier for users to remember and easier for search engines to find. By using rule templates, rewrite maps, .NET providers, and other functionality integrated into IIS Manager, Web administrators can easily set up rules to define URL rewriting behavior based on HTTP headers, HTTP response or request headers, IIS server variables, and even complex programmatic rules. In addition, Web administrators can perform redirects, send custom responses, or stop HTTP requests based on the logic expressed in the rewrite rules.

Define powerful rules to transform complex URLs into simple and consistent Web addresses
URL Rewrite allows Web administrators to easily build powerful rules using rewrite providers written in .NET, regular expression pattern matching, and wildcard mapping to examine information in both URLs and other HTTP headers and IIS server variables. Rules can be written to generate URLs that can be easier for users to remember, simple for search engines to index, and allow URLs to follow a consistent and canonical host name format. URL Rewrite further simplifies the rule creation process with support for content rewriting, rule templates, rewrite maps, rule validation, and import of existing mod_rewrite rules.

Easily replace Web application URLs to produce user and search engine friendly results
URL Rewrite permits Web administrators to easily replace the URLs generated by a Web application in the response HTML with a more user friendly and search engine friendly equivalent. Links can be modified in the HTML markup generated by a Web application behind a reverse proxy. URL Rewrite makes things easier for outbound response content and headers rewriting with outbound rewrite rules that work with HTTP request and response headers and with IIS server variables.

Seamless integration with existing IIS features that improve management, performance, and troubleshooting
URL Rewrite is tightly integrated with IIS Manager for better management. In addition, URL Rewrite supports both user-mode and kernel-mode caching for faster performance. URL Rewrite also supports Failed Request Tracing for enhanced troubleshooting of application logic execution.

Features
Rules-based URL rewriting engine
Rules-based response rewriting engine
Support for custom .NET rewrite providers
Regular expression pattern matching
Wildcard pattern matching
Global and distributed rewrite rules
Rewriting within the content of specific HTML tags
Pre-conditions for outbound rules
Access to server variables and HTTP headers
Rewriting of server variables and HTTP request headers
Rewriting of HTTP response headers
Allow list for server variables
HtmlEncode function
Built-in rule templates
Reverse proxy rule template
Rule templates for Search Engine Optimization
Various rule actions including redirect and request abort
Tracking capture groups across rule conditions
Logging of rewritten URLs
Updated user interface in IIS Manager
Integrated user interface for managing rewrite rules and rewrite maps
Integrated user interface for importing of Apache mod_rewrite rules
Integrated user interface for testing regular expression and wildcard patterns
Support for IIS kernel-mode and user-mode output caching
Lowercase conversion function
Rewrite maps to generate the substitution URL during rewriting
Failed Request Tracing support

URL Rewriting -Introduction

2011-05-09T09:38:00.001-07:00

Take a moment to look at some of the URLs on your website. Do you find URLs like http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary? Or maybe you have a bunch of Web pages that were moved from one directory or website to another, resulting in broken links for visitors who have bookmarked the old URLs. In this article we'll look at using URL rewriting to shorten those ugly URLs to meaningful, memorable ones, by replacing http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary with something like http://yoursite.com/people/sales/chuck.smith. We'll also see how URL rewriting can be used to create an intelligent 404 error.

URL rewriting is the process of intercepting an incoming Web request and redirecting the request to a different resource. When performing URL rewriting, typically the URL being requested is checked and, based on its value, the request is redirected to a different URL. For example, in the case where a website restructuring caused all of the Web pages in the /people/ directory to be moved to a /info/employees/ directory, you would want to use URL rewriting to check if a Web request was intended for a file in the /people/ directory. If the request was for a file in the /people/ directory, you'd want to automatically redirect the request to the same file, but in the /info/employees/ directory instead.

With classic ASP, the only way to utilize URL rewriting was to write an ISAPI filter or to buy a third-party product that offered URL rewriting capabilities. With Microsoft® ASP.NET, however, you can easily create your own URL rewriting software in a number of ways. In this article we'll examine the techniques available to ASP.NET developers for implementing URL rewriting, and then turn to some real-world uses of URL rewriting. Before we delve into the technological specifics of URL rewriting, let's first take a look at some everyday scenarios where URL rewriting can be employed.

LINQ TO SQL Tutorial

2011-04-20T17:04:00.000-07:00

Windows Communication Foundation (WCF)

2009-11-15T07:12:00.000-08:00

Windows Communication Foundation (WCF) is an SDK for developing and deploying services on Windows. WCF provides a runtime environment for your services, enabling you to expose CLR types as services, and to consume other services as CLR types. Although in theory you could build services without WCF, in practice building services is significantly easier with WCF. WCF is Microsoft’s implementation of a set of industry standards defining service interactions, type conversion, marshaling, and various protocols’ management. Because of that, WCF provides interoperability between services. WCF provides developers with the essential off-the-shelf plumbing required by almost any application, and as such, it greatly increases productivity. The first release of WCF provides many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security. WCF also has an elegant extensibility model that you can use to enrich the basic offering. In fact, WCF itself is written using this extensibility model. The rest of the chapters in this book are dedicated to those aspects and features. Most all of the WCF functionality is included in a single assembly called System.ServiceModel.dll in the System.ServiceModel namespace.

WCF is part of .NET 3.0 and requires .NET 2.0, so it can only run on operation systems that support it. Presently this list consists of Windows Vista (client and server), Windows XP SP2, and Windows Server 2003 SP1 or their later versions.

Services' Execution Boundaries
With WCF, the client never interacts with the service directly, even when dealing with a local, in-memory service. Instead, the client always uses a proxy to forward the call to the service. The proxy exposes the same operations as the service, plus some proxy-management methods.

WCF allows the client to communicate with the service across all execution boundaries. On the same machine the client can consume services in the same app domain, across app domains in the same process, or across processes.

Addresses
In WCF, every service is associated with a unique address. The address provides two important elements: the location of the service and the transport protocol or transport schema used to communicate with the service. The location portion of the address indicates the name of the target machine, site, or network; a communication port, pipe, or queue; and an optional specific path or URI. A URI is a Universal Resource Identifier, and can be any unique string, such as the service name or a GUID.

WCF 1.0 supports the following transport schemas:

HTTP
TCP
Peer network
IPC (Inter-Process Communication over named pipes)
MSMQ
Addresses always have the following format:

[base address]/[optional URI]
The base address is always in this format:

[transport]://[machine or domain][:optional port]
Here are a few sample addresses:

http://localhost:8001
http://localhost:8001/MyService
net.tcp://localhost:8002/MyService
net.pipe://localhost/MyPipe
net.msmq://localhost/private/MyService
net.msmq://localhost/MyService
The way to read an address such as

http://localhost:8001
is like this: "Using HTTP, go to the machine called localhost, where on port 8001 someone is waiting for my calls."

If there is also a URI such as:

http://localhost:8001/MyService
then the address would read as follows: "Using HTTP, go to the machine called localhost, where on port 8001 someone called MyService is waiting for my calls."
Contracts
In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does. WCF defines four types of contracts.
Service contracts
Describe which operations the client can perform on the service. Service contracts are the subject of the next chapter, but are used extensively in every chapter in this book.
Data contracts
Define which data types are passed to and from the service. WCF defines implicit contracts for built-in types such as int and string, but you can easily define explicit opt-in data contracts for custom types. Chapter 3 is dedicated to defining and using data contracts, and subsequent chapters make use of data contracts as required.
Fault contracts
Define which errors are raised by the service, and how the service handles and propagates errors to its clients. Chapter 6 is dedicated to defining and using fault contracts.
Message contracts
Allow the service to interact directly with messages. Message contracts can be typed or untyped, and are useful in interoperability cases and when there is an existing message format you have to comply with. As a WCF developer, you should use message contracts only rarely, so this book makes no use of message contracts.

WCF Architecture
So far in this chapter, I’ve covered all that is required to set up and consume simple WCF services. However, as described in the rest of the book, WCF offers immensely valuable support for reliability, transactions, concurrency management, security, and instance activation, all of which rely on the WCF interception-based architecture. Having the client interact with a proxy means that WCF is always present between the service and the client, intercepting the call and performing pre-and post-call processing. The interception starts when the proxy serializes the call stack frame to a message and sends the message down a chain of channels. The channel is merely an interceptor, whose purpose is to perform a specific task. Each client-side channel does pre-call processing of the message. The exact structure and composition of the chain depends mostly on the binding. For example, one of the channels may be responsible for encoding the message (binary, text, or MTOM), another for passing security call context, another for propagating the client transaction, another for managing the reliable session, another for encrypting the message body (if so configured), and so on. The last channel on the client side is the transport channel, which sends the message over the configured transport to the host.

On the host side, the message goes through a chain of channels as well, which perform host-side pre-call processing of the message. The first channel on the host side is the transport channel, which receives the message from the transport. Subsequent channels perform various tasks, such as decryption of the message body, decoding of the message, joining the propagated transaction, setting the security principal, managing the session, and activating the service instance. The last channel on the host side passes the message to the dispatcher. The dispatcher converts the message to a stack frame and calls the service instance.
The service has no way of knowing it was not called by a local client. In fact, it was called by a local client—the dispatcher. The interception both on the client and the service side ensures that the client and the service get the runtime environment they require to operate properly. The service instance executes the call and returns control to the dispatcher, which then converts the returned values and error information (if any) to a return message. The process is now reversed: the dispatcher passes the message through the host-side channels to perform post-call processing, such as managing the transaction, deactivating the instance, encoding the reply, encrypting it, and so on. The returned message goes to the transport channel, which sends it to the client-side channels for client-side post-call processing, which consists of tasks such as decryption, decoding, committing or aborting the transaction, and so on. The last channel passes the message to the proxy. The proxy converts the returned message to a stack frame and returns control to the client.

Most noteworthy is that almost all the points in the architecture provide hooks for extensibility—you can provide custom channels for proprietary interaction, custom behaviors for instance management, custom security behavior, and so on. In fact, the standard facilities that WCF offers are all implemented using the same extensibility model. You will see many examples and uses for extensibility throughout this book

Host Architecture
It is also interesting to explore how the transition is made from a technology-neutral, service-oriented interaction to CLR interfaces and classes. The bridging is done via the host. Each .NET host process can have many app domains. Each app domain can have zero or more service host instances. However, each service host instance is dedicated to a particular service type. When you create a host instance, you are in effect registering that service host instance with all the endpoints for that type on the host machine that correspond to its base addresses. Each service host instance has zero or more contexts. The context is the innermost execution scope of the service instance. A context is associated with at most one service instance, meaning it could also be empty, without any service instance.

Calling Webservices from ASP.NET: Example Google Web Service

2009-06-01T07:00:00.000-07:00

What are Web services?
Web services is a fairly new technology that has been around for the past few years. Web services is a conduit for providing application services between disparate applications using eXtended Markup Language (XML). The web services technology we feel is finally beginning to mature a bit.
The idea of web services as a mechanism for bridging disparate systems - is not new. Web services is really just a slight twist of an old technology. It is basically Remote Procedure Calls (RPC) over HTTP.
Initially it was proscribed as the panacea to solve all IT application integration problems. This has not been fully realized because of many issues - such as lack of development tools at the on-set to support the infrastructure, security concerns, complexity, network speed and object serialization/deserialization processing speed. Nevertheless, web services are proving to be a very useful tool when used sparin

What's the big deal with Web Services?
The big deal with webservices is how it differentiates itself from prior standards such as DCOM, CORBA, Java Remote Method Invocation (RMI). In a nutshell - these standards were designed to perform a similar function to web services, but the problem with them is that interoperation between them was too complicated and too expensive. For example to integrate one system using DCOM with another using CORBA would require using a bridge.
Web services is a more widely accepted univeral standard. Java has a web services tool kit, ASP.NET has one, and so do other languages and environments. It's probably one of the first times that all big players have come to an agreement on a standard.
If Web services is so great and such an obvious solution - why didn't we do it 10 years ago?The reason is simple. We couldn't. There is always a trade-off between standardization, speed and simplicity. Web services are inherently slower than other standards because of the need to convert an XML blob of text into an object. 10 years ago we could not afford this speed crunch, and also the need of interoperation between Joe here and Jim 20 miles away was not feasable because of network issues. Web services then was simply an answer to a problem that was way down on the totem pole of our concerns.

Does web services completely replace DCOM, CORBA, or Java RMI?
NO. The reason is very simple. Each of the aforementioned standards - while difficult to integrate with other standards -- work well in the environments they were designed for and are highly optimized for those environments. E.g if all your apps are in DCOM - it makes sense to integrate them with DCOM, but if you need to collaborate with your neighbor next door and you don't know what he uses - go with an open-standard such as Web Services for that integration.

What makes up a Web Service?

The current web services standard as defined by the W3C org is composed of 4 main parts.
The service which is usually performed by a web server that listens for requests of the service. This is generally just a web like page or cgi script that gets posted to similar to the way other http web requests are done. Instead of returning HTML though it returns a formalized XML message in Simple Object Application Protocol (SOAP) format etc.
The service description - specified in Web Services Description Language (WSDL) - this description defines the web methods (functions) that a service will accept - the inputs that go into these methods, and the format of the output that can be expected in return. It is the contract or message signature of the service. This is what you will need to generate a web service client proxy.

The .NET SDK comes with a utility WSDL.exe that will autogenerate a client proxy class in .vb or C# given a .wsdl file.

The web service registry This piece is basically a directory of web services. The current standard is Universal Description, Discovery, and Integration (UDDI). This is an optional piece because a web service need not be listed in a UDDI registry to be used. The registry is just a nice way of cataloging available services - similar to what Java Naming and Directory Service (JNDI) does for Java.

Finally there is the web service client proxy - which negotiates the communication between a web service and a client. It accepts the inputs and requests - passes it off to the web service - waits for the service to respond and then converts the response to something meaningful. This is known as serialization/deserialization - conversion from the web service XML response back to an object and conversion of a user request to XML format required by the service.

Google Web service
Incorporating a search engine seamlessly into ones site is a feature very commonly needed. The new Google Web Service (currently in beta) and the ample support in ASP.NET for web services - makes this a snap. In this article we detail how to call this particular service in ASP.NET.

Setting up

Download the Google API from http://www.google.com/apis/ and then follow the instructions to acquire a search key.
Get the >NET SDK if you don't have it already and don't have VS.NET
You can use the packaged Google api web service proxy or generate your own proxy class using the wsdl.exe util that comes packaged with ASP.NET SDK.
Compile the proxy class using a command something like vbc /t:library /out:Google.dll Google.vb /r:System.web.dll /r:System.web.Services.dll /r:System.data.dll /r:system.dll /r:System.xml.dll Note that for this we renamed the generated proxy class file to Google.vb mostly for clarity.
Next copy the generated Google.dll into the bin folder of your web app.
Add an entry in Web.config to hold the google key you received -- in ours we put it in the appsettings section of web.config and called the key googlekey. Alternatively, you can hard-code the key in the search page.
Write the search page - a sample of our code is shown in the next section

for more information goto http://www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=13

Top Ten FAQs for Web Services

2009-05-21T14:35:00.000-07:00

1. What is a Web service?
Many people and companies have debated the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.

XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.

Beyond this basic definition, a Web service may also have two additional (and desirable) properties:

First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL). (See FAQ number 7.)

Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration. (See FAQ number 8.)

Web services currently run a wide gamut from news syndication and stock-market data to weather reports and package-tracking systems. For a quick look at the range of Web services currently available, check out the XMethods directory of Web services.

2. What is new about Web services?
People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.

So, what is really new about Web services? The answer is XML.

XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.

Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.

By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.

3. I keep reading about Web services, but I have never actually seen one. Can you show me a real Web service in action?
If you want a more intuitive feel for Web services, try out the IBM Web Services Browser, available on the IBM Alphaworks site. The browser provides a series of Web services demonstrations. Behind the scenes, it ties together SOAP, WSDL, and UDDI to provide a simple plug-and-play interface for finding and invoking Web services. For example, you can find a stock-quote service, a traffic-report service, and a weather service. Each service is independent, and you can stack services like building blocks. You can, therefore, create a single page that displays multiple services--where the end result looks like a stripped-down version of my.yahoo or my.excite.

4. What is the Web service protocol stack?
The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:

Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).

XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.

Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.

Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.

Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language .

Fortunately, you do not need to understand the full protocol stack to get started with Web services. Assuming you already know the basics of HTTP, it is best to start at the XML Messaging layer and work your way up.

5. What is XML-RPC?
XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.

More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.

Because XML-RPC is platform independent, diverse applications can communicate with one another. For example, a Java client can speak XML-RPC to a Perl server.

To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):

weather.getWeather

10016

The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).

Here is a sample XML-RPC response from the weather service:

65

The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.

In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.

The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.

6. 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.

To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):

The request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).

Here is a sample SOAP response from the weather service:

The response indicates a single integer return value (the current temperature).

The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.

7. What is WSDL?
The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.

In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:

Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.

WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.

Below is a sample WSDL file. This file describes the public interface for the weather service used in the SOAP example above. Obviously, there are many details to understanding the example. For now, just consider two points.

First, the elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the element specifies that the service is available via SOAP and is available at a specific URL.

Using WSDL, a client can locate a Web service, and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code.

8. 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.

9. How do I get started with Web Services?
The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.

Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. These topics are also covered in Web Services Essentials. For a comprehensive treatment of SOAP, check out O'Reilly's Programming Web Services with SOAP, by Doug Tidwell, James Snell, and Pavel Kulchenko.

10. Does the W3C support any Web service standards?
The World Wide Web Consortium (W3C) is actively pursuing standardization of Web service protocols. In September 2000, the W3C established an XML Protocol Activity. The goal of the group is to establish a formal standard for SOAP. A draft version of SOAP 1.2 is currently under review, and progressing through the official W3C recommendation process.

Amazon Simple Storage Service

2009-05-10T20:22:00.000-07:00

Amazon S3 is storage for the Internet. It is designed to make web-scale computing easier for developers.

Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers.
Amazon S3 is intentionally built with a minimal feature set.

Write, read, and delete objects containing from 1 byte to 5 gigabytes of data each. The number of objects you can store is unlimited.
Each object is stored in a bucket and retrieved via a unique, developer-assigned key.

A bucket can be located in the United States or in Europe. All objects within the bucket will be stored in the bucket’s location, but the objects can be accessed from anywhere.
Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access. Objects can be made private or public, and rights can be granted to specific users.
Uses standards-based REST and SOAP interfaces designed to work with any Internet-development toolkit.
Built to be flexible so that protocol or functional layers can easily be added. Default download protocol is HTTP. A BitTorrent™ protocol interface is provided to lower costs for high-scale distribution. Additional interfaces will be added in the future.
Reliability backed with the Amazon S3 Service Level Agreement.

Basic of Web Service & Web services architecture

2009-05-10T18:18:00.001-07:00

Web services architecture

A Web service (also Web Service) is defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network".[1] Web services are frequently just Internet application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. Other approaches with nearly the same functionality as web services are Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA), Microsoft's Distributed Component Object Model (DCOM) or SUN's Java/Remote Method Invocation (RMI).

The W3C Web service definition encompasses many different systems, but in common usage the term refers to clients and servers that communicate over the HTTP protocol used on the Web. Such services tend to fall into one of two camps: Big Web Services and RESTful Web Services.

"Big Web Services" use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks (frameworks such as Spring, Apache Axis2 and Apache CXF being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web service.

More recently, REpresentational State Transfer (RESTful) Web services have been regaining popularity, particularly with Internet companies. These also meet the W3C definition, and are often better integrated with Hypertext Transfer Protocol (HTTP) than SOAP-based services. They do not require XML messages or WSDL service-API definitions.

List of web service protocols

2009-05-10T18:15:00.000-07:00

The following is a list of Web service protocols.

BEEP - Blocks Extensible Exchange Protocol
E-Business XML
Hessian
JSON-RPC
REST (Representational State Transfer)
SOAP - outgrowth of XML-RPC, originally an acronym for Simple Object Access Protocol
Universal Description, Discovery, and Integration (UDDI)
Web Services Description Language (WSDL)
WSFL - Web Services Flow Language (superseded by BPEL)
WSCL - Web Services Conversation Language
XINS Standard Calling Convention - HTTP parameters in (GET/POST/HEAD), POX out
XLANG - XLANG-Specification (superseded by BPEL)
XML-RPC - XML Remote Procedure Call

ASP.FAQ

2009-04-22T08:50:00.000-07:00

ASP.Net FAQ api_user_11797_sreshyamsundar

Publish at Scribd or explore others:

2009-04-18T04:42:00.000-07:00

C# and VB.NET Comparison Cheat Sheet

Illustrated C# 2008

2009-04-18T04:37:00.000-07:00

Download your free ebook
If you're a C++ or VB programmer migrating to C# 2008, this book is well worth reading. The author, Daniel Solis offers a very visual approach – with lots of figures, diagrams and code samples – that will help you get to work with C# fast.

2009-04-18T04:32:00.000-07:00

Convert C# to VB.NET

Convert VB.NET to C#

Introduction to Webservices

2008-10-25T22:27:00.001-07:00

Webservices

View SlideShare presentation or Upload your own. (tags: webservices .net)

Introduction To Csharp

2008-10-25T22:25:00.001-07:00

Introduction To Csharp

View SlideShare presentation or Upload your own.

Dotnet interview questions..

2008-10-25T22:23:00.000-07:00

Dotnet Interview Questions

View SlideShare presentation or Upload your own. (tags: .net dotnet)

Introduction to SOAP

2008-09-22T08:53:00.000-07:00

SOAP (Simple Object Access Protocol) is a simple solution for interaction of different applications built in different languages and running on different platforms as it uses HTTP as its transport and XML as its payload for sending and receiving messages. Its is a lightweight and a loosely coupled protocol for exchange of information in a decentralized and a distributed environment.

A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.
HTTP + XML = SOAP
A SOAP request could be an HTTP POST or an HTTP GET request.

SOAP stands for Simple Object Access Protocol
SOAP is a communication protocol
SOAP is for communication between applications
SOAP is a format for sending messages
SOAP is designed to communicate via Internet
SOAP is platform independent
SOAP is language independent
SOAP is based on XML
SOAP is simple and extensible
SOAP allows you to get around firewalls
SOAP will be developed as a W3C standard

Why SOAP?
It is important for application development to allow Internet communication between programs.
Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.
SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

Soap relies on HTTP as a transport mechanism to send XML based messages, the messages are packed in what is called a SOAP envelop and send to the server to process in a Request/Response fashion. SOAP unlike proprietary protocols like DCOM or RMI does not require strong connection between client and the server and the SOAP messages are sting based messages passed from the Client to Server and vice versa in the form of SOAP envelops.

Syntax Rules
Here are some important syntax rules:
A SOAP message MUST be encoded using XML
A SOAP message MUST use the SOAP Envelope namespace
A SOAP message MUST use the SOAP Encoding namespace
A SOAP message must NOT contain a DTD reference
A SOAP message must NOT contain XML Processing Instructions
Skeleton SOAP Message

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
...

...
...

...
...

SOAP and Security
SOAP as it works on HTTP get the benefits of all the security that are currently available to HTTP, a SOAP message can pass through the firewall of the web server normally from port 80.
Limitations of SOAP Though SOAP is evolving, and has a number of striking features, which are important in development of, distributed applications but still there are certain things which SOAP cannot support which I would like to address
SOAP is a simple protocol: As the name suggests it's a simple protocol and works on HTTP, we cannot expect all the functionality's offered by other protocols like DCOM or RMI.
SOAP may turn out to be slower compared to other proprietary protocols as it requires additional XML processing.
Still SOAP fares well in most areas compared to other wire protocol. As per the specifications, SOAP can also use other transport carrier like SMTP to transmit SOAP messages. Still lot of information on this topic in not available.

web services in c#

2008-08-08T19:25:00.000-07:00

Introduction of web services

The term "web service" has been used quite frequently lately: you hear people saying how good web services are and how they will dominate the future of software development, but what exactly are web services and how can we create them? In this we will explore the features of Microsoft ASP.NET Web Services, more specifically how to build web services. A real world example extending what I discuss in this article will be shown at the end of this . To understand this webservices fully, you are required to have some previous knowledge of C#, ASP.NET . To try the examples shown in this article for yourself, you will need the .NET Framework and Internet Information Server 5 or higher installed on your Windows NT/XP/2000/vista PC.

What is a web service?
The term "web service" refers to a form of a component that can be used remotely. Microsoft offers two types of web services in their .NET framework: XML web services and .NET remoting. When developers refer to web services they usually mean XML web services, and in this article I will also refer to XML web services as just web services. Web services are invoked remotely using SOAP or HTTP-GET and HTTP-POST protocols. Web services are based on XML and return an "answer" to the client in XML format. Web services have all the advantages of components plus many more. The most significant benefits include:

Language and platform independence: Web services can be built and consumed on any operating system just as long as that operating system supports the SOAP protocol and XML.

Automatic upgrade: Unlike components, if a web service requires an update, that update is propagated to all applications consuming that web service immediately. This is because the actual methods and properties for the web service are invoked from the web server remotely, meaning that each function contained within a web service appears as a "black box" to a client: they aren't concerned with the way the function does its job, just as long as it returns the expected result.

How Does it Work?

The basic Web services platform is XML + HTTP.
The HTTP protocol is the most used Internet protocol.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
Web services platform elements
• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

Commonly Used Jargon
Here's a list of some terms that you'll come across as you begin of the web services

UDDI (Universal Description, Discovery and Integration)
This isn't the case at the moment, but I'm pretty sure that in the future there will be thousands of web services on the Internet. The question is how are we going to find the web services we are looking for? UDDI is the answer to that question. UDDI is a registry that provides a place for a company to register its business and the services that it offers. People or businesses that need a service can use this registry to find a business that provides the service.

When you search for a web service using UDDI's web service or web browser, UDDI returns a listing of web services that matched your criteria. This list is returned in the form of a DISCO or WSDL document.

WSDL (Web Services Description Language)
WSDL is a language that describes a web service. It contains information such as where you can find the web service, methods and properties that it supports, its data types, and the protocol used to communicate with the web service. WSDL is based on the XML format and it's used to create proxy objects. Basically, without a WSDL document, developers wouldn't be able to use web services simply because they wouldn't know which methods and properties they support and also which communication method any particular web service supports.

DISCO is a list of WSDL documents. DISCO is used to group common web services together. DISCO documents are also in XML format.

SOAP (Simple Object Access Protocol) is a protocol to transport data to and from the web server. It is in XML format and allows you to transport a variety of data types used in .NET. As an alternative to SOAP, we can use HTTP-GET and HTTP-POST, which will be covered later in the article. These protocols return the output in a non-SOAP format, however this output is still in XML format. Well, this isn't the case at the moment, but I'm pretty sure that in the future there will be thousands of web services on the Internet. The question is how are we going to find the web services we are looking for? UDDI (Universal Description, Discovery and Integration) is the answer to that question. UDDI is a registry that provides a place for a company to register its business and the services that it offers. People or businesses that need a service can use this registry to find a business that provides the service. When you search for a web service using UDDI's web service or web browser, UDDI returns a listing of web services that matched your criteria. This list is returned in the form of a DISCO or WSDL document. WSDL WSDL (Web Services Description Language) is a language that describes a web service. It contains information such as where you can find the web service, methods and properties that it supports, its data types, and the protocol used to communicate with the web service. WSDL is based on the XML format and it's used to create proxy objects. Basically, without a WSDL document, developers wouldn't be able to use web services simply because they wouldn't know which methods and properties they support and also which communication method any particular web service supports. DISCO DISCO (Abbreviated from discovery) is a list of WSDL documents. DISCO is used to group common web services together. DISCO documents are also in XML format. SOAP SOAP (Simple Object Access Protocol) is a protocol to transport data to and from the web server. It is in XML format and allows you to transport a variety of data types used in .NET. As an alternative to SOAP, we can use HTTP-GET and HTTP-POST, which will be covered later in the article. These protocols return the output in a non-SOAP format, however this output is still in XML format.

We now show you how to create the Helloworld Web service. In the following steps, you will create an ASP.NET Web Service project that executes on your computer's local IIS Web server. To create the Helloworld Web service in Visual Studio 2005, perform the following :

Creating an ASP.NET Web Service in Visual Studio 2005

HelloWorldMethod. HelloWorldMethod returns a string, "Hello World". We'll add modifications to this web service as we learn more about the available features of web services.

Before building a web service, a virtual directory or web application must be created using IIS

The following code shows the most basic web service:

using System.Web.Services;
public class HelloWorld : WebService
{
[WebMethod]
public string HelloWorldMethod()
{
return "Hello World";
}
}

Copy the code above into your favourite text editor and save the file into the virtual directory we created above as HelloWorld.asmx. The file extension for a web service is .asmx.

You can now access our HelloWorld web service in your browser by visiting http://localhost/HelloWorld/HelloWorld.asmx.

You should see a page that looks like this:

This web page is automatically built by IIS using the WSDL of our web service. You can change how this page looks but that's out of the scope for this article. You can view the raw WSDL by clicking on the link to "Service Description", which will forward you to the WSDL for our web service.

As you can see, the WSDL shows where you can find the web service (URI) and other useful information including the methods that we have created in our web service. Now that we've built the web service, we need to be able to use it. On the main web service page, you can see the method that we've created. If you click on the method, it will forward you to this page:

When you click on the invoke button, you'll get the following result: