AJAX joins hands with SOA to build a new generation of Web service applications

1. Introduction

Today, enterprises are trying to improve their production efficiency, and they are also exploring the restructuring of IT assets. With the help of Service-Oriented Architecture (SOA) technology, IT organizations have achieved certain results in overcoming these problems; however, in most cases, it is only a small part of the entire IT service portfolio. Currently, most of the effort in this area is simply to achieve a "just satisfied" SOA application situation-in terms of improving the ability to build applications and making it faster, better, and cheaper to integrate with the market. As we already know, it is easy to achieve these goals.

2. traditional middleware-based compound applications

The existing fact is that SOA is a kind of middleware-in traditional cases, middleware often relies on more middleware to translate data into a consumer-friendly state. When you finally figure out that building a composite application integrated with SOA requires not only a portal (middleware), but also a BPEL engine (or even middleware) of course, you are very disappointed with the orchestration. Worse, you may work in an Organization that publishes the UDDI registry and registers a large number of Web Services. Unfortunately, in most cases, there are still very few applications that actually consume these services. How can this happen?

If we cannot build applications that consume these SOA services, we should come to the conclusion that something went wrong? Is IT because IT is too difficult for business content developers to build such applications that directly consume SOA services, so that they have to create such applications for us by other IT organizations? Is it because of the lack of an SOA regulatory architecture that makes us hesitate? I think all my answers to the above questions are "yes ". There is also a very prominent reason: IT is too difficult to consume and use this SOA service exposed by IT organizations only by business developers! In fact, the real problem is the lack of an easy way to add an interface to SOA-which is the advantage of combining AJAX technology with SOA.

In typical cases, SOA services are implemented as a loosely coupled Web service that encapsulates and exposes business functions. This seems very straightforward, but it is very complicated and difficult to implement. Developers often discuss more about the development granularity of SOA services. However, most developers now agree that the "Business-level" Development granularity is the most appropriate. However, this still requires a large number of relevant field experts to join and cooperate with the business content to determine the size of these services.

3. Restoration of SOA

Fortunately, people have recently become deeply interested in SOA. Maybe enterprises eventually realize that SOA can indeed help them a lot. Maybe this is because of better development tools and Web services promoted by Amazon, Yahoo, and eBay. Maybe it's AJAX? Yes-that's why I wrote this article. Seriously, I do think AJAX is an important driving force to update people's new understanding of SOA, especially in today's hybrid application of various new technologies. But how should these two very different technologies be combined and connected together to bring out even greater power? Let's take a look at Wikipedia's definition of the current AJAX technology. It involves Web pages, but does not mention SOA at all. The description is as follows:

"AJAX represents 'asynchronous JavaScript + xml' and is a Web development technology used to create interactive Web applications. The purpose is to achieve a small amount of data exchange between the backend and the server to make the front-end Web page more responsive. Therefore, you do not have to reload the entire Web page whenever you make a change. The ultimate goal is to further improve the web page interaction, response speed and availability ."

It is not surprising that SOA is not mentioned in this definition, because early AJAX applications mainly focus on enhancing the functions and availability of pages. This has been proven in many applications, such as Google Maps, Flickr, and Yahoo Mail. However, it is not these consumer-oriented applications that make me excited about the potential of AJAX, but the business applications running behind the company's firewall actually take advantage of AJAX, it shows us two key features: one is the client programming model, and the other is the implementation of asynchronous calls to the server. These two key capabilities-the client (browser) application logic and the ability to access server data without interrupting web pages, it is precisely because they broaden the application field of so many possibilities for building new and richer Web 2.0 enterprise applications.

