Second generation Web Services Outlook [turn]

Web|web Service
In the early days of Internet development, companies used SMTP, NTTP and FTP clients and servers to connect to the Internet, transmit messages, text files, executables, and source code, and the Internet became a basic tool when enterprises began to integrate enterprise information into the Internet architecture. The popularity of the internet is greatly enhanced when the Internet's focus is shifted from an exchange of information protocols to data objects and links between them.
Early web architectures are characterized by html-gif/jpeg, HTTP, and URIs, which are incredibly powerful when combined, and use these technologies to integrate a wide variety of online publishing systems into a system that is more appealing than any single technology.

Once organizations use public data formats, HTTP protocols, and a single address system, the Web is no longer a collection of many web sites, but it is the most diverse and powerful information system, with organizations building links between their information and the information of other institutional groups.

The first generation of Web services is very similar to the first generation of connections, and the various Web services are not integrated with each other, and their design goals are not to make it easy for third parties to integrate them in a unified manner. I think the next generation of Web services will be a more integrated Web service originating from online publishing and human-computer interaction, it will be based on the architecture that makes the web more useful, the Trinity: Standard Format (XML), Standard application protocol, and a single URI namespace.

The next generation of Web services will be tied to rest, the current web architecture pattern, which means "representing state transitions." It explains why the Web can have URIs, HTTP, HTML, JavaScript, and many other features, it contains multiple aspects, and I'm not sure I've mastered it, and in this article we'll focus on the most interesting parts of XML users and developers:

The current Web service

Soap was originally presented as a trans-internet form of DCOM or CORBA, and the name of the early soap-like technology was "Web Proxy" ━━, a Web-based object broker, which accurately expressed the implications of this technique for establishing cross application protocols in the standards of DCOM, CORBA, and RMI. It is also an existing model for resolving interoperability issues between applications.

These technologies have only limited success when they are not applied to the web. Some analysts say the problem is caused by the collaboration between Microsoft and the OMG supporters, but I don't think so, which has a deeper problem. For closed-world problems, RPC is really good. In a closed world, you know that all users can share data models with them and communicate with them according to their needs. It's fairly easy to develop in such an environment: you just tell all the users that the RPC API is going to change over time and that there may be a transition period between them to avoid problems. With point-to-point integration, new systems can be integrated.

On the other hand, when the user base is very large, point-to-point communication is impossible, and we need a different strategy. We need a pre-arranged framework to change at the same time on both the server side and the client, and there is a clear mechanism for interoperability with systems that do not have the same APIs. RPC protocol is deficient in this aspect, change the interface of which is extremely difficult, integration new service often need to carry on complex software glue.

I think this is the real reason that no enterprise has succeeded in unifying their systems on DCOM, CORBA or RMI. Now we have reached the crux of the problem: SOAP RPC is the Internet DCOM.

There are many problems that can be solved in RPC. But I think one of the biggest and hardest to solve is the need for a model that enables clients, servers, and the middleware side to upgrade independently.

Prototypes can be upgraded applications

The two most scalable, interoperable, distributed applications today are web and e-mail, what makes these two applications so scalable and interoperable, and so on? They rely on standardized, extensible message Formats (HTML and MIME), application protocols (HTTP and SMTP), but I think the most important thing is that each application has a standardized, scalable global address system.

In the real estate industry there is a joke, the formation of real estate value of three elements is the location, location and location, in the XML Web service is also the case. If implemented properly, XML Web services enable us to assign addresses to data objects so that they can be shared or modified.

In particular, the central concept of the Web is a single, unified namespace for URIs, which allow the web to have a large number of web links that take advantage of value, tying the web to a single, large-scale application.

URIs are equivalent to resources. Resources are conceptual objects whose expressions are published on the web in the form of HTTP messages. These ideas are quite simple, but they are very powerful, and they have been successful. The connection between URIs is so loose that we can even use a piece of paper or OCR to pass a URI from one system to another. URIs are late-bound, and they do not define what can be done about the information being referred to. It is the "loose" and "late" features that make it possible for networks of this size to be available to the Web.

Unfortunately, most of us don't consider web services that way, and we think of Web services as a remote procedure call between the endpoints of software components, the idea of CORBA and DCOM, the idea of the web being based on the resource organization URI.

