China Naming Network - Eight-character fortune telling - Preliminary understanding: SOA, SOAP, Web Service, WSDL, etc.

Preliminary understanding: SOA, SOAP, Web Service, WSDL, etc.

What is SOA and SOAP?

What exactly is SOA?

The definition of SOA (Service-Oriented Architecture) is a service-oriented architecture, which means that software is designed into services according to functions. These services define interfaces in a standard way and are called through standard protocols. . The interfaces and calling methods defined by SOA are independent of programming languages ​​and operating platforms. Broadly speaking, SOA can be implemented based on different underlying technologies, such as CORBA and Web Services. However, CORBA is rarely used because it is too complex and bloated, so the vast majority of SOA currently mentioned is based on Web Services technology. In the implementation of Web Services, the interface of the SOA service is defined in XML.

Under the SOA architecture, software development starts with business process analysis, uses componentized business modeling methods to identify and analyze various business models, integrates various practices into them, and establishes use cases on this basis. Use cases directly generate BPEL, and these BPEL can be integrated into a service integration framework, which describes various service information, thereby unifying various modules on the ESB to form a huge service warehouse.

Separate the middle layer and create a cross-technical architecture metadata and business logic in the middle layer, making it a cross-technical architecture, long-term inheritance, and continuously accumulated enterprise business library and business logic. The most valuable information asset is the service-oriented component library, and this service component library can also be reused by other enterprises and does not depend on any technical architecture. To exaggerate, if all software companies use SOA architecture, the world's software industry will be completely changed. Obviously, such a framework is not a product, nor is it just a technology, but a methodology for solving problems.

SOA may be used in two scenarios: the first is business interconnection; the second is a closed transaction system, which separates metadata and business logic to make it reusable. For example, in the first scenario, when businesses between different enterprises need to call each other, SOA technology may be used; in the second scenario, when systems need to be migrated within the enterprise, SOA technology is used The original data and business processes defined can be completed quickly.

SOA is not a new thing. IT organizations have successfully established and implemented SOA application software for many years. BEA, IBM, and other manufacturers have seen its value and have followed suit. The goal of SOA is to make IT more flexible to respond more quickly to the needs of business units and achieve a real-time enterprise (Real-Time Enterprise, which is the vision goal described by Gartner for SOA). As early as June 2001, BEA's CIO Rhonda proposed to transform BEA's IT infrastructure into SOA, and to control the entire enterprise architecture, improve development efficiency, speed up development, and reduce the cost of customization and personnel skills. Good results have been achieved in investment and other aspects.

SOA is a specification for designing, developing, applying, and managing distributed logical (service) units in a computing environment. This definition determines the breadth of SOA. SOA requires developers to design application software from a service integration perspective, even if the benefits of doing so are not immediately apparent. SOA requires developers to think beyond application software and consider reusing existing services, or examine how services can be reused. SOA encourages the use of alternative technologies and methods (such as messaging mechanisms) to structure applications by linking services together rather than writing new code. After proper architecture, the application of this messaging mechanism allows companies to quickly respond to changing market conditions within the time allowed by the business environment by simply adjusting the original service model rather than being forced to develop large-scale new application code. response.

SOA is not just a development methodology - it also includes management. For example, after applying SOA, managers can easily manage these enterprise applications built on the service platform instead of managing a single application module. The principle is that by analyzing the mutual calls between services, SOA allows company managers to easily obtain data information on when, why, and which business logic was executed, thus helping enterprise managers or application architects to iteratively Optimize their enterprise business processes and application systems.

One of the central ideas of SOA is to enable enterprise applications to get rid of the constraints of technology-oriented solutions and easily respond to the changes and development needs of enterprise business services. A single application in an enterprise environment cannot accommodate the (various) needs of business users. Even a large-scale ERP solution still cannot meet the growing and changing needs of business users and respond quickly to the market. It can only struggle to support its existing business needs by continuously developing new applications and expanding existing applications.

By focusing on services, applications can be focused to deliver richer, more purposeful business processes. As a result, SOA-based enterprise application systems often more closely reflect integration with business models. Services looks at technology from a business process perspective - that's from the top down. This perspective is contrary to the typical business perspective driven by available technology. The advantages of services are clear: they are integrated with business processes and therefore can represent the business model more accurately and better support the business processes. Instead we see an application-centric enterprise application model that forces business users to limit their capabilities to the capabilities of the application.

Enterprise process is the air that flows through the enterprise framework. It gives life to the components in the business model and defines the relationships between them more clearly. Processes define specialized methods for interacting with business models. For example, accounting may be a component of an enterprise services system - but sending invoices to customers is a business process. Services are defined to support business processes, so throughout the entire process are the assembly operations of various service components during process and logic implementation. Understanding business processes is key to customizing services.

