1 Overview
2, distributed protocol technology and SOAP relationship
3. Introduction to SOAP concept
4, SOAP B2B e-commerce application
I. Overview
SOAP (Simple Object Access Protocol) Simple Object Access Protocol is a simple protocol to exchange information in a disperse or distributed environment, which is an XML-based protocol. SOAP technology helps to achieve interoperability between a large number of heterogeneous procedures and platforms, thereby enabling the existing application to be accessed by users. SOAP is a combination of mature HTTP-based Web technology with XML flexibility and scalability.
SOAP provides a simple and lightweight mechanism for using XML pairs of structured and type information in a loosely, distributed environment. SOAP itself does not define any application semantics, such as programming models or specific semantics implementations, it just defines a simple mechanism, expressed applying the application through a modular packaging model and the data of the data encoded in the module. Semantics. This capability of SOAP allows it to be used by many types of systems to extend from the message system to the RPC (Remote Procedure Call).
SOAP consists of four parts:
1) SOAP ENVELOP (SOAP envelope), it constructs a whole representation framework, which can be used to indicate what is in the message, and who should handle it, and this is optional or forced.
2) SOAP ENCODING RULES (SOAP Code Rules) defines an instance of a data type for a sequencing mechanism for switching applications.
3) SOAP RPC REPRESENTATION (SOAP RPC Representation) defines a convention for representing remote procedure calls and responses.
4) SOAP BINDING (SOAP Binding), which defines an agreement with the underlying transport protocol to exchange SOAP envelopes between nodes.
The main design goals of SOAP are concise and scalable. This means that there are some features in the traditional message system or distributed object system will not be included in the core specification of SOAP. These features include:
Distributed garbage collection; batch messaging / processing; object references (support for distributed garbage collection); object activation (support for object references). SOAP defines a message interaction mechanism that describes how to encode information with XML. Typically, SOAP is used to explain the parameter values of remote calls at runtime, and fill these values in an XML document using a particular encoding manner. Then, XML data is transmitted to the remote server via HTTP protocol, and of course, other transport protocols are sometimes used. In addition, there are many remote methods to call specifications, such as Corba's IIOP, DCOM ORPC, and Java Remote Method Protocol. SOAP features - the biggest advantage is that it is based on text (by using XML), not binary, and it is not a manufacturer. SOAP uses a general transport protocol ----- mainly http. This is not only the secret weapon of SOAP, but also the key to its success. Since the company's firewall rarely restricts HTTP data, SOAP should be easily passed through the firewall (using HTTP as a transmission protocol) SOAP. A dedicated distributed computing protocol is impossible. The network addresses used usually does not allow access to the security system that has been installed. Another advantage of SOAP is XML. SOAP can integrate systems that have not communicated and shared resources. At present, various computing systems are gradually supporting XML. As long as you get an XML document into the system, you can usually find software for reading and explaining XML encoding information. To support remote computing, SOAP saves method call parameters as a unique binary format, and passes these parameters as XML information to the remote server, and then the corresponding SOAP handler on the server will use XML information, and restore it to binary form. deal with. Second, Distributed Protocol Technology and SOAP Relationship 1 Application System Specification. Several parts of the object request proxy ORB, object service, public facilities, domain interfaces, and application interfaces. Its core part is an object request proxy ORB (Object Request Broker). ORB provides a mechanism that allows for a transparent request and response by this mechanism. Distributed, interoperable objects can utilize ORB configurations to be interoperable. ORB can be seen as a middleware that establishes a client / service relationship between an object. Based on ORB, customer can transparently call the method of service objects, which can run on the same machine with customers, or run over other machines to interact with customers through the network. The ORB intercepts the request sent by the customer and is responsible for finding the service object that implements the request on the software bus, then completes the parameters, method call, and returns the final result. CORBA 1.1 is published by the object management organization in 1991. Define Interface Definition Language (IDL) and Apply Programming Interface (API) to activate the interaction of the client / server by implementing the object request agent (ORB). Corba 2.0 issued the implementation of how to span different ORB providers in December 1994 to communicate. The recent development of the CORBA specification increases the characteristics, service quality control and CORBA Component Model facing the Internet. Internet integration features include a firewall (FireWall) and Naming Service, which defines the URL naming format for IIOP transmission.
Service quality control includes an asynchronous message service capable of quality control, a set of request schemes for real-time CORBA and fault tolerance CORBA for embedded systems. Corba CCM (CORBA Component Model) is based on the CORBA specification (after version 2.3) that supports PoA, it is developed based on the current specifications of the EJB. COM / DCOM (Component Object Model) is a distributed component object model based on Microsoft, support communication between the LAN, WAN, and even the objects of different computers on the Internet. DCOM-based applications, components, tools, etc., handle low-level detail issues of network protocols, without having to pay too many network protocol details, allowing users to concentrate on solving the problems required by users. DCOM is located between the components of the application, and the components are glued together with the unasual way to form a complete feature application. COM is a set of component framework techniques that Microsoft's need for application layers based on WINDOWS 2000. COM is no longer limited to the component technology of COM, it is more focused on the design and implementation of distributed network applications, and Com inherits COM almost all advantages, while avoiding some of the shortcomings in COM implementation. COM is tightly coupled to the operating system and provides comprehensive services to the application via system services. COM not only inherits many of COM, DCOM, and MTS, but also adds some services, such as load balancing, memory database, event model, queue service, etc. COM new service provides a strong feature for COM applications, making applications based on COM can use these services to obtain good enterprise application features. EJB (Enterprise Javabeans) is part of the Java-based server-side component specification J2EE, which is launched. Since J2EE is launched, it has developed extensive development and has become standard technologies for application server. Sun EJB technology is based on the local components of Java Bean, and the development of server-oriented distribution applicability technology is developed. EJB gives the system's server-side distribution component specification, including the interface specifications of components, component containers, and standard specification content such as component packaging, component configuration, and the like. From the perspective of distributed calculations, the EJB is the basis for distributed technology like CORBA. Providing communication means between objects. EJB is a distributed component model for developing security, scalable, transactional, and multi-user components. Simply put, EJB is (ideal) a reusable software unit that contains business logic. As the JSP page allows the application and representation logic to be separated, EJB allows the application logic to be separated from the system level service so that developers can concentrate on specific business issues, not system programming. These enterprise applets (Bean) business objects have three basic forms, and there is no need to implement all three, which are sessions beans beans beans beans beans beans Beans Beans Beans (Message-Driven) beans, respectively. Enterprise Javabean is a structural system based on components-based distributed computing environment. Enterprise beans are components of distributed enterprise application systems for transaction-oriented. 2, the relationship between SOAP and CORBA, DCOM / COM / COM and EJB is first pointed out that SOAP does not replace CORBA, COM / DCOM, and the three concepts are distinguished. COM / DCOM is a component model, CORBA is a service standard for distributed applications. CORBA and DCOM establish a service, service objects to execute client calls. SOAP is a communication protocol based on XML and HTTP distributed objects, which is a protocol for communications in COM / DCOM and CORBA objects.
In fact, the two can be combined with SOAP interoperability and CORBA powerful execution capabilities. OMG is paying attention to this development. Corba applications and DCOM applications cannot achieve interoperability, and both cannot work together. Because in the ORPC (Object RPC) protocol, use ObjRef to represent a reference to run objects; in CORBA / IIOP (Internet Inter-ORB Protocol), use the exchange interoperable object reference to IOR (Interoperable Object Reference) represents a server Object references. Unfortunately, the IOR and Objref cannot be associated. However, using SOAP can be implemented on the vertical application level level integration, which can be better integrated with CORBA, and DCOM is a whole. Although the three platforms of CORBA, DCOM / COM / COM and EJBs have different historical backgrounds and commercial backgrounds, their own focus and characteristics, in fact, there is also a lot of exchange and complementarity. For example, EJB provides a method of clear, compact distributed computing models, and component interoperability, providing considerable flexibility for component application development. CORBA CCM is an integration technology instead of programming technology. It provides a binder that makes a variety of functional modules and bundled them together. EJB and CORBA can be seen as complementary. This development requirement for web applications, many manufacturers attach great importance to promoting the combination of EJB and CORBA technology, future RMI may be built on IIOP. CORBA is not just an object requesting agent ORB, and is also a very complete distributed object platform. CORBA can extend EJB in network, language, component boundaries, and various applications in operating systems. Many platforms currently implement interoperability of EJB components and CORBA components. Interoperability between DOCM and CORBA is relatively complex compared to each other of EJB and CORBA, while interoperability between DOCM and CORBA is relatively complex, although DCOM and CORBA are extremely similar. The DOCM interface pointer is generally equivalent to CORBA object reference. In order to achieve interoperability of CORBA and DCOM, OMG joins the implementation specifications of CORBA and DCOM interoperability in CORBA 3.0, and provides interface methods. With the emergence of SOAP, people are more and more discovering this is an ideal technology to solve different component platforms. At this time, XML has been widely used, and most platforms have an XML processor that can be used, using XML re-use Describe and package the respective remote component access protocols, so that the remote access protocols of the various component platforms can be transmitted through the same standard message, which is the initial concept of SOAP. Figure 1 Soap Slap Component Platform Difference Referring to Figure 1, we can see that although various component platforms have their own remote object call protocols, CORBA is IIOP, COM is ORPC, and J2EE / EJB is RMI, however they are It is possible to re-encapsulate the data in these protocols into SOAP, that is, each platform requires a protocol adapter to achieve conversion from the own protocol to the SOAP protocol, so they can be called through the SOAP protocol. SOAP is a pure message protocol specification that is not related to the platform, and is a data description specification XML based on a widely used platform, and it can be implemented smoothly in various platforms. Third, about the SOAP concept introduction 1, the protocol · SOAP About SOAP message format and processing rules are simple control mechanisms for generating and receiving SOAP messages between different applications along the SOAP message transfer path. A set of specifications and conventions. · SOAP binds its set of specifications and rules that transmit SOAP messages on or within another underlying network transfer protocol.
Typical SOAP bindings include transmitting a SOAP message in an HTTP message or transmitting SOAP messages over TCP. SOAP Node SOAP Node The SOAP message is processed according to the entire specification defined by the SOAP. The SOAP node is responsible for compliance with the rules of the SOAP message exchange and provides services to access through the SOAP binding of the underlying protocol. Any case where the SOAP agreed will cause the SOAP node to produce a SOAP FAULT (SOAP error). The data package · SOAP message SOAP message is the basic unit of communication between the peer SOAP node. · The SOAP envelope SOAP envelope is the outermost structure of the SOAP message defined in the SOAP specification (SOAP Message) in the syntax. In syntactics, it contains all other SOAP elements and application elements. · SOAP entry OAP entries are structural structures, which are used to include a logically single element, which is required to be processed by the SOAP node. A SOAP entry is identified by the full modifier of the outermost element of the entry (with named space modification), which is composed of a local name and a namespace URI. The SOAP entry encapsulated in SoapHeader is called a Header entry, while the SOAP entry encapsulated in SOAP Body is a Body entry. · SOAP HEADER is a set of SOAP entries (0 or more) capable of being processed by any SOAP recipient node in the SOAP message transmission path. · SOAP BODY is a set of SOAP entries (0 or more) that can be processed by the final SOAP receiving node in the SOAP message path. · SOAP FAULT It is a special SOAP entry generated by the SOAP node. Figure 2 Soap Message Component Figure 2 demonstrates a form of SOAP messages. Due to the XML technology, we can see it is a perfect nested structure. · SOAP Data Model It is a set of abstract construct conventions for describing the general data type and link relationship in the data. · SOAP data encodes it indicates that one or more SOAP entries in the SOAP message are used in accordance with the data representation of the Synth Method in the SOAP Data Model. 3, message reception and sending · SOAP sender SOAP sender is a SOAP node that issues SOAP messages. · The SOAP Receiver SOAP recipient is the SOAP node that accepts the SOAP message. · SOAP Message Path SOAP Message Path refers to a set of SOAP senders and SOAP recipients to transmit a simple SOAP message. It includes an initial SOAP sender, zero or more SOAP intermediaries, and the final SOAP recipient. · The initial SOAP sender is the initial generator of the SOAP message, and the first node of the SOAP message path. · SOAP intermediary Node SOAP intermediary node is both SOAP recipients and SOAP senders, an application that the SOAP message can arrive. When the SOAP message is transmitted along the SOAP message path, the SOAP interbard node will process a set of determined SOAP entries, then forward the message to the next SOAP node of the message path until it is transmitted to the final SOAP recipient. • The final SOAP recipient refers to the final recipient of the SOAP message transmitted by the SOAP message path by the initial SOAP sender. If there is a SOAP error in the SOAP message path, the SOAP message will not reach the final recipient. · SOAP Application SOAP Application is a production, consumption SOAP message, or software entity that implements some other action for SOAP messages. When processing SOAP messages, its behavior is followed by the SOAP processing model. 4. Data Coding Concepts • SOAP Data Models A set of abstract constructs for describing the general data type and link relationship in the data. · SOAP data encoding uses one or more SOAP entries in the SOAP message, follow the data representation of the Synth Method according to the SOAP Data Model.
Fourth, SOAP's B2B e-commerce application enterprise-class (Business to Business) e-commerce is generally referred to as B2B e-commerce process, which is a buyer, seller, and information between their middlemen (such as financial institutions). Exchange and transaction behavior integrate electronic operations together. On the Internet, the B2B e-commerce must have a certain basis, which is mainly manifested in: 1) standardization; 2) User authentication; 3) Network transaction integration technology. For this three-point SOAP, it is a good support: 1) SOAP uses XML to describe data, and XML is a normal choice for expressing data. 2) SOAP uses existing TCP / IP-based application layer protocols HTTP, SMTP, POP3, etc., which can be maximized with existing communication technology. Bind SOAP to HTTP, which can fully uttever security based on HTTP message protocols. 3) SOAP's message path mechanism and expandable header and Body mechanism provide good support for distributed computing, which is especially effective for distributed portals for LAN applications and require automated data exchange. Enterprises can use the data stored by each distribution point based on the data of the existing message system to rely on the application of the application, and solve the integrated problem of the backend system established by different component technology through SOAP. SOAP Message (SOAP message) is a carrier for transmitting application entry call information, especially B2B application calls. Fundamentally, SOAP Message is a transmission method from the sender to the recipient. In B2B applications, the SOAP message is a basic carrier of the B2B application call information. SOAP ENVELOPE (SOAP envelope) is used to describe the structure of SOAP Message, defining a description structure with SOAP HEADER, SOAP Body to the child body. SOAP envelope is the information framework for SOAP Message. In B2B applications, SOAP Envelope provides a basic information description framework for B2B application call information. SOAP Header provides a scalable mechanism for spreading SOAP messages in dispersed modularity, while communication between communication does not need to have a pre-agreement. A typical exemplary example in B2B applications can be some Header entry such as authentication, transaction management, and payment. The SOAP Body element provides a simple mechanism for the exchange of information that must be handled with the event's final recipient. Various data information of the application entry call and response can be described in the SOAP Body. In B2B applications, the application of the Body element can be a B2B application call request information (such as product ID, product number, etc.) and response information (such as order number, order fulfillment date) and error message (such as product stocks are not enough). SOAP ENCODING (SOAP Traveling Method) is based on a simple type system, and this system is the general characteristics of the type system of the program language, database, and semi-structural data. The default SOAP Encoding definition and XML Schema are compatible, basically consistent. SOAP ENCoding makes similar integer, string, array, structure (Struct), and other data types are represented in the SOAP message. SOAP ENCODING provides a default way for the data representing SOAP Header and SOAP Body, of course, you can also use any other XML Schema-based / value description system. SOAP RPC Presentation is a convention for indicating remote procedure calls and responses, using XML scalability and scalable to package and exchange RPC calls. Currently, such as HTTP, SMTP, POP3, etc., using these protocols, such as HTTP, SMTP, POP3, etc., using these protocols, and complete the call and response of SOAP. Specifically, the SOAP message is sent as the body of these protocols.