The next generation of Web services will use separate data objects as endpoints, and the boundaries between software components will be very small.

Example of a demonstration

UDDI is an example of a more powerful Web service that can be used as a resource-centric feature, here we do not discuss the philosophical role of UDDI in Web services, only the specific issues of how to get information from it or enter it, which applies to most Web services that already exist, For example, stock quotes, airline reservations and so on.

There is a businessentity concept in UDDI that represents an enterprise that is determined by UUID, in the web-centric model, where the enterprise is determined by the URI, and the simplest way is to use businessentity as an XML document that can be set to address, for example, Http://www.uddi.org/businessEntity/ibm.com or http://www.uddi.org/getbusinessEntity?ibm.com. The differences between these two approaches are fairly small and are not related to technology, so we don't have to worry about that.

We can think of http://www.uddi.org/businessEntity as a directory containing files, or a Web service that reads data from a database. One of the most fascinating features of the web is that it is simply through a URI and cannot tell what it really is, which is also the role of "loose combination".

Let's consider using an HTTP based URI rather than using a UUID to represent the meaning of an enterprise entity:

• People who want to check the enterprise entity can only point the browser to the URI and view the businessentity record, and the HTML version of the enterprise entity applies only to the previous browsers, while the XML version of the enterprise entity applies to newer browsers.

• To refer to a businessentity in another Web service or document, you can only use its URI.

• To integrate the referenced information into other XML documents, you can use XLink, XPointer, or xinclude.

• To save a permanent copy of a record you need to use command-line tools such as wget or select the "Save as" menu item in the browser.

· XSLT style sheets can dynamically acquire resources and combine them with other resources in transformations.

• Access to BusinessEntity can be controlled using standard HTTP authorization and access control mechanisms.

• Meta data can be associated with businessentity by using RDF.

• Any client application (whether browser-based or not) can fetch data without a special SOAP library.

• Two business nannies you can use redirects from one enterprise entity to another to represent a merge of the two.

• Editing and analysis tools like Excel, XMetaL, Word, and Emacs can use HTTP to import XML documents directly from URIs and use WebDAV for writeback.

· UUID or other forms of location-independent addresses can still be specified as additional layers of abstraction.

The current UDDI API has a method called Get_businessdetail, which is completely redundant in address-centric mode and can be removed from the API. UDDI has several get_ methods for manipulating data objects such as tmodels, business services, which can be represented as logical XML documents and can be deleted. It is important to note that we have greatly simplified user access to UDDI information while improving the importance of XML and XML schemas in UDDI systems.

The enterprise entity is not the only thing in UDDI that should be determined based on the XML resource addressed by the URI rather than the SOAP API, in fact, all data in a UDDI database can be determined in this way.

Summary: Resources (data Objects) as children, if they want to integrate into the community of the family, each of them need to have a name.

Scalability

If you organize Web services around URIs, the service can be automatically integrated with other Web services through links, and a UDDI entry in one registry can easily point to UDDI entries in another registry system. In fact, companies can maintain enterprise information on their own sites, and "register" these changes to UDDI when information changes. Resource-centric Web services are inherently easy to integrate.

Elements in a UDDI registry can only be consulted among themselves (with very few exceptions), and they do not have access to objects elsewhere on the web, such as elements in other UDDI registries. A URI-centric solution organizes the data domain in the same way that the phone number system organizes the telephone.

Because businessentity documents are XML documents, it is relatively easy to add elements, attributes, or other namespaces. XML is an extensible form of data expression that can be easily extended by adding a specific HTTP header or even a new HTTP method (in rare cases).

Performance

The performance of Web services is a very important issue, and any resource obtained from a get URI is involved in a performance problem with the buffer server, enterprise firewall, or client computer before the server. Buffering is built into HTTP, SOAP Get_businessdetail information cannot be buffered by existing technologies, and other aspects of the rest architecture can be enhanced.

Other methods

There are other businessentities-related methods in UDDI, one of which is delete_business. HTTP already has a Delete method, so delete_business is already redundant in rest mode, and we can use the deletion method in HTTP without using the UDDI Soap-rpc method, which is beneficial to the "know" Tools such as Resource Manager in Windows 2000 that remove methods in HTTP are compatible. Theoretically, a company can delete a part of a record by clicking the "Delete" button.