Integration that benefits enterprise business Traditional application integration methods (point-to-point integration, enterprise message bus or middleware integration (EAI), business process-based integration) are complex, expensive, and inflexible. These integration methods are difficult to quickly adapt to the changing needs of modern enterprise business. Application development and integration based on service-oriented architecture (SOA) can well solve many of these problems.

SOA describes a complete development model to help client applications connect to services. These patterns customize a series of mechanisms for describing services, notifying and discovering services, and communicating with services.

Unlike traditional application integration methods, in SOA, all patterns surrounding services are implemented using standards-based technologies. The same goes for most communications middleware systems, such as RPC, CORBA, DCOM, EJB, and RMI. However, their implementation is not perfect, and there are always problems in balancing interactivity and the acceptability of standard customization. SOA attempts to eliminate these pitfalls. Because almost all communication middleware systems have fixed processing modes, such as RPC functions, CORBA objects, etc. However, services can be defined both as functions and externally as objects, applications, etc. This makes SOA adaptable to any existing system and allows systems to be integrated without any special customization.

SOA helps enterprise information systems migrate to a "leave-and-layer" architecture, which means that the system can provide external Web service interfaces without modifying existing enterprise systems. This is because they have been encapsulated by the application layer that can provide Web service interfaces, so SOA can quickly convert systems and applications into services without modifying the existing system architecture. SOA not only covers information from packaged applications, custom applications and legacy systems, but also functions and data from IT architectures such as security, content management, search, etc. Because SOA-based applications can easily add functions from these basic service architectures, SOA-based applications can respond to market changes faster and enable enterprise business departments to design and develop new functional applications.

What is Soap?

SOAP is the abbreviation of Simple Object Access Protocol.

SOAP is a lightweight, XML-based communication protocol for information exchange used in distributed environments.

Understanding of Soap:

The first step of understanding: SOAP = HTTP + XML

The second step of understanding: SOAP converts XML usage codes into request and response parameter encoding modes, and uses HTTP for transmission.

SOAP combines mature HTTP-based WEB technology with the flexibility and scalability of XML.

The third step of understanding: Specifically speaking, a SOAP implementation can simply be regarded as an HTTP request and response that follows SOAP encoding rules.

Note: SOAP is a protocol, not a programming language. In fact, many languages ​​​​have begun to support SOAP, such as: Java, C, C++ and JavaScript.

The origin of Soap? What problem does Soap solve?

SOAP was originally researched by Microsoft to solve the problems of MTS/COM resource consumption and lack of portability. Later, it was gradually accepted by giants such as IBM and joined the research. It has now been submitted to W3C to become a Web Service application transmission standard.

SOAP technology is mainly used to achieve interoperability between a large number of heterogeneous programs and platforms, so that existing applications can be accessed by a wide range of users.

SOAP means Simple Object Access Protocol. Indeed, as its name suggests, SOAP is very simple. It is an XML-based protocol that allows program components and applications to communicate with each other using a standard Internet protocol - HTTP. SOAP is an independent platform that does not rely on programming languages. It is simple, flexible, and easily extensible. Currently, applications can communicate with each other using remote procedure calls (RPC) based on DCOM and CORBA technologies, but HTTP was not designed for this purpose. RPC is very difficult to apply on the Internet, and they present many compatibility and security issues because firewalls and proxy servers usually block these types of traffic. The best way to communicate between applications is through the HTTP protocol, since HTTP is supported by all Internet browsers and servers. For this purpose, the SOAP protocol was created.

SOAP (Simple Object Access Protocol) is a simple protocol for exchanging information in a decentralized or distributed environment. It is an XML-based protocol and consists of four parts: SOAP encapsulation ( envelope), encapsulation defines a framework that describes what is in the message, who sent it, who should accept and process it and how to process them; SOAP encoding rules (encoding rules), used to represent the data that the application needs to use Instances of the type; SOAP RPC representation, which represents a protocol for remote procedure calls and responses; SOAP binding, which uses the underlying protocol to exchange information.

Although these four parts are defined as a whole as part of SOAP, they are functionally intersecting and independent of each other. In particular, envelope and encoding rules are defined in different XML namespaces (namespace), which makes definition easier.

What is CXF?

Apache CXF = Celtix + XFire, the predecessor of Apache CXF was called Apache CeltiXfire, and now it has been officially renamed Apache CXF, hereafter referred to as CXF. CXF inherits the essence of two major open source projects, Celtix and Code First or WSDL First to easily publish and use Web Services. Currently it is still just an incubation project of Apache.

