The discussion of cross-origin problems in WebLogic12.1.1 and solutions to cross-origin problems in some common middleware, weblogic Middleware

The discussion of cross-origin problems in WebLogic12.1.1 and solutions to cross-origin problems in some common middleware, weblogic Middleware
1. Problem Description

The middleware WebLogic12.1.1 was installed at the site in Yangzhou. According to the company's previous solution to WebLogic12, we released a service with the virtual path/and the root directory file as root in the middleware.

The root file contains the following files:

 

When the program starts to initiate cross-origin access, the following problem occurs:

 

It can be seen that although we can access crossdomain. xml and get the complete content, the program cannot proceed, and the cross-origin access on the Flash end cannot be triggered.

2. Solution 2.1: whether the crossdomain. xml content is incorrect

Different Flash versions may have different crossdomain. xml requirements. After Flash9, the security mechanism has changed. If we use Flex3 to access the old version of crossdomain. xml, the security error may be returned. Some articles on the Internet say that the crossdomain. xml method after flash 9 is required for configuration of allow-http-request-headers-from. However, after my own tests, I found that even if I did not write this configuration, the cross-origin can still be successful under tomcat.

However, I asked the on-site engineers to replace Flash with a relatively new version, and crossdomain. xml also uses a new version. Finally, the cross-origin fails.

2.2 is there any problem with other configurations?

After searching for information on the Internet, we found that the web. xml configuration is also required. Check that the original configuration of this file is:

<? Xml version = "1.0" encoding = "UTF-8"?>

<! DOCTYPE web-app PUBLIC "-// Sun Microsystems, Inc. // DTD Web Application 2.3 //" http://java.sun.com/dtd/web-app_2_3.dtd ">

<Web-app id = "WebApp_1166189002905">

<Display-name> root </display-name>

<! -- Homepage file name -->

<Welcome-file-list>

<Welcome-file> index. jsp </welcome-file>

</Welcome-file-list>

</Web-app>

A mime-mapping configuration is missing from the suggested configuration on the Internet, so I added the following configuration in web. xml:

<Mime-mapping>

<Extension> xml </extension>

<Mime-type> application/xml </mime-type>

</Mime-mapping>

Re-release the root folder and find that the program can be cross-origin successfully at this time. Result:

 

3. How to add mime-mapping

We previously found that in WebLogic12.1.2, if this configuration is not added, cross-origin is successful, but not in 12.1.1. The reason may be that this configuration is not added in this version, webLogic cannot automatically identify XML files.

After this configuration is added, the cross-origin can also be normal in WebLogic12.1.2. We recommend that you use this compatible version of web. xml to configure WebLogic later.

4. Add 4.1 what is cross-origin?

Cross-origin is used to access files or resources of other domain names. For example, if your swf is for server A, and the swf has A request to access server B, when you access the content of server B, cross-origin is required on server B.

4.2 why cross-origin?

In fact, not only Flash, Javascript, and other scripts also have cross-domain issues. This is mainly determined by their own security mechanisms, because cross-domain access to some files or resources is risky, he has exceeded the scope of the website and cannot review its security for off-site resources. In today's increasingly rampant Network viruses and Trojans, cross-domain access restriction is an important solution to his security policy.

5 Summary of cross-origin file placement addresses of other middleware 5.1 tomcat

The crossdomain. xml in tomcat is easy to put at: apache-tomcat \ webapps \ ROOT.

5.2 Kingdee 7.0

Its placement address is: Apusic-AS-7.0 \ domains \ mydomain \ applications \ default \ public_html.

5.3weblogic9.2

The placement address is .. \ user_projects \ applications \ domain1 \ server \ examples \ build \ mainWebApp.

5.4 cross-origin middleware related to ArcGIS

Cross-origin problems are also common in Arcgis Server. There are two cases.

If the. net version is installed, place the crossdomain. xml file under the published IIS. The general path is C:/Inetpub/wwwroot.

If the Java version is installed, for arcgis9.3, the address is {arcgis installation directory}/ArcGIS/java/web_output.

