When can Web services be more meaningful?

Services|web Current Web Services is a fairly new technology, and not everyone knows how to make the most of them. In my experience (I have built a complete enterprise software PRODUCT on the Web services underlying architecture), I find that Web services has two main uses: consolidating multiple systems together and providing functional functions as components to remote calls. In this article I'll look at the issues that need to be noted when using the latter method.

You need to consider a number of factors when you want to use a Web service to submit a new function or service to a client that may be invoked remotely. Whether this function is for internal or external customers or collaborators, in Visual Studio. NET to start a new Web service project, you can save a lot of time by designing an outline first. For example, it makes sense to provide a functional function as a Web service when it comes to requiring access to a proprietary database and/or when it is difficult to implement a local deployment or the cost is too high. The functions used to perform simple computations do not require access to proprietary data, and are less complex in terms of local deployment or maintenance.

When a functional function requires a complex installation process or a complex, expensive hardware configuration, using Web services may be your best choice. In this case, providing a functional function as a Web service will solve a lot of problems for your customers because they don't have to deploy it locally. If you often need to publish a new version of a functional function, you should also consider using Web services. A Web service provides an easy way to publish an upgraded version to all customers who use the function, without having to redeploy them every time a new version is released. It is not easy for the public to provide functional functions that require access to proprietary data through the Web service interface. In any case, the client needs to be able to get the data, and the Web service is clearly a better way than to transfer the normal files (flat file) data. Finally, it is best to provide functional functions that depend on changing data frequently as Web services. Increasing the speed of data and changing the size of data can make remote access to proprietary data more obvious.

Deployment issues are one of the most important factors when you decide whether to provide a functional function as a Web service. WEB Services makes it easier to deploy software. For example, if you're building an application that directs driving, you don't have to worry about how to install the map software. Or if you have a functional function that needs to be upgraded frequently, you don't have to go back to the company every few months to get them to deploy updates for you.

Select Web Services wisely
However, you have to understand that not all aspects of Web services are good, they also have pros and cons. Of course, before you start your project, you have to make sure that there are more advantages than disadvantages. Otherwise, the only place you need to use a new Web service is on your resume.

For example, a Web service running in another architecture is certainly not as reliable as running on your own server. Even the most perfect and best protected networks are not completely secure in some ways. You must be able to prove to your customers that there is a great advantage in the deployment and maintenance of services, both internally and externally, to compensate for the deficiencies inherent in the remote Access function function in an error-prone network.

I prefer to use the square root function function to illustrate a typical "error" example of using a Web service (see table 1). Although the scene is a bit exaggerated, it is very descriptive. The square root functional function does not embody the advantages offered by any Web service, but instead embodies all its flaws. It is not difficult to deploy it, and it does not (at least not recently) need to be redeployed because of the changes that make the Web services deployment advantage not manifest. Furthermore, it does not require access to any database or proprietary data to implement the computing function. However, it does need to send functional function requests to the Web server, which causes the Web service to perform slowly because of its inherently slow or no network link problems. In this case, a small function like the square root causes the function of a large application to stop completely. When you first try Web services, it tries to publish some application functions (utility function) as Web services-some functions that convert bitmaps (bitmap) to JPEG or compress bitmap data. These functional functions may be very handy, but they are not available for Web services.

Internal Department-to-department (D2D) Web Services may apply to all functional functions, or even to some functional functions that are difficult to deploy, when data may be useful to other departments. Web Services provides a great way to quickly and efficiently implement software deployment and maintenance within the enterprise without having to access Web services outside the firewall. Because D2D Web services are running inside your network, this reduces the likelihood that a program will break due to network problems, and that the level of volume is easier to predict.

Typically, when a department builds a program that needs access to data from other departments, the department that holds the data will set up a data export program (procedure) to transfer a normal file containing the data to the desired department so they can import the data into the database. Unfortunately, this very inconvenient method of sharing data is very common. WEB Services provides a better way to load plain file data for internal departmental data sharing. Instead of sending raw data to the client to do data processing on its own, Web services gives you more control, which provides the computing function rather than the data to be computed. This is not only a more stable method of information sharing, but it also provides a mechanism to enhance business rules related to data.

Although the same approach is used, it is important to evaluate the functional functions that need to be provided to the outside through Web services. The risk of using a Web service provided by an external enterprise is greater. However, this risk is offset by the advantage that they can take advantage of distributing programs across firewalls without having to deploy service locally (see table 2).

Consider the following questions
When you recommend to your company that a functional function be available as a Web service to your business partner or user, you need to demonstrate whether the advantages outweigh the disadvantages. The answers to the following questions will help you:

What is the urgency of the function for the program you are using?

How sensitive is the data for the incoming or outgoing Web service?

What is the data source? How often does it update? Is it public?

How often do you participate in the release of the new version of this feature?

Who is controlling the architecture of the Web service? Is the architecture reliable?



WEB Services has the potential to exploit most IT companies, especially in software deployments, but you can't use it anywhere. You want to avoid the meaningless use of functional functions or services as Web services. Sometimes it is necessary to deploy locally.