Apache CXF is an open source Services framework. CXF helps you build and develop Services using Frontend programming API, like JAX-WS. These Services can support multiple protocols, such as SOAP, XML/HTTP, RESTful HTTP or CORBA, and can run on multiple transmission protocols, such as HTTP, JMS or JBI. CXF greatly simplifies the creation of Services, and it inherits In addition to the XFire tradition, it can also be naturally and seamlessly integrated with Spring.

CXF contains a large number of functional features, but mainly focuses on the following aspects:

Supports Web Services standards: CXF supports multiple Web Services standards, including SOAP, Basic Profile, WS-Addressing, WS-Policy, WS-ReliableMessaging and WS-Security.

Frontends: CXF supports multiple "Frontend" programming models. CXF implements the JAX-WS API (following the JAX-WS 2.0 TCK version). It also contains a "simple frontend" that allows clients and EndPoints to Created without Annotation annotation. CXF supports both WSDL-first development and code-first development from Java.

Ease of use: CXF is designed to be intuitive and easy to use.

There are a large number of simple APIs used to quickly build code-first services. Various Maven plug-ins also make integration easier, support JAX-WS API, support Spring 2.0's more simplified XML configuration method, and so on.

Support for binary and legacy protocols: CXF is designed to be a pluggable architecture that can support both XML and non-XML type bindings, such as JSON and CORBA.

Let's use cxf to create a simple webservice.

First of all, the packages required by cxf: The website explains that the following packages are necessary, but in my actual project, the packages in red are not used.

You can add packages that suit your needs.

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo -annotation.jar (Or the Sun equivalent)//

geronimo-javamail.jar (Or the Sun equivalent)//

neethi.jar

jaxb -api.jar

jaxb-impl.jar

stax-api.jar//

XmlSchema.jar

wstx-asl .jar

xml-resolver.jar

Distributed applications and browsers

Study current application development and you will find a definite trend : People are beginning to prefer browser-based thin client applications. This is certainly not because a thin client provides a better user interface, but because it avoids the high cost of publishing a desktop application. Publishing desktop applications is expensive, partly because of problems with application installation and configuration, and partly because of communication problems between client and server.

Traditional Windows rich client applications use DCOM to communicate with the server and call remote objects. Configuring DCOM to work properly in a large network will be a very challenging task, and it is also a nightmare for many IT engineers. In fact, many IT engineers would rather endure the functional limitations brought by the browser than run a DCOM on the LAN. The result, in my opinion, is an application that is easy to publish, but difficult to develop, and has an extremely limited user interface. In the extreme, you spend more money and time, but develop an application with weaker functionality from the perspective of users. Don’t believe it? Ask your accountant what he thinks of new browser-based accounting software: The vast majority of business program users want a friendlier Windows user interface.

Regarding the communication problem between the client and the server, a perfect solution is to use the HTTP protocol to communicate. This is because any machine running a web browser is using the HTTP protocol. At the same time, many current firewalls are also configured to only allow HTTP connections.

Another problem faced by many commercial programs is interoperability with other programs. If all applications were written using COM or .NET language and all ran on the Windows platform, the world would be peaceful. However, in fact, most business data is still stored in the form of non-relational files (VSAM) on mainframes and accessed by mainframe programs written in COBOL language. Moreover, many commercial programs continue to be written in C++, Java, Visual Basic, and a variety of other languages. Now, all but the simplest programs need to integrate and exchange data with applications running on other heterogeneous platforms. Such tasks are usually accomplished by special methods, such as file transfer and analysis, message queues, and APIs that are only suitable for certain situations, such as IBM's "Advanced Program to Program Communication (APPC)" and so on. Previously, there was no application communication standard that was platform, component model, and programming language independent. Only through Web Service can the client and server communicate freely using HTTP, regardless of the platform and programming language of the two programs.

What is WebService?

Web services are a new platform for building interoperable distributed applications. As a Windows programmer, you may have built component-based distributed applications using COM or DCOM.

COM is a very good component technology, but we can easily cite situations where COM cannot meet the requirements.

The Web services platform is a set of standards that defines how applications can achieve interoperability on the Web. You can write Web services in any language you like and on any platform you like, as long as we can query and access these services through Web service standards.

