You should consider several strategies to better understand how you will design your Web services. How will you organize your code into projects, classes, methods, properties, and events? After you have determined exactly what your requirements are and which scenarios your application will need to handle, you can begin to design your application. You must construct your Web services projects into one or more objects that handle the functionality.
Assuring peak performance
As with any software project, you must take into account certain design considerations. Performance is one of the biggest issues. And so many areas affect performance. Some of the performance considerations are based on hardware, but some performance considerations — such as memory — are also based on software.
With memory, more is always better. However, how much is enough? It's best to follow the recommendations based on the requirements of the software manufacturer for each piece of software loaded on the computer. Then decide on a magnitude greater than that.
The easiest method for assessing the amount of memory needed is to determine the maximum amount of memory required if every application was in use at the same time. You also need to consider how many users you expect at any time.
Following are some components to consider:
* Operating system (OS) requirements: That is, the amount of memory that the server needs to have in order to enable users to safely run the current OS and other installed software. For example, say you have two Web services that will be hosted on a Windows 2000 Server. Windows 2000 Server requires 128MB memory.
* .NET framework requirements: For example, say that the framework takes up 128MB of memory on the server. Together, the operating system and framework occupy a total of 256MB memory on your server, and that's without even considering the Web Services objects that you will be developing.
* Users: That is, the number of users who may be using a Web service at any given time. Suppose that you expect 100 users to need to use each of the two Web services objects at any time.
* Web service requirements: This is very difficult to estimate with any degree of accuracy, but at a minimum, add up all of the space that each of the data types will occupy.
* Overhead associated with the Web service: That is, the amount of memory your server should have over and above your initial estimates. If you estimate overhead of another 50K or so for each Web service, the memory starts to add up and compound.
Dealing with security issues
Security is one of the biggest topics in computing today. The fact that Web services are typically transmitted by using HTTP, the concern over security is great. In fact, any time that you transmit data over the Internet, security becomes a concern. If any personal data — such as user names, passwords, addresses, credit card information, and so forth — needs to be transmitted over the Internet, it should be encrypted. If it isn't encrypted, anyone with hacking tools will be able to read the data being transmitted across the wire. The same is true on a corporate intranet or extranet. Therefore, encryption becomes a necessity.
Encryption is easily handled by Internet Information Services (IIS), which uses Secure Sockets Layer, or SSL. The only thing that you must do to use SSL is to install an SSL certificate that you obtain from a trusted third party. After the SSL certificate is installed, clients can access your Web sites or Web services by using the HTTPS protocol, instead of HTTP. (The S stands for secure.) This SSL certificate is known as a server certificate.
Just because you use SSL to encrypt your data doesn't mean that everyone should have access to your Web service. Access is controlled by an authentication scheme. You can control who has access by allowing Active Directory to authenticate.
You also need to know how your Web Services should handle security. To know this, consider these questions:
* Can anyone or any system access the Web services?
* If access must be restricted, how will you restrict it?
* Should you use Active Directory to authenticate users?
* Should you use Passport to authenticate users?
* Should you limit Web services based on looking up valid users in a database?
The answers to these questions dictate how complex your Web services become. Certainly, the easiest thing to do is to allow everyone access to your Web services, but this is not always practical. For example, what if you charge for your Web services usage through an Internet Service Provider (ISP)?
If you're going to use Active Directory, you need to decide how you want to administer adding users and computers. For example, you should consider automating this task, depending on whether you plan to be signing up new customers/users very often. If you are going to use database lookups, you need to account for this functionality in your project plans and to determine the details of how this can work.
On the other hand, if you have Microsoft Passport do the authentication, you guarantee that a user is authenticated, but you don't have to store the user's information at your location. Remember that you need to look at security issues from every possible angle.
Ensuring interoperability
Interoperability is the concept that disparate computer systems need to be able to talk to each other. For example, if an Oracle database needs to work with a SQL Server database, you have to figure out how to make that happen. Likewise, if you know that your ERP (Enterprise Resource Planning) system has to talk with a CRM (Customer Relationship Management) system, you'd better get cracking.
Many of the interoperability issues that arise from disparate systems talking to each other can be addressed with a Microsoft product called BizTalk. BizTalk allows the mapping of disparate systems by allowing multiple protocols and formats. Internally, BizTalk uses XML to store mappings among these disparate systems.
Interoperability also has an impact on how different technologies have to work with each other. For example, does a .NET component need to invoke COM components? The two technologies are somewhat similar in concept, but not in technology. However, it is very possible to wrap COM components with .NET interfaces. This is called COM-Interop.
Deciding what your users can access
You must determine how much of your object model you wish to make available over the Internet, which is a concept known as exposing. It's important that you remember the concepts of a component, or object, that makes up your object model. You want to expose only an abstracted view of what is necessary to get work done and solve your use cases.
For example, if you have a financial application that decides whether a mortgage should be granted based on specific criteria; you don't expose all the internal implementation details. That's your "secret sauce." The less you share, the better. Expose only the bare minimum number of objects, along with the bare minimum number of members (properties, methods, and events) needed in order to get work done.
