Reports sent back from the Web services front

Web|web Service Web Services is a few of the highlights of this gloomy e-commerce field



。 Last week I visited web Services Edge 2001, a small exposition in Santa Clara, Calif., where most of the attendees were developers, while the main participants were the Java Development tools and application server vendors. The Web services Giants-Microsoft, IBM, and sun---were not there, presumably thinking it was a small event. In other words, it's a great place to show off your products and see how people really think about Web services, and not to get the ring of gold on the market.

This incident, like the early advent of the PC, employs an industry that talks about a new technology in almost an academic way, imagining what long-term impact it can really bring. Web services are considered to have little technical merit-they are simply a set of protocols that make it possible to integrate XML. Here are some of the major problems and observations emerging in some Web services:

simplistic. The IT industry should now start moving along with Web services rather than waiting for new security and business processes to emerge. Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) make up everything the IT industry needs to complete an XML integration project within a firewall-providing a major, short-term opportunity for Web services. If we also wait for the standard society to finalize protocols that simply repeat the current content, the implementation process will become very complex and ultimately fail like other complex component architectures (such as the Open Software Association's DCE or CORBA of the Object Management Association).

reduce the cost of integration within the enterprise. Today, many companies rely on expensive enterprise application integration (EAI) products that come with an adaptive interface that enables applications to communicate with each other for a particular business purpose. Web services will eventually eliminate EAI, providing a simple, message-based data exchange process between applications. In several pilot programs, several vendors claim that they significantly reduce the cost of integration projects and Time-to-market. Again, the simple thing is the best: just making Microsoft and Java objects talk to each other--a problem that EAI does not have at all--comes with a direct benefit.

solve the actual business-to-business problem. This is one of the most cited examples: it can be used to replace the electronic data interchange (EDI) process. For most business practices, a system that is full of complex, proprietary connections built by different businesses is too expensive, and these systems are often used to order bulk raw materials. Web services can make up for the shortcomings of previous business-to-business solutions: The process of cheap machine-machine transactions between enterprises. HTTP plus SSL may not be fast enough and unreliable for many business-to-business applications, so it is worth mentioning that the Kenamea and Slam Dunk Networks provide a secure HTTP solution.

don't get knocked out by the hype about business-to-business solutions. Some participants were uneasy about the universal Discovery Description and Integration Protocol (UDDI) as one of the three protocols that define Web services. With a UDDI directory, and the idea that thousands of Web services can be automatically integrated with other Web services over the Internet, there are many problems-the most obvious one is that capturing service volume information will never be realistic. If companies do not have the form of trusting each other in the business-to-business marketplace, they are afraid to wander between Web services that have not been identified. And if you want to build a reliable connection first, why bother building a UDDI directory? One of the best answers to this question is that UDDI can be used in private swaps where both sides of the transaction have already known each other, or for the internal use of an enterprise to make applications easier.

Finally, let's talk about companies that are considering starting Web services: The factional battles between Microsoft. NET and the Java EE Camp will continue to escalate as both sides want to convince the market that they have the only viable Web services platform, either directly or covertly. My advice is: Try not to work on your current architecture as you develop the configuration. If you already have some skilled C + + programmers and you already use Windows on the back end, you can buy a beta version of Visual Studio. Net and have these programmers develop a useful Web service application in C #. If your Java EE programmer has already started to bundle EJB with soap, it is best to upgrade to the latest version of the Java application server that supports Web services and let these programmers use it. Experiment with all your stuff. After all, one of the main benefits of Web services is the low cost development and integration process, which is a great idea this year.