The interoperability problem is easy but usually, but it is more difficult. Although the Web Service promises to provide the best solution to connect Based on .NET and J2EE applications, the process is not simple. We have found that many problems need to consider when using SoapBuilders and Web Services Interoperability Demo (WSID). Recently released Web Services Interoperability Organization (WS-i) also provides a lot of valuable deep insights.
This article includes the development process of Demo, participating in the SOAPBuilders interoperability test, and the experience summary acquired by WS-i in recent-released norms (want to know more about WS-I information, you can check "Talking about WS-I" in the toolbar). Here, we start to study which ranges can be used to achieve interoperability by using Web Services to reduce your current and future investments on .NET and J2EE. The conclusions we provide will help you decide whether to invest in both platforms, as well as the limitations of Web Service interoperability will allow you to choose one of the platforms.
The interoperability problem appeared in the early stage of the development of the computer industry. At that time, the development of software was to adapt to a particular hardware shunt, and the recent approach to adapt to a particular operating system that adopts a particular hardware configuration. However, the operating system is often replaced, and new hardware is often used, or the hardware is often upgraded. Therefore, although the computer application uses a compiled or interpreted language based on the operating system, it is still subject to the impact of the operating system. This is indeed, although there are some advanced languages (sometimes called third or fourth generation language, such as Visual Basic, C # and Java), the behind-the-screening idea is to develop a programmer in a higher level abstraction program.
In the early stage of computer applications, people did not consider the problem of interface connection or integration programs too much. This situation has continued until the computer reflects important business uses - making some or all commercial operations automated, some practical problems such as investment protection, integration, and interoperability. Business requirement, regardless of the software of investment, they can continue to use these programs, regardless of whether hardware, operating system, and development technologies have changed. This makes the compatibility between completely different hardware and operating systems have become the largest, the highest cost, because it directly affects productivity, downtime, chance to grasp and other failures Aspects of questions.
The interoperability of .NET and J2EE is very important because most companies use these two platforms to develop programs. .NET and J2EE represent different methods of solving the same problem: development, deployment, and management custom business procedures. The importance of custom business procedures is that the business itself has different operations, and if it does not make it unique, it will affect management inventory, process orders, or provide financial services (Financial Services). In fact, mutual competition between enterprises is often very intense; for example, Wal-Mart has blown in Inventory Management System, saying that it can closely consolidate the purchasing power from all its stores in real time. And it is possible to use this information from the supplier to get a lower price.
Understand the difference between .NET and J2EE in a perfect world, between the main development platform for custom applications is completely compatible, and programs written for a platform are fully applicable to other platforms. However, we are far away from the world. The current software industry is still quite immature, and it can even be said not fully standardized.
Unlike the electronics industry and other industries, the computer industry has been working hard for establishing a standard. Not long ago, DVD Forum successfully released a set of standards for DVD-ROM software and hardware. All DVD players can play any DVD disc, all DVD hardware manufacturers, and DVD dishes will be in accordance with the same coding standard. In the software industry, all major developers have implemented software systems that are not compatible. They advocate how their products are useful to developers, and they expect developers to use their products to develop projects, because once the program is developed into the production phase, it is generally not replaced with other products. Software developers are not to establish a market that is involved in all people, but to occupy a place in this complex development market.
The initial idea of Microsoft.Net is to prepare custom development close to the operating system platform, of course, refers to using Windows (currently XP, ME, and 2000). Visual Basic and C # are the most important development languages on the .NET platform, and they cannot work on other platforms. Java-based J # and .NET platforms are also incompatible. Microsoft claims that many developers have developed language and .Net Common Language Runtime (CLR), but until today, we see the CLR is just a Windows version. This explains an important interoperability problem because each programming language (divided according to definition) has its own specific data type and data structure.
figure 1.
Compare .NET and J2EE
With only a simple HTTP connection, it is unable to achieve interoperability because the program is developed in the programming language abstraction layer above the operating system (see
figure 1). The development programming language on the .NET and J2EE platforms has an essential difference (.net compare privatization and J2EE is more open). Another important difference is to .NET, development environment and operating system are provided by the same developer. .NET and J2EE have different, non-compatible binary communication protocols for distributed applications: They are .NET Remoting and Remote Method Invocation / Internet Inter-ORB Protocol (IIOP).
Of course, Java has different data types and data structures than VB, C #, or even J #. The primary problem that usually solves interoperability is to process data types and structural incompatibility, which is also an important challenge in testing the interoperability of the Web Services.
Although Java runs in a Windows platform, the J2EE application can be developed on any platform and is connected to any operating system in a manner that is often referred to as "loose coupling". In other words, J2EE uses the operating system-specific features, such as direct memory management (Direct Memory Management); or Platform-Specific communication mechanism, such as Microsoft Remote Procedure Call (RPC).
The .NET development environment can make full use of the "Tightly Coupled" or "Native" (Native) (Native) (Native), and can use Microsoft-specific features and operating system services. Overall. Net is more likely to use, which better combines the characteristics of Windows itself than J2EE; but the advantage of the J2EE program is in other operating systems (see Resources). Different from the Programming Language Behavior, local distributed computing protocols, data types, and structures, and the separation from the operating system service, they have an impact on the interoperability. Unless everyone uses the same programming language, operating system and applications, you still need to understand a variety of complex interoperability issues, and which solution is more worth going to study.
Web Services specification for Web Services solutions to solve the interoperability problem has been introduced, including resolving the interoperability of .NET and J2EE and Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Universal Protocols such as DESCRIPTION, DISCOVERY, and INTEGRATION (UDDI). It is quite important to understand what problems can really solve and how to solve the problem by using them (see Figure 2).
figure 2.
Review basic web services architecture
The SOAP specification defines the message format transmitted from HTTP to TCP / IP data. The WSDL specification defines how to describe a Web Service, and UDDI defines how to register (discover) and discover Web Service description. SOAP and WSDL are standard in the underlying WORLD WIDE Web Consortium (W3C). W3C is also responsible for customizing various specifications in the field of HTML and XML.
In addition, W3C also provides sponsors for Web Services Architecture Working Group, which is responsible for developing a Web Service Reference Schema for Basic Specifications (REFERENCE ARCHITECTURE). The relationship of SOAP, WSDL, and UDDI shown in the draft artificial draft chart of architectural specification can be seen in Figure 2. The Web Service specification and the underlying platform that achieve their underlying platform are completely independent, this is similar to HTTP and HTML, while they can run on the .NET and J2EE platforms. To learn more about .NET and J2EE comparisons for support differences on Web Service specification, please review ERIC's article "Decide Between J2EE and .NET Web Services".
Web Services Architecture Working Group has also developed extended specification, such as in security, coordination, and transaction processing. The products used to achieve these norms are not a lot, so I will introduce it here unless some more complex interoperability issues, because you have to understand whether the Web Service interaction is supported to support other specifications. And which specifications they support them. However, from the experience so far, even the most basic Web Service specification also tries to challenge the interoperability because Web Service technology exists in a advanced abstraction layer, which includes two main interactions ( Interaction style), each has its own consideration.
In general, developers use two mechanisms to access a remote program (that is, call another application from a program located in a different address space): RPC, it mainly includes definition and use external programs Call the interface; and the file or queue (Queue) operation, the program implements data sharing by reading writing on files or queues. SOAP is specified and considered (protocol) in consideration of these two ways. In the Web Service field, they are called interactive ways to RPC (RPC-Oriented) and Document-Oriented. The RPC method is more common in synchronous communication functions, such as in CORBA, COM, and in the binary communication protocol used in .NET and J2EE. One benefit using RPC is that the requestor can see the definition of the Service in Interface Definition; that is, programs or method names and call parameters can be used to provide information about Service behavior. Another benefit of using a kit-based RPC method is to implement the programming interface of the RPC mode automatically implements the transition between the real data type and the XML structure. This will cause the programmer from the data conversion. The advantage of using a document (or a messaging) method is that the requester and provider can obtain consistency on the data (or schema) definition, and the specific details of the program or method call do not require. However, the way of document is limited to transmitting and receiving data using an XML document. Since the use of XML documents is now more wide, this is not a problem, although early users are more willing to convert non-XML information to the appropriate XML structure to improve file interaction. Ultimately, use RPC-based or document-based mode will be called by the respective service calls (do you need to use detailed parameters or relatively few call operations on a normal document or relatively less call operations?) And transmitted data Type (if you need to convert the data is simple or complex data type?) To determine.
A large number of interoperability work is done by SOAPBuilders through the RPC interactive interaction in WSID - mainly through "debugging" or found a common point in the support data type and architecture in multiple SOAP product implementations (CommON Denominator) . The results define a set of data types and structures that can be used to achieve interoperability. So the list becomes the primary thing to check the .NET and J2EE Web Service products. I will teach you how to do it behind this article.
The lower level of interoperability is done with a document-oriented interaction. However, WS-I claims that it is difficult to use a wide range of interoperability for RPC methods, and call for companies to use a document-oriented way to get better results. Documentation mode is implemented as documentation. Transfer SOAP messages are asynchronous asynchronous messages as through a Message Broker, such as Microsoft Message Queue (JAVA Messaging Services (JMS), which is only in TCP / Use HTTP on IP, and the message format is defined by WSDL. In fact, the way of documentation should avoid resolving data types and structures in the Web Service layer, but developing such programs need to do more work. We will talk about this problem in the following sections of this article.
The relationship between the Connection-Oriented protocol is equivalent to the relationship between the synchronous and asynchronous communication protocols. Synchronous communications simulates a subroutine through the block calling program until a response is called. If the called program is not completed, the caller will receive an error message, whether the program being called is running on the remote network or in the local machine. However, a necessary condition for implementing this mode is that the calling program and the CONVERSATION must be maintained between the modified programs. This continuous connection consumes a lot of network resources, which is why HTTP does not support it. This means that you have many restrictions when using .NET and J2EE object mode. For example, you cannot use SOAP that relies on multiple interactive operations that depend on the same conversation on HTTP, and you cannot perform object lifecycle management, such as constructing, destroy and fragmentation ( Garbage collection).
But by asynchronous call, you can write files through a program, followed by another program to read data from the file. You only need to have a network connection during the read and write file. These programs can run in the same machine or different machines, as long as the data written by the "call" (or generated) program can be accepted by the "call" (or use) program. However, in the case of asynchronous calls, the calling program cannot understand what happens when the return data is confiscated; and the custom standard error handling and results analysis (resolution) has become another interoperability issue.
When you can't determine that the web service is not the correct choice to measure it, it is very important to understand if you need to use a synchronization protocol. From the definition, the HTTP-based web service is a one-way asynchronous message, so it is the best way to solve files or queue-based interoperability issues. For example, if interoperability needs to include a data update to synchronize user responses, the Web Service may not be a good way. However, although it has obvious defects, it is still possible to achieve interoperability.
image 3.
build connection
In-depth understanding of WSID
WSID is the main company of Tony Hong (XMethods.net), SIGS / 101 Conference and Web Services Technology, including Microsoft, IBM, Iona, Excelon (now is a Progress Software), Mind Electric, Amberpoint and WebMethods Together, it is used to study multi-developers to achieve Web Service compatibility. Its goal is to achieve a multi-developer commonly developed, cross-platform Web Service interoperability examples by using a simple but extraordinary, practical business background (Business Scenario). At present, most DEMO implementations are J2EE-based products, but because Microsoft is also one of the initiators of this Demo, .NET is also included.
WSID has been published at the Boston's Web Services One conference in August 2002, although the plan of its online version is still brewing (see resources). This example uses a simple Purchasing Network. The supplier provides a directory for the user, and the user submits a list of purchase. The supplier will first examine the current credit situation of the user and then send a shipping order to the agent store (see Figure 3). For several reasons, XMethod implements its important role in the Demo network by providing static XML files and web service interfaces: a list of all participants and their related terminals with Web Service and browser interfaces.
Mapping from Customer to Bank.
Keep WSDL files and list UDDI records for end users.
A online collection of all standard WSDL files that have all defined interfaces.
A logging service.
These interfaces are included in a separate document that you can find them from Xmethods Web Site (see resources). This great DEMO includes RPC-EnCoded combined with internal component communication (Inter-Component Communication) and Document-Litral combination instances. And a large number of participation in all platforms and the binding of these methods and coding. The success of Demo internal operation depends primarily on the operational accuracy and the relatively simple amount of WSDL Web Service operation definition. Moreover, all DEMO's behavior is done by a Logging Web Service, which is originally provided by the XMethods website.
When a part of the person begins to assemble the WSID, another informal organization consisting of approximately 15 Web Services suppliers will perform a set of ordinary test versions, and improve the interoperability level by using SOAPBUIlders. All developers have issued beta terminals to demonstrate their level of interoperability. Other suppliers can test their own implementation, use the published test terminal, and then complete the measurement of the interoperability level with other suppliers (see Resources).
SoapBuilder is discussed with other members to complete the assessment, completing customization and correction work and get a new beta. The purpose of each discussion is to improve the interaction level through some important methods, such as more data types and structures in the beta, or contain more content in the WSDL specification. The organization focuses on the elaboration of RPC coding in the SOAP specification by testing, using the RPC interactive interaction. As of the date of publication, SOAPBuilder has completed five discussions and got a large number of discussion results. Conclusions Prove that simply data types (such as integer and text types) are more easily interactable than complex data types (such as arrays and structures). The more complex the data type used, the less the number of developers of all tests. Most developers use the J2EE platform, so it is easy to find J2EE suppliers and find which data type and how much data types can be supported in the interoperability test. You can view the results of SOAPBUILDER to learn which data type and structure are available in the RPC mode.
Since the organization is not official, SOAPBUILDERS's charter is still negotiated. Some people think that since WS-I has released their original proposal (see resources), there is currently no SOAPBUILDERS. However, many developers still adhere to the RPC-based Web Services products, and the use of RPC simplifies the interoperability of the RPC middleware, such as .NET, J2EE, and CORBA. In many cases, SoapBuilder and WS-I are alternately used because their goals are to create a general Web Service specification that implements interoperability. According to Web Service Development Blueprint When Web Service Application matures and becomes mainstream products, you need to add some other features in existing Web Service standards. In order to achieve these needs, WS-I plans to release a structure blueprint (Architectural Road map, used to identify the functional area and the functions that need to be concerned in future Web Service specifications. Since many standard organizations continue to establish and adopt new specifications to enhance existing web service features, WS-i will continue to launch a forum that ensures test data supports existing requirements and internal independence.
We must emphasize the two main development platforms proposed by WS-I: C # (.NET) and Java (J2EE). That is to say that WS-I will probably be related to the interoperability of .NET and J2EE, which will be important because of the tools and strategies in WS-I, will certainly (at least) can be operated correctly These two large development platforms are above.
SOAPBuilder took approximately 1 year to test the interoperability of the RPC mode (debugging each RPC encoding). However, the Basic Profile Working Group (BPWG) of WS-i is difficult to use RPC encoding, which is difficult to achieve interoperability, especially when processing RPC encoding approved ordinary data types and data structures. It will be removed from the most recently proposed interoperability data (see Go Online Box). This means that WS-I recommends only uses the interoperability issue by facing document types. But this will return the problem to the app, and the Web Services can only be sent back to the Internet on the Internet. This is still unable to solve the interoperability problem.
The basic performance of the .NET and J2EE platforms is attributed to the demand for custom application development support for custom applications in the internal enterprise LAN (Corporate Lans) or other controlled companies. The initial scope of program development was assumed in a company. Products and Service built around .NET and J2EE are directly sold to various companies, they provide support for commercial applications for commercial business processing.
With a specific language and platform to support business data processing, users are limited to a language, product, or middleware structure, which determines how much earnings can be obtained, and competition related to this kind of income is a variety of The reason for the platform.
The Web Service standard is committed to solve the difference between .NET and J2EE by providing a universal XML message abstraction layer. However, the limitations of this specification itself and the limitations of interoperability implementation in their implementation.
The software industry is still continuing to argue, because a large number of commercial models of software companies are based on. They can't make changes in the current customer base without threat, or give up existing customers they rely on. That is to say, when you use Web Service in your business, they may add an abstraction layer that solves important issues. However, when you deal with the interoperability between .NET and J2EE, it is very important to understand its possibilities and limitations, which also applies to successful implementation of arguments (such as the chart provided by WSID) and a large number of WS-I. Suggest.