It is clear that authorization and access control are key. Microsoft cannot erase its rivals ' progress in this regard. There is already a feature of authorization, authentication, and encryption in the Htttp, which is not supported by the UDDI SOAP RPC protocol.

There is also a save_business method in UDDI to upload a new business, which corresponds to a put or post in HTTP. One advantage of using the HTTP method without using the SOAP method is that you can perform the Post method in an HTML table.

UDDI also includes a method with a name of find_business, which differs in principle from the search function or specific search engine on each Web site. In URI mode, the service is able to obtain a series of search parameters, returning the businessentities that represents the matching search parameters.

Using the four basic methods of get, put, DELETE, post, we can do what we do with dozens of UDDI methods. The relationship between rest and Web services is like the relationship between RISC technology and CPU, but the relationship between the two is quite different, the cost and the benefits are not the same.

Role of HTTP

The benefits we get from Web services are also available with HTTP, and we need just the XML symbol set, which is what XML is all about: more about exchanging data than software components.

Everything in UDDI can be represented with HTTP for XML Resource operations, so HTTP and URIs become one of the most central technologies in the Web, and are designed to be a major part of a feature-centric rest architecture.

Here's a very radical view: Whatever the problem, we can and should consider it as a data resource processing problem rather than an API design problem, consider the Web server as a huge information warehouse, where we work on data processing.

In discussing UDDI, I chose a Web service that could be easily converted to a rest architecture, but we could apply that principle to all Web services. So what about the order submission? This is more like a transaction, and an order needs to be named. If we use post or put to submit an order to a new URI, then the entire company's internal system can review the order, regardless of where the system is. Using HTTP, XSLT style sheets and Perl scripting code on desktops used by employees in Beijing branch can handle orders on the financial system running on a large host in Los Angeles. Accessing the HTTP Address resource is no more difficult than accessing the files on the local system.

Even a Web service with a complex workflow can be organized in a URI-centric manner. Now let's look at a ticket booking system. In the traditional HTML system, there are different kinds of web pages that represent logical transactions. First, we need to defend the right flight and get a URI that represents many suitable flights. Then choose a flight from it and get a URI that represents our choice. Then decide whether to submit the order, and then get the page that returns the reservation number. In general, the URI of the page is kept for a reasonable period of time so that we can write down the number of the reservation. We can consider all the business in this way.

HTTP can even be applied in Peer-to-peer, asynchronous, and reliable distributed computing, and if readers are interested in these issues, they can further refer to other information.

xml-based Web services can be done in the same step. No HTML tables are returned in each step, and the Web service returns XML documents that conform to the aviation industry standards, which can be used in completely different ticket booking systems to run the same process.

Summary: Any business problem can be viewed as a resource handling issue, and HTTP is a data resource processing protocol.

Safety

A globally consistent address to the data does not mean that everyone has access to your data. We can easily hide objects by not publishing their URIs, and we can easily use security policy on objects. In fact, rest simplifies security to a large extent.

In SOAP RPC mode, the objects we use are not obvious and their names are hidden in the parameters of the method, so we need to use a new security policy for each Web service. In rest mode, we can use 4 basic permissions for each data object: Get permission, put permission, delete permission, and post permission. We can make a subset of the resources have or do not have get, put, delete, and post four permissions, which is somewhat similar to the permissions of the currently widely used file system, which is effective and mature.

Resource-centric Web services can work well with firewalls. A firewall administrator can easily make a Web service read only by blocking HTTP requests that do not use the Get method.

Maintenance

In fact, security is only one form of maintainability. All network administrators will say that any size of the networks will have problems, sometimes IP is not a problem, but DNS will be problematic (DNS server shutdown or incorrect DNS configuration), sometimes the IP and DNS is normal but HTTP out of the problem (firewall or proxy server configuration is not correct). If you run Web services on top of HTTP, the likelihood of a system problem is the sum of the two, and there may be multiple parts of the problem and security vulnerabilities.

Once the Web service is working properly, you can test it by using a service in the browser, or even a complex Web service that requires multiple steps to complete, through an HTML table. In essence, the test of rest Web Services is similar to that of a Web site. On the other hand, each SOAP RPC service has its own security mode, address model, data model, State transition table, and method set, and it is much more difficult to test such a system.