- SOAP Toolkits
- WSDL Overview
- Using Web Services to Create Applications
- Case Study
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Using Web Services to Create Applications
So, maybe you think Web Services sound really interesting. They have great support on most platforms and the industry as a whole supports them. But, are Web Services a solution in search of a problem? To answer that question, we will cover some of the things that SOAP lets you do.
Access Applications Over the Internet
One thing that we hear a lot about is the "software as a service" concept. What does this really mean? One thing software-as-a-service enables is the ability to make sure that users always have the latest code running on their machines. Software as a service also takes component based programming to a higher level. Instead of simple widgets that require applications to redistribute code, we can start building applications that rely on complex and costly infrastructure supplied by someone else. MSDN recently implemented a project called Server Side Favorites (co-author Scott Seely is on that team) that allows ISPs to give their users the ability to make their favorites available on any device, anywhere.
Figure 1 Accessing Applications over the Internet.
){kind=link}
In Scott's book, SOAP: Cross-Platform Web Service Development Using XML, he covers an auction service where the client could create a Web-based auction by picking and choosing from individual pieces that provide things such as item management, bidder registration, and auction rules. The client could present the user interface and let the auction Web Service infrastructure handle the rest. This extends to many other areas as well. For example, you could:
Expose HR services over the Internet.
Integrate purchasing with bigger services.
Create unified data stores for medical records.
Cross-Platform Development
Some of the low-hanging fruit in Web Service deployment involves making it easy for disparate operating systems and programming languages to use each other's services. Before Web Services, people were looking at implementing COM-to-CORBA bridge technology or utilizing various application servers that tied the enterprise to one solution. Because SOAP interoperability is on every implementer's feature lists, you actually have the freedom to let people pick the best SOAP library for the job. If you need Perl, grab SOAP::Lite. Perhaps your developers are most comfortable with COM—use the Microsoft SOAP Toolkit. If a group has made a big investment in Java, Apache SOAP works well. All these benefits apply when you need to collaborate with business partners as well.
Figure 2 Using SOAP for cross-platform development.
){kind=link}
The underlying message here is that your corporate initiatives regarding everyone using the same toolset just to leverage everyone else's work becomes less important. Instead, you can look to toolsets that implement standard interoperability mechanisms. SOAP is a great way to get applications to talk to each other without investing in expensive architecture pieces like CORBA and Enterprise Java Bean servers.
Establishing a "Demilitarized" Zone (DMZ)
Maybe you want to share data over the Internet but want to protect the data store from prying eyes. Web Services allow you to place the computer serving up the information in a DMZ and hide the data store behind a firewall. Because you can configure the firewall to only allow the machines in the DMZ access to the data store, you make it easier to provide value without compromising private information.
Figure 3 Using SOAP with a DMZ.
){kind=link}
These are just a few of the things that Web Services can do for you and are among the most common reasons for making the jump from proprietary technologies to things like SOAP. People have made the leap for other reasons. Few have regretted the decision.