SOA: Are we re-inventing the wheel?

ArticleDirectory

• Introduction
• Obstacles to reuse
• Reuse-oriented
• What is SOA?
• SOA and Distributed Technology
• Is web services a savior?
• Service Infrastructure: emerging solutions
• Have we achieved our goal?

Copy this article from: http://dev2dev.bea.com.cn/techdoc/20060703838.htmlintroduction

If you have been in the IT industry for a while, you may feel familiar when you hear that suppliers are introducing new technologies. If you are dizzy with a large amount of publicity on the service-oriented architecture, you are not the only one. At a recent conference, a participant accustomed to using COBOL coding asked where is the difference between SOA and the COBOL copybook he uses. I have never used a COBOL copybook, but I have seen a lot of technology disappear, so I can understand this problem. In this article, I will explain the main driving force behind SOA and how to improve technology to support SOA. I will discuss it at the conceptual level and give some references at the end for those who want to study it in depth.

Obstacles to reuse

Reuse has always been one of the primary goals of software development. This is obvious: if you writeCodeTo implement a function. If you do not need to rewrite or maintain it in many other places, it will undoubtedly increase productivity. However, reuse implementation is not easy or automated. First, code must be organized or written in a reusable manner. Then, you must know that there is a piece of code that can be reused. In terms of code organizationProgramming LanguageProvides built-in support for reuse in different ways. Most processes and functionsProgramThe basic unit that the staff is familiar. Object-oriented languages, such as C ++ and Java, also provide methods to define and extend custom types or classes. The basic concept behind these features is encapsulation (that is, you only need to use some well-defined interfaces to access the functions, which is a black box for you ). These features have their own purposes and advantages, but they also have some limitations when it comes to supporting larger scale.

• First, these programming language artifacts are very low-level and can be effectively reused only by programmers who are particularly familiar with them.
• Second, even in the same project team, it is not easy to find reusable assets, let alone within the enterprise.
• Finally, code at this level does not support the network, which means that the Code cannot be called across machines or transparently reused in another programming language. For example, if I have already written a pricing module using C ++, I cannot call this module in Java.

Here I want to express that these features must have their own advantages, but the reuse at this level is actually cutting and pasting code, which is prone to errors and cannot be expanded.

Reuse-oriented

The concept of "service" is introduced to solve some of these reuse problems. CORBA is a standard proposed by the Object Management Group (OMG). This may be the first comprehensive effort to solve the reuse problem using a standard distributed computing model.

The idea is to formally implement the concept of encapsulation through an abstract interface and provide a set of basic services that can be used by these services (or objects in the CORBA technology. Interfaces are defined in languages called IDL (Interface Definition Language), and ing is defined for various programming languages. The service can be described in this language. To use a specific service, you only need to use IDL, without understanding the actual details of implementing the service. These services also support networks. This provides a convenient way across hardware, languages, and networks.

CORBA also defines a rich set of basic services, such as the Directory Service (naming) used to register and discover objects, and the transaction (trader) that discovers Objects Based on Public attributes) service, notification service for asynchronous communication, transaction service, and so on. Therefore, you can quickly build services because these basic services can be used. You can also easily reuse these services across multiple boundaries. Other distributed component models, such as Microsoft's DCOM and J2EE, all build and use services in a more or less similar way.

What is SOA?

Now, we have prepared to define a Service-Oriented Architecture (SOA. Unfortunately, there are multiple definitions about SOA, and sometimes they conflict with each other. Many definitions combine a specific technology (especially Web Services), or include a specific feature (such as the call type) in the definition ). I will give some existing definitions that I think hold on to the nature of SOA rather than associating it with specific technologies. However, let's take a look at the term "service" in the service-oriented architecture ".

Define services in SOA

A service is an over-used term, but it is not well defined. A service is a function that can be called in a distributed manner. It is well-defined, self-contained, and does not depend on the context or the status of other services. Let's take a look at some of the features that constitute the service definition:

• Can be called in a distributed manner. This is important because we cannot assume that a function is in the client environment.
• Well defined. As discussed earlier, one of the major challenges to reuse at the programming language level is the difficulty of discovering reusable assets and using them across a variety of technologies. A service should be able to describe and register itself in a well-known directory, and the client that wants to call the service should be able to call the service completely based on the registered information.
• Self-contained. The meaning of an operation should be determined by the Information and Service Status of the forthcoming operation, rather than the status or context of another service. This isolation makes it easier to understand the functions provided by the Service and reuse them.

Define SOA

Now let's take a look at some different definitions of SOA. W3C defines SOA as "a set of callable components whose interface descriptions can be made public and discovered ". I personally do not like the word component used in this definition, because the component is an over-used term that may remind people of specific content, such as ActiveX and EJB. However, this definition is reasonable if we use a service instead of a component.

Zapthink is an industry analysis company that defines SOA as "an architecture criterion. Its central content is to describe and publish it assets as services. These services can then be loosely coupled as part of advanced business processes to provide business flexibility in the face of it heterogeneity ". I prefer this definition because it uses the IT asset term to define SOA, which is more extensive in scope. In addition, it also points out an important feature of SOA-loose coupling (which will be described in detail later) and mentions the advantages of SOA.

The last definition is the SOA Technical Center of the dev2dev site of Bea. In this definition, SOA is defined as "a design method whose goal is to Reuse Application-neutral services, this improves it adaptability and efficiency ". This is an excellent definition of SOA at the business layer. It emphasizes the fact that SOA is not only a technical component (like interfaces and protocols), but also a design method with a clear goal of maximizing reuse. I want to add some content for this definition: it is not only a design method (this is only a front-end part ), it also involves the entire service lifecycle-service design, deployment, maintenance, and final stop-use.

We hope that these three definitions will help you understand what SOA is and its goals. Before entering the next section, I would like to talk about an important feature of SOA-loose coupling. Coupling refers to the degree to which components are mutually dependent. Services can be designed together, that is, tightly coupled, or services can be dynamically discovered and used. Loose coupling is what we want to achieve, because it can reduce the mutual dependencies between services or components and allow you to easily replace or update services.

SOA and Distributed Technology

As you can see from the discussion on both CORBA and J2EE, both technologies provide methods for building SOA. These technologies have been successfully deployed several times across different industries. However, if enterprise-level evaluation and reuse are to be performed, the reuse of these technologies does not reach the expected level even in enterprises that have already deployed these technologies. In some enterprises, from a business perspective, a large number of "services" are actually executing the same task, such as verifying credit cards and finding employees. This situation is not uncommon.

Why does this repetition exist? There are two main reasons:

• heterogeneous or multi-middleware problems: A typical enterprise typically uses a variety of applications, tools, and technologies. The same situation applies to middleware: the Java field may use J2EE, while the Microsoft field uses DCOM, and so on. From the perspective of service construction, this means that interfaces can be described in multiple ways (IDL is used for CORBA, MDL is used for DCOM, and Java is used for J2EE ). In addition, since each technology defines its own transmission protocol, there are multiple ways to use these services. Although people have tried to build bridges to connect different programming models and transmission protocols between these technologies, the actual user experience is poor: ununderstandable ing (I will know the ing from Java to IDL). Vendors blame each other for the poor performance of such "bridges. In short, neither the definition nor the use of services are universal, thus affecting interoperability and making reuse difficult to implement.
• the complexity of these technologies: these technologies are quite complex and difficult to learn, you need to understand a new API and a new programming model before using these technologies. Using these technologies to build services requires writing a lot of code, especially for CORBA. In this regard, J2EE is better, because it supports more declarative methods to build services. However, even J2EE is not satisfactory, because programmers need to master dozens of APIs to achieve certain efficiency. The complexity is also reflected in the management of these services, such as deploying services, versioning services, and stopping services. These technologies have poor support in this regard, and only J2EE is better, while both CORBA and DCOM have their own advantages. However, effective management of these services is a headache (and costly) for every enterprise.