The Web service platform requires a set of protocols to achieve the creation of distributed applications. Any platform has its data representation method and type system. To achieve interoperability, the Web service platform must provide a standard type system for communicating different type systems in different platforms, programming languages, and component models. In traditional distributed systems, interface-based platforms provide some methods to describe interfaces, methods and parameters (Annotation: such as the IDL language in COM and COBAR). Similarly, the Web service platform must also provide a standard to describe the Web service so that customers can get enough information to call the Web service. Finally, we must have a way to make remote calls to this Web service. This method is actually a remote procedure call protocol (RPC). In order to achieve interoperability, this RPC protocol must also be platform and programming language independent.

Web Service is a new branch of web applications. They are self-contained, self-describing, modular applications that can be published, located, and called through the web. Web Services can perform any function from simple requests to complex business processes. Once deployed, other Web Service applications can discover and call the service it deploys.

Web Service is an application that can use standard Internet protocols, such as Hypertext Transfer Protocol (HTTP) and XML, to programmatically embody functions on the Internet and intranets. Web services can be viewed as component programming on the Web.

1 History

Technologies widely used on the web:

◆TCP/IP: Universal network protocol, used by various devices

◆HTML: A universal user interface that can display data using HTML tags

◆Java: A universal programming language that can be written once and run anywhere

◆XML: A universal data expression language, An easy way to deliver structured data on the web

They are characterized by their openness and cross-platform nature. Openness is the basis of Web services.

2 Trends in Web development

More dynamic content

◆ Bandwidth is cheaper and easier to obtain

◆ Storage is cheaper , easier to obtain

◆Pervasive computing becomes more important: A large number of devices, such as mobile phones, web pages, computers, and PCs, have become common on the Internet, and platforms have become more diverse, such as Cross-platform technologies like XML have become more important

3. What role do Web Services play?

These trends mean that more intelligent processing, manipulation and aggregation of content are becoming important. Let's look at the four trends predicted from the perspective of Web services:

◆Content is more dynamic: a web service must be able to merge content from multiple different sources, which can include stocks, weather, news, etc. , in a traditional environment content, such as inventory levels, shopping orders or catalog information, etc., come from the back-end system

◆Bandwidth is cheaper: web services can distribute various types of content (audio, Video streaming, etc.)

◆Cheaper storage: web services must be able to handle large amounts of data intelligently, which means using technologies such as databases, LDAP directories, buffering, and load balancing software to maintain scalability

◆Universal computing is more important: web services cannot require customers to use a certain version of Windows' traditional browser, and must support various devices, platforms, browser types, and various content types.

4 Two important technologies

To achieve this goal, Web services use two technologies:

◆XML XML is used to transmit structured information on the web. A great way to use data, Web services need to operate data in a reliable and automatic way. HTML will not meet the requirements, but XML can make web services process data very conveniently. The separation of content and presentation is ideal

◆SOAP SOAP uses XML messages to call remote methods, so that web services can interact with remote machines through the post and get methods of the HTTP protocol. Moreover, SOAP is more robust, flexible and easy to use.

Other technologies like UDDI and WSDL are closely integrated with XML and SOAP technologies for service discovery.

These three technologies make up the Web service platform.

XML and XSD

Extensible Markup Language (XML) is the basic format for representing data in the Web service platform. In addition to being easy to create and analyze, the main advantage of XML is that it is both platform-independent and vendor-independent. Irrelevance is more important than technical superiority: software vendors will not choose a technology invented by a competitor.

XML solves the problem of data representation, but it does not define a set of standard data types, let alone how to extend this set of data types. For example, what exactly do integer numbers represent? 16-bit, 32-bit, or 64-bit? These details are all important to achieving interoperability. XML Schema (XSD) developed by W3C is a set of standards that specifically solves this problem. It defines a standard set of data types and provides a language to extend this set of data types. The Web service platform uses XSD as its data type system. When you use a certain language (such as VB.NET or C#) to construct a Web service, in order to comply with the Web service standard, all data types you use must be converted to XSD types. The tool you use may have automatically completed this conversion for you, but you will most likely modify the conversion process to suit your needs.

WSDL

How would you introduce to others what functions your Web service has and the parameters for each function call? You might write a set of documentation yourself, and you might even verbally tell people who need to use your Web service. These informal methods have at least one serious problem: when programmers sit down in front of the computer and want to use your Web service, their tools (such as Visual Studio) cannot provide them with any help, because these tools do not provide any help at all. I don't understand your Web service. The solution is: provide a formal description document in a machine-readable format. Web service description language (WSDL) is such an XML-based language used to describe Web services and their functions, parameters and return values. Because it is based on XML, WSDL is both machine-readable and human-readable, which is a great benefit. Some of the latest development tools can not only generate WSDL documents based on your Web service, but also import WSDL documents to generate code that calls the corresponding Web service.