Previously, I mentioned that SOA lacks an interface. This is exactly why AJAX is "between"-it can add a specific appearance to SOA. Here, let me explain more. Let's take a look at the situation if the SOA service appears online? Such a service usually needs to be registered in a registry or repository (if we are lucky) and then can be used for consumption. For example, let's take a look at the content provided by the StrikeIron website (www.StrikeIron.com. StrikeIron has successfully created a "Web Service Market" for the general public ". At first glance, the directory mechanism in the StrikeIron website looks like a list provided by a small business application. But later, you will realize that this is not some applications-they are actually some Web Services. The concept that a company provides WSDL/REST Web services to a large number of consumers contains multiple meanings. But now let's take a look at what the company sells. According to the information provided by StrikeIron, they allow access to these services.) Most Popular Web services provided by StrikeIron include:

· U.S. address verification

· Global Short Message Service

· Sales and use tax

· Email Verification

· Reverse telephone query

Undoubtedly, all these Web services are quite useful and can be applied to many different fields. But at the same time, they are too "commercialized ". In other words, I may not care who provides these services, but just want the information I want. On the other hand, will I simply use any Web service to transfer cash from my regular account to my savings account? I won't do that. First, I need to establish trust in such a service. Therefore, I must establish a certain relationship with the supplier that provides the service. This "trust circle" between the consumer and the service provider also represents the relationship between the enterprise and its partners.

4. Combination of AJAX and SOA Technologies

The same method can also be used by enterprises to provide their Web services to a wider user base. Through a Web service market, enterprises can register various Web services-these Web services are generally only available for internal enterprises or partners. Market Vendors obviously want this to happen, but more importantly, we see an opportunity to use AJAX + SOA technology to drive a new type of Web 2.0 business applications.

For the first time, people began to feel that application development and SOA have finally come together. We have business functions described through reusable forms-SOA services. We have a ubiquitous connection-Web. We have a browser that is proving to be a new application container. We have a programming model in this type of application container/browser-JavaScript. And they all use open standards! What else do we need? In fact, there are other contents.

I especially want to see a faster way to develop applications based on all the above technologies-a way to build applications without having to rely on middleware integrated with SOA services. This is exactly the capability of my desired Web application-"directly connecting to SOA ". This "direct connection to SOA" should be able to pass through the traditional portal barrier and heavyweight process engines, and then directly, at least conceptually, so we will look at it later) to access the SOA service. Here, I am not only referring to Web Services, but may also be a service for the compilation of BPEL, a coarse-grained POJO service, RSS feedback, or anything else that can be exposed as a "service. Of course, the interfaces here should be exposed using open standards.

This new development and runtime model creates a new method for building application-driven composite applications. It is attractive to the client/server type, without the heavy burden of traditional heavyweight Client/Server. It runs on the browser side and can be implemented according to specific requirements.

5. User-based compound applications

In the past few years, we have heard of the concept of "composite applications. However, most vendors have been talking about "Composite services"-as a way to rebuild their hosting services into another useful service or portal application. Let me make an analogy for further explanation.

AcmeGrid, a fictitious grid computing vendor in this article, provides a service-grid computing-that enables your application to run as a service. Customers of the company told them they wanted to combine many services into a coarse-grained service. Therefore, AcmeGrid released an Eclipse-based AcmeGrid Compound Application Constructor (CAB ). Interestingly, the CAB looks like a BPEL designer, but it is more closely integrated with the Services released by AcmeGrid. Although pretty, it is not a real application, but a service at best. In essence, CAB is more like a service constructor. But who will need a service constructor when we try to build an application? Soon, Another fictitious vendor, which we now call AcmePortal, announced its Portal Composite Application Constructor (PCAB ). It also released an Eclipse-based designer. Although it looks like a BPEL designer, the program "knows" How to Build a portal. In many cases, a portal has the same effect as an application. However, if you want to convert a portal to an application, it is just in vain.

In fact, I really want to implement a user-based compound application instead of a middleware-based compound application. To this end, I need a development and runtime platform that can not only use AJAX and SOA, but also manage the two. Some dealers have further promoted the concept of AJAX applications-calling WSDL-based Web services directly from browsers is essentially a SOAP call. This method even has the name "client/SOA ". This may be good for simple non-enterprise or consumer applications, but not for real enterprise applications. Why? Because when you call a Web service directly from a browser, the supervision function is handed over to the browser-that is to say, there is no regulatory problem at all. Figure 1 shows the unsupervised Web service consumption diagram. I have never met an enterprise that does not supervise its own services, and I do not believe that this can happen only because we are technically very effective. If you don't trust my opinion, you just need to remember that enterprises never open their firewalls to applications other than HTTP and SSL. No matter how we advise the System Supervisor, they will not open other ports.

6. We need a new platform

As we can see above, we are not only discussing AJAX and SOA technologies. What we really need is a platform that provides the necessary regulatory capabilities for AJAX and SOA to coexist in enterprises. This platform also provides the ability to consume SOA services from the client perspective, and can monitor service consumption. Figure 2 shows how to use a service gateway to monitor Web services. A service gateway is actually a server abstraction. It can represent a client that supervises and regulates service access. This is a browser-based AJAX application that we have discussed just now. The beauty of using a service gateway is that you are not restricted to only accessing services running in the enterprise. This service gateway can monitor any service registered to an enterprise. In a wsdl-based Web Service, the enterprise registers the WSDL, And the WSDL provides binding to the service at runtime. This may be a service running in an enterprise's data center, but it may be as easy as a service running in a data center of a partner. If the enterprise allows access to services through regulated applications, it does not matter where these services run.

7. Conclusion

After reading this article, I hope you have begun to appreciate the power of combining AJAX and SOA-especially the coexistence between them and the implementation of new Web Services with enterprise-required regulatory capabilities. I firmly believe that we are on the eve of a new era of amazing opportunities. In the Web 2.0 era, social networks, image sharing, and various tagging technologies are all great, but what is truly influential is the response of Web 2.0 to enterprises.

(