Therefore, although the distributed component technology provides clear support for SOA construction and is based on industry-recognized standards, the above two factors impede the implementation of reuse at the enterprise level. Note that the actual situation is even worse, because to use these standards-based technologies, enterprises need to make the system based on specialized middleware technologies, such as MQ and tibco. All these systems, whether based on standards or specialized technologies, should be considered as the IT assets of enterprises, because enterprises invest heavily in building these systems. Existing functions in these existing systems must be made public to reusable services, so that they can be used to easily build new systems. The introduction of another API or another transmission protocol cannot solve this problem. What we need to do is standardize the Message format and use the transmission protocols that have been widely used in enterprises, such as MQ and IIOP. In the next section, you will see how Web services meet this requirement.

Is web services a savior?

Web services is based on the same technologies as Internet and Web. It solves many problems of distributed component models. I assume that you have some basic knowledge about Web Services. For those who want to get started, refer to the references section at the end of this article. In this section, I will explain how Web Services solves the limitations of distributed component models such as croba and J2EE.

• Web Services uses HTTP as its transmission protocol. HTTP has been widely used and recognized, which not only helps enhance interoperability, but also improves operation efficiency by using the existing infrastructure. Note: Web services are actually independent of the transmission protocol. HTTP is only one of the available transmission protocols. You can use transmission protocols that are already widely used in enterprises for web services, such as MQ and IIOP.
• XML usage. Web Services uses XML to describe interfaces and messages that need to be exchanged between services and their consumers. You can use the Web Services Description Language (WSDL) to describe the interface to a web service. Although on the surface, WSDL is similar to an IDL or Java interface, it is more powerful and has components that support loose coupling of services. For example, WSDL supports multiple types of systems, so you can use it to describe services that use large host type systems. It also supports multiple protocols and transmission modes. For example, you can specify that a specific service is available based on JMS rather than HTTP. Finally, with the help of WSDL, you can define the operational behavior of a Web service in an abstract way, and then bind it to a specific way to access it at different network endpoints.
• Commitment to reduce complexity. One of the reasons for the complexity of distributed component technology is that they define their own programming models, so they need to learn a new set of APIs. In contrast, Web Services does not specify any new programming model. You can continue to use the environment you are familiar with, including J2EE or CORBA. This also means that you can use any programming language-C ++, Java, and Perl. Web Services is actually a combination of messaging technology.

From the above discussion, we can see that web services actually solves many problems related to the distributed component model. Web services is most suitable for deploying SOA.

However, we have not fully achieved this goal. As mentioned above, when we discuss the complexity related to the distributed component model, the main cause of the complexity is that it is difficult to support the entire service lifecycle, which involves not only service construction, it also involves service deployment, version control, protection, and management. We also need to extend the service definition to accommodate the existing assets of the enterprise, even if the enterprise is not based on Web Services technologies such as soap and WSDL. This includes integration built out of the message solution, such as. net, MQ series, tibco, and legacy and packaged applications. To support real reuse, we need to break the barriers in the enterprise. We also need to make it easier to discover and use these services-not only programmers, but also operators and even business analysts.

Service Infrastructure: emerging solutions

We can see that the industry continues to develop based on common experiences and lessons. The above discussion should not be understood as the location or value that traditional technologies do not exist in the enterprise. We still need an object-oriented programming language, such as Java, distributed component technology, and message passing system, to build a new system. As mentioned above, the problem lies in supporting reuse across existing technical silos by looking at the functions of these systems as services and supporting the creation of new composite applications using these services. Although manual building with existing technologies is feasible, it is neither easy nor cost-effective. Just like using J2EE as the infrastructure for building applications, we also need a similar infrastructure to form, consume, and manage the service lifecycle in an enterprise. In short, we need the service infrastructure (see figure 1 ). The essential features of such service infrastructure should include:

