Very old article, do not know someone posted no: Some problems in the development of Web services

Web|web Services | Problems in the development of Web services


Date: October 10, 2001


There have never been such an exciting agreement before. But just talking about the three kinds of protocols such as SOAP, WSDL, and uddi--that define Web services doesn't make the idea of component software architecture and generic XML integration a reality. In order for Web services to begin to work, the protocols associated with them must be redefined and the corresponding development tools must be published, and a cultural revolution must be made by IT managers and developers.

In particular, Microsoft and IBM have been surprisingly productive in terms of the benefits of exchanging Web services-reusable software components, easy integration processes between businesses, and so on. Although the implementation of the actual Web services is still in the experimental phase, the media has made these high-level concepts popular. The developers who are opposed to the figures have different views. They have a lot of complaints about Web services.

Here are some common objections from developers to Web services. Some of them have been well addressed but there are some that are not:

Security and certification. Of all the objections to Web services, these two points first appear and appear most frequently. Fortunately, when you are dealing with sensitive data, SSL, the old web solution, is a good way to avoid the interception of XML messages. But authenticating the XML file on the server is another matter. There are no fewer than 10 certification schemes--they are presented by different standards committees--hoping to solve the problem with digital signatures and similar technologies, but it will be some time before these standards are stabilized.

Transaction completed. When multiple traders are trading at the same time-as it happens in a supply chain-the transaction process is lengthy and complex. You must find a way to monitor complex transactions so that each part of the process is identified. There are several different criteria, including secure Assertion markup Language (secure assertion Markup Language), business transaction agreements, and IBM's reliable HTTP to address this issue, but the standardization associations have not agreed to any of them.

Performance. There is no good answer to this question. HTTP based XML is not a high-performance solution at all. And if used in; the security protocols at the top of these protocols, it is not possible for a user to want a server to respond quickly to a particular action--such as credit card verification--high ductility problems that will allow Web services to be limited over time to engineering and automated business-to-business transactions within the enterprise.

Increased reliance on the sex. If multiple applications are based on the same Web service, changes to this Web service may cause errors in multiple applications. Similarly, the heavy use of individual Web services must be carefully monitored to ensure that the appropriate hardware is upgraded correctly. Like any component architecture, WEB service components must be developed for general-purpose users, meaning that programmers must estimate the functionality that many applications use.

Capacity and reliability. WEB connectivity is more reliable than ever, but when you call a component outside the firewall, you have to endure lower uplink speeds. You also have to trust the components that are accessed through the XML API, and consider them completely black boxes. You have to establish a stereotypical trust relationship between companies before you can accept the risk of using other people's Web services.

Additional development work. The individual wants to develop the application in the right way: a complete development document, always thinking about the maximum amount of reuse of the code. But in the real world, projects have to be done at a certain time and with a certain amount of funding. The first time you create an application from a Web Service component requires additional work and time. In any case, many IT managers do not want to drag the project down just to gain the benefit of code reuse that can be realized later. For the same reason, the likelihood that an IT manager will "component" a functioning application is very small, even if dividing them into Web service components can benefit other applications.

But no difficulty can really block its footsteps. In fact, the developers I've visited agree with the general direction of Web services development and many are still working on experimental programs.

With a more realistic estimate of the time and effort required for Web services-and a clearer understanding of the limitations of Web services-perhaps this promising technology will not suffer as much anticipation as many other technologies do.