1. Introduction
Today, every enterprise is looking for ways to improve its production efficiency, and they are also actively exploring the reorganization of IT assets. IT organizations have made some progress in overcoming these issues with the help of service-oriented architecture (SOA) technologies; however, in most cases only a small portion of the entire IT service portfolio is implemented. Currently, most efforts in this area are merely achieving a "just enough" state of SOA adoption—improving the ability to build applications and integrating them with the market faster, better, and cheaper. And as we've learned, achieving these goals is easier said than done.
2. Traditional middleware-based composite applications
The existing fact is that SOA is a kind of middleware - and 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 that incorporates SOA technology not only requires the use of a portal (middleware) but may also require the use of a BPEL engine (or even middleware) to orchestrate it, this of course makes You are very disappointed. Even worse, you might work within an organization that publishes UDDI registries and registers numerous web services. Unfortunately, in most cases, there are very few applications that actually consume these services. How could this be the case?
Should the inability to build applications that consume these SOA services lead us to conclude that something is wrong? Is it because it is too difficult for business content developers to build applications that directly consume SOA services? Are we having to rely on other IT organizations to create such applications for us? Is the lack of an SOA governance structure holding us back? I think the answer to all of the above is "yes." And there is a very prominent reason: it is too difficult for only business developers to consume and utilize such SOA services exposed by the IT organization! In fact, the real problem is the lack of an easy way to add on SOA An interface - and this is the advantage of combining AJAX technology with SOA.
Typically, an SOA service is implemented as a loosely coupled Web service that encapsulates and exposes business functionality. This may sound very straightforward, but it is very complex and difficult to implement. Developers often debate the development granularity of SOA services; however, most developers now agree that "business-level" development granularity is the most appropriate. However, this still requires a large number of relevant domain experts to come on board and work with business content to finalize the size of these services.
3. The renaissance of SOA
Fortunately, people have recently become deeply interested in SOA. Maybe businesses are finally realizing that SOA can actually help them tremendously. Perhaps this is due to better development tools and web services promoted by Amazon, Yahoo and eBay. Maybe it's AJAX? Yes—that's why I'm writing this article. Seriously, I do think that AJAX has become an important driving force in renewing people's understanding of SOA, especially in today's hybrid application fields of various new technologies. However, how should these two very different technologies be combined and connected together to unleash greater power? Let us first take a look at Wikipedia's definition of current AJAX technology. Web pages are involved, but SOA is not mentioned at all. The description is:
"AJAX, which stands for 'Asynchronous JavaScript+XML', is a web development technology for creating interactive web applications. Its purpose is to make the front-end web page easier by exchanging a small amount of data with the server in the background. It feels more responsive; therefore, every time a user makes a change, the entire Web page does not have to be reloaded. The ultimate goal is to further improve the interactivity, responsiveness, and usability of the Web page. "
SOA is not mentioned in this definition. Not surprising, since early AJAX applications focused on enhancing the functionality and usability of pages. This has been proven in numerous applications such as Google Maps, Flickr and Yahoo Mail. However, it's not these consumer-facing applications that get me excited about the potential of AJAX, it's the business applications running behind a company's firewall that really take advantage of what's good in AJAX, because it shows us two key characteristics : One is a client-side programming model and the other is an easy implementation of asynchronous calls to the server. These two key capabilities—the ability to apply logic on the client (browser) and the ability to access server data without interrupting the Web page—open the door to building new, richer Web 2.0 enterprise applications. So many possible application areas of the program.
Earlier, I mentioned that SOA lacks an interface. This is where AJAX comes in - it adds a decent look to SOA. Here, please allow me to explain a little more. We might as well think about what would happen if SOA services appeared online? Such services usually need to be registered in a registry or warehouse (if we are lucky) and then can be used for consumption. For example, let's take a look at what's available on the StrikeIron website ( www.StrikeIron.com ). StrikeIron has successfully created a "Web services marketplace" for the general public. At first glance, the directory mechanism in StrikeIron looks a lot like a list provided in a small business application. But later on, you'll realize that these aren't just applications—they're actually Web services. The concept of a single company providing WSDL/REST Web services to a wide range of consumers has many implications. But for now, let's take a look at what this company is selling. According to information provided by StrikeIron (which provides access to these services), the most popular web services it provides include:
· US address verification
· Global SMS service
· Sales and use tax
· Email verification
· Reverse phone lookup
Nothing No doubt, all of these Web services are quite useful and can be used in many different areas. But at the same time, they are too "commodity". In other words, I may not care who provides these services, but just want to get the information I want. On the other hand, would I simply use any web service to transfer cash from my current account to my savings account? I wouldn't. I first need to establish trust in this service, so I have to establish a certain relationship with the vendor that provides it. This "circle of trust" that exists between me (the consumer) and the service provider also represents the relationship within the enterprise and its partners.
4. Combining AJAX + SOA technology
The same method above can also be adopted by enterprises to provide their Web services to a wider user base. Through a Web services market, enterprises can register various Web services—and these Web services are usually only available within the enterprise or to partners. Market vendors obviously want this to happen, but more importantly, we see an opportunity to apply AJAX+SOA technology to drive a new class of Web 2.0 business applications.
For the first time, people began to feel that application development and SOA were finally coming together. We have business functionality described in a reusable form - an SOA service. We have ubiquitous connectivity—the Web. We have browsers that are proving to be the new application containers. We have a programming model in this type of application container/browser - JavaScript. And they all use open standards! What else do we ask for? In fact, there are other things.
I would particularly like to see a faster way to develop applications based on all of the above technologies - a way to build applications without having to rely on middleware integrated with SOA services. This is exactly what I want a web application to be capable of - "direct connection to SOA". This "direct connection to SOA" should be able to bypass traditional portal barriers and heavyweight process engines to directly (at least conceptually; we will learn more about this later) access SOA services. By this, I don't just mean web services, it could also be BPEL orchestration services, coarse-grained POJO services, RSS feeds or anything else that can be exposed as a "service". Of course, the interfaces should be exposed using open standards.
This new development and runtime model creates a new way to build application-driven composite applications. It has the appeal of a client/server type without the heavy baggage of traditional heavyweight client/servers. It runs on the browser side and can be implemented according to specific requirements.
5. User-Based Composite Applications
Over the past few years, we have all heard of the concept of "composite applications." However, most vendors have been talking about "composite services" - as a way to restructure their host services into other more useful services or portal applications. Let me make an analogy to explain further.
AcmeGrid, our fictional grid computing vendor in this article, provides a service—grid computing—that enables your applications to run as a service. The company's customers told it they wanted a way to combine many services into a coarse-grained service. So, naturally, AcmeGrid released an Eclipse-based AcmeGrid Composite Application Builder (CAB). Interestingly, CAB looks a lot like a BPEL designer, but is more tightly integrated with the services published by AcmeGrid. Although very beautiful, however, it is not a real application, at best it is just a service. In essence, CAB is more like a service builder. But who needs a service builder when we're trying to build applications? Soon, another fictitious vendor, let's call it AcmePortal, announced its Portal Composite Application Builder (PCAB) . It also ships with an Eclipse-based designer; although it also looks and feels like a BPEL designer, this program "knows" how to build portals. In many cases, a portal works just as well as an application. However, if you insist on converting a portal into an application, it will be in vain.
In fact, I really want to implement a user-based composite application rather than a middleware-based composite application. To do this, I needed a development and runtime platform that could not only use AJAX and SOA, but also manage both. Some vendors have taken the concept of AJAX applications one step further - calling WSDL-based Web services directly from the browser, which is essentially a SOAP call. This approach even has a name - "Client/SOA". This may be fine for simple non-enterprise or consumer applications, but not for true enterprise programs. Why? Because when you call a Web service directly from the browser, the supervision function is equivalent to being handed over to the browser - which simply means that there is no supervision problem at all. Figure 1 shows the block diagram of unsupervised Web service consumption. I've never met a company that didn't police its services, and I don't believe companies would allow this to happen just because we're technically very efficient at it. If you don't believe me, just remember that enterprises never open their firewalls to applications other than HTTP and SSL. No matter how much we persuade the system administrators, they will not open other ports.
6. We need a new type of platform.
As can be seen from the above, what we are discussing is not just about AJAX and SOA technologies. In fact, what we really need is a platform that can provide the necessary supervision capabilities for AJAX and SOA to coexist in the enterprise. This platform also provides the ability to consume SOA services from the client's perspective, and can also monitor service consumption. Figure 2 shows how Web services can be managed through a service gateway. A service gateway is actually a server-side abstraction that monitors and regulates service access on behalf of the client, which in the case we just discussed is a browser-based AJAX application. The beauty of using a service gateway is that you are not restricted to accessing only services running within the enterprise. This service gateway can oversee any service registered within the enterprise. In a WSDL-based Web service, the enterprise will register the WSDL, and the WSDL provides binding to the service at runtime. This might be a service running in an enterprise's data center, but it could just as easily be a service running in a partnership's data center. If an enterprise allows (through regulation) applications to access services, it doesn't matter where those services are running.
7. Conclusion
After reading this article, I hope you have begun to appreciate the power of bringing AJAX and SOA together—especially how the two can coexist and enable new types of Web-based applications with the regulatory capabilities required by the enterprise. Service application. 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 annotation technologies are all great, but what is truly influential is the response of Web 2.0 to enterprises.