• Multi-middleware support: CORBA, J2EE, MQ, and tuxedo-these technologies are used for integration in enterprises. Applications built based on these products and technologies have become a silo, because there may be multiple "domains" that cannot be interacted in the enterprise ". Service infrastructure should allow enterprises to publish useful assets in these silos based on appropriate levels of granularity. With tools used to discover metadata in these systems and automatically create services based on them, it is easier to publish such services. All such services should be made public in a unified manner and abstracted Based on the technologies it is based on, for example, I should be able to build a new composite application using the MQ-based bill compilation and tuxedo-based call processing functions without learning any knowledge about MQ or tuxedo.
• Support for multiple transmission modes:JMS, MQ, FTP, HTTP and so on are all widely used transmission methods in enterprises today, and will continue to be used in the near future. The service infrastructure should not only support these transmission methods, but also provide a way to extend them using enterprise-specific protocols or transmission methods. In addition, the service infrastructure should directly convert the protocol, rather than making the service use a common protocol like HTTP. This is important for some high-performance applications, because the overhead resulting from conversion to standard messages or using protocols like HTTP may be unacceptable.
• Service Release and discovery:Services must be discovered before they can be reused. You need to use some form of registration library to discover existing services (the directory should be based on a certain query or browsing format) to register or publish new services. In addition, policies used by these services need to be defined and registered. Such policies can describe content such as the cost and security features of services.
• Service runtime and lifecycle management:This involves monitoring service availability, service fault recovery, service version control, or service stop. In short, advanced operational support must be provided. In the previous generations of integration and middleware Products, management and operational support appeared to be behind the scenes. This causes a lot of trouble for most enterprises and increases the cost. The service infrastructure should focus on operational considerations. Another important aspect is that, because services can be reused in multiple applications, the Service's unavailability will affect all applications dependent on it. Therefore, a special method should be provided for service version control and upgrade.
• Service Combination Support:This involves using existing services to build new composite applications. Because the service itself is application neutral and can be used in the context unexpected by the Service's initial designers, message conversion, message content-based routing, and introduction of some simple conditional logic must be supported.
• Service Security:Security is obviously a big problem. Therefore, it is necessary to support service access control based on certain policies, using audit and alarm Triggering mechanisms. In addition, because the service can span multiple applications with its unique security model, it is necessary to provide integration with these security models to provide end-to-end security.
• Ease of use:Service infrastructure should not introduce new programming models or APIs. In essence, it should be highly declarative and almost or completely requires no encoding. This should be provided by a very intuitive visualization tool.

Figure 1. Basic Elements of the service infrastructure

Have we achieved our goal?

Service infrastructure has gone a long way in supporting SOA and enhanced reuse. This represents the joint efforts of the entire industry in supporting reuse and simplifying system building. There is no doubt that the industry will continue to grow based on experience in deploying new applications that utilize such infrastructure. Many companies are concerned about the number of web services standards, some of which are driven by the competing supplier camps. More cooperation is required between suppliers, not only to quickly aggregate some important standards in the web services and security fields, but also to solve practical testing and verification problems, this will not cause inconvenience to customers due to product interoperability.

I listed a long list of requirements on the service infrastructure. The good news is that there are several products on the market that support most of these features. However, one thing you must be aware of is that by purchasing a product that claims to support these features, you cannot have a service infrastructure that delivers flexibility and agility value. SOA and the service infrastructure supporting SOA can be transformed, so organizations, process management, and culture need to be changed. IT organizations should implement architecture consistency and build closer alliances with their business risk owners, so that they can receive support and funding for the conversion. The process should be defined based on how to deliver the service and how to manage the dependencies between participants in SOA. Some services that are reused by most applications can be horizontal and general, while others can be used specifically for some selected applications. A management model that covers how to fund these services and how to develop these services is important. Finally, culture should encourage and reward reuse of existing services, rather than building everything from scratch.

all this may sound daunting, but it is indeed a daunting task. However, there are some good signs for development. First, the Web Service interoperability (WS-I) team specifically developed charts to improve web service interoperability across different implementations. Vendors perform interoperability tests based on configuration files provided by the WS-I. Although this seems to be something that should be done clearly, this is not the case with CORBA or J2EE. The situation for specialized middleware and EAI products is even worse. The second good news is that the tools used to build the service infrastructure are becoming more mature and easy to use. For example, Bea's AquaLogic Service Bus product is fully configuration-driven-almost all tasks can be completed through a graphical interface. Finally, many enterprises have deployed SOA and have benefited in terms of application development speed and cost. More mature IT organizations have obtained these indicators and best practices around their implementation, and proved to their enterprises how competitive agile it can be.