For arcgis10.0, the address is {arcgis installation directory} \ ArcGIS \ Server10.0 \ java \ manager \ web_output.

For arcgis10.1 and 10.2, I have observed that they will install the crossdomain. xml file during installation. The address is {ArcGIS Server Installation Directory} \ ArcGIS \ Server \ framework \ runtime \ tomcat \ webapps \ ROOT.

Middleware problems (30 decomposition)

I have just found this article to explain some of the problems.
That is to say, the problem in 3 should not be a real middleware, but what is it? That's hard to say.

Middleware
From ITwiki, an open Encyclopedia of Information Technology
Jump to: navigation, <jumptoSearch>
MiddleWare (MiddleWare) is a common service located between the Platform (hardware and operating system) and applications. These services have standard program interfaces and protocols. For different operating systems and hardware platforms, they can have multiple implementations that comply with the interface and protocol specifications. The middleware concept is proposed to solve the problem of distributed heterogeneity.

Computer technology is developing rapidly. From the perspective of hardware technology, the CPU speed is getting higher and higher, and the processing capability is getting stronger. From the perspective of software technology, the scale of applications is constantly expanding, especially the emergence of Internet and WWW, this gives computers a wider range of applications. Many applications need to run on heterogeneous platforms in the network environment. All of this poses new requirements for the next generation of software development. In such a distributed heterogeneous environment, there are usually a variety of hardware system platforms (such as PCs, workstations, minicomputers, etc ), there are a variety of system software (such as different operating systems, databases, language compilers, etc.) on these hardware platforms, as well as a variety of user interfaces with different styles, these hardware system platforms may also use different network protocols and network architecture connections. It is very realistic and difficult to integrate these systems and develop new applications.

[Edit] middleware should have the following features:
It meets the needs of a large number of applications and runs on a variety of hardware and OS platforms to support distributed computing, provides transparent interaction between applications or services across networks, hardware, and OS platforms. standard protocols support standard interfaces.

Due to the importance of standard interfaces for portability and standard protocols for interoperability, middleware has become a major part of many standardization work. For application software development, middleware is far more important than operating systems and network services. The program interfaces provided by middleware define a relatively stable high-level application environment, no matter how the underlying computer hardware and system software are upgraded, as long as the middleware is upgraded and the interface definition of the middleware is kept unchanged, the application software does not need to be modified, this protects significant investments in application software development and maintenance.

Classification of main Middleware

Middleware has a wide range of features, and a variety of distinctive middleware Products have emerged for different application requirements. So far, no precise definition of middleware is provided. Therefore, the classification of middleware varies from different angles or layers. Because middleware needs to shield heterogeneous operating systems and network protocols in the distributed environment, it must be able to provide communication services in the distributed environment. We call this communication service a platform. Based on different purposes and implementation mechanisms, we divide the platform into the following main categories:

Remote Procedure Call Message-Oriented Middleware (Message-Oriented Middleware) Object Request proxy (Object Request Brokers)

They can provide different forms of communication services, including synchronization, queuing, subscription and publishing, and broadcasting. On these basic communication platforms, they can build various frameworks, provides services in different fields for applications, such as transaction processing monitor, distributed data access, and Object Transaction Manager OTM. The Platform shields the differences between heterogeneous platforms for upper-layer applications, and its framework defines the system structure and standard service components of applications in the corresponding fields, you only need to tell the framework about the events and then provide the code to handle these events. When an event occurs, the Framework calls your code. User code does not need to call the framework, and user programs do not need to care about the framework structure, execution process, and system-level API calls. All these are done by the framework. Therefore, applications developed based on middleware have good scalability, manageability, high availability, and portability.
References:... the remaining full text>

Comparison of several web development technologies weblogic and tomcat all support Middleware

Java programs are middleware. Middleware = Platform + service can be considered as a framework. Tomcat and weblogic are based on the excellent java program framework and can provide Web Services. Forgive me for not understanding what the landlord meant.