Java Web Development Concept (4)--6. Web Frame __java

6. Web Framework

The Web frame layer is a clean floor. A lot of good programmers are doing well at this level and have made a lot of great work. I feel good about spring MVC, Web Work.

For Web applications, the Web framework layer is the most important layer. The effects of SOA, Semantic web, and so on are implemented at this level.

First, let's discuss the programming structure of the framework.

My blog has an article in the overview of the Java Web framework. Explains some of the popular web framework programming structures, many of which are not repeated.

Http://blog.csdn.net/buaawhl

Overview of Java Web framework

Http://blog.csdn.net/buaawhl/archive/2004/12/21/224069.aspx

The programming interface of Spring MVC is the clearest. In most simple cases, the use of WEB work is the most simple and effective, the programming structure is quite special, it can be said to have a certain meaning of change.

Spring MVC's Controller interface is the same as the struts Action, with the request, response two parameters, although the programming interface is very clear and elegant, but there is no change in nature.

WebWork's action loses controller's identity, which is equivalent to Formbean's identity, or Actionbean's identity. The WebWork action does not have a request, Response two parameters, it has only attributes, and gets the parameters of the HTTP request through the property setter, outputting the resulting data to the HTTP Response through the property getter.

It can be said that the webwork of this grasp is quite in place. Over 95% of the cases, the programmer is not required to request, response parameters. When these parameters are required, WebWork does not block the path, either by implementing interfaces such as Requestaware,responseaware, or through a thread local. In this case, the conventions of the programming structure are not so clear.

I have received a lot of inspiration from Canonical's posts and blogs.

Http://canonical.blogdriver.com

Jsplet: A Critique of Model 2 mode

Http://canonical.blogdriver.com/canonical/591479.html

A comparative study of the concept of Jsplet and WebWork

Http://canonical.blogdriver.com/canonical/594671.html

Looking at MVC architecture from the perspective of Level column theory

Http://canonical.blogdriver.com/canonical/579747.html

As you can see from Canonical's article. Jsplet use JSP files as dispatcher, and then register in the JSP and call the corresponding object. This process of searching for an object is entirely based on a rich URL definition. The URL includes object Scope, object name, method name, and method Parameters, which is inherently well supported by the event mechanism.

Some of Zope's practices are similar.

Zope Object Publishing

Http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx

Http://www.plope.com/Books/2_7Edition/ZopeArchitecture.stx#2-3

The idea of obtaining the service of published object by URL is an effective way to achieve SOA effect.

Let's first look at the status of Web service. At present, the Web service is divided into two major camps. Soap and Rest. For rest, see

Http://www.xfront.com/REST-Web-Services.html

There are a lot of articles on the internet about soap and rest comparisons and interoperability. If necessary, search for a lookup.

I personally prefer the rest-style web Service.

Because SOAP is a fixed protocol, if you write a Web service program with soap, you need a parsing library of the SOAP protocol, and perhaps some specialized "soap data-programming language" Mapping library, like the Multi-Language mappings of CORBA IDL. If you want your Web application to support SOAP, you need to wrap the published service objects and methods into the SOAP protocol, which requires a mapping of the data structures associated with the programming language.

Rest is just a style, not a protocol. The central idea is simply to get resources through rich URI definitions (such as XLink + XPointer, etc.). If you want your Web application to support REST, it's easy to just go up and down the URI, for example, add one more parameter format=rest, and add an extra XML output format to the program. (In a sense, soap can do the same, but soap input and output are subject to the SOAP protocol, and SOAP input parameters are generally wrapped in a SOAP envelope)

About HTTP GET and post, I'm expressing my opinion.

I think the essence of the web is getting, not post, to get the output of the server, not to enter the server. That is, the essence of the web is to small beats big, four to dial the heavy. The classic usage is to use a URL to get a lengthy text content that is filled with additional resource connections. This is also the original intention of hypertext connection HTML invention.

As for HTTP Post, this is an extension above. b/s structure is so popular, many applications will be transferred to the web, how to do, the application is always interactive, always let the user input data bar, added the HTTP POST protocol.

HTTP get classic, simple, and efficient. You can use the rich URI definition to maximize this advantage. The implementation is also simpler and more elegant. I don't have to say more. The main difficulty is in the HTTP Post. The following discussion deals primarily with the complex phenomenon of "HTTP Post".

HTTP Post never makes people happy. When the input logic is complex to a certain extent, the form data is complicated, messy, scattered, to the server side is difficult to organize. Input b/s structure and C/s structure is difficult to match. So, there are XMLHTTP, can be in the browser to organize parameters into a unified XML data structure (or other formats), sent to the server side, once resolved. Soap does this in a way that is more of a forte. Therefore, many XMLHTTP programs use soap directly as a communication protocol. The rest-style HTTP POST is not substantially different from the HTML Form post.

Rest is better at HTTP GET, and soap is better at HTTP POST. According to the characteristics of the Web application, according to the HTTP get/http Post page ratio, select the appropriate technology.

We will further analyze the data content of the HTTP post. The data for the HTTP post may contain three types:

(1) Need to archive the data in the server

For example, the user registers the time, the input basic information, the user name, the password, the email and so on. This information is to be stored in the server's database.

For this kind of basic information, HTTP Post,xmlhttp,soap is not very difficult to deal with, there is no big difference.

Business-to-business data exchange is also part of this category. What kind of technology does not make much difference. Soap is generally used, because soap is a popular standard protocol.

(2) Service invocation parameters

For example, when the user makes a compound condition query, enter the query criteria. At this point, HTTP post processing is very lame. And Xmlhttp,soap has a lot of advantages. Complex query conditions can be organized into XML data and sent to server-side unified processing. In soap, you can even define detailed invocation information such as object names, method names, and so on.

(3) Instruction

This situation is relatively rare. The "Object name, method name, and other detailed invocation information" mentioned in the above argument category are somewhat interleaved with this instruction category.

If the parameter in a SOAP invocation method is also a custom object, the property data of the custom object is defined in the SOAP message. After the server side, the service-side program first calls the constructor of the custom parameter, generates the Parameter object, and then invokes the corresponding service object and passes this parameter to the service. This process can be seen as a sequential instruction: [1] The constructor parameter [2] invokes the service.

This is just the simplest case. and the current Web service is generally supported to that extent.

My opinion is, Yibu, rather endlessly. Since all the call information is defined to this extent, it is better to do a more thorough, comprehensive and perfect support instructions. This instruction means logic. As I've said before, I'm not in favor of using XML tag to represent logic, but pro script. The more appropriate script here is JavaScript, because JavaScript is more generic, and the client and server side can interpret execution. Note that this is the opposite of what is generally the case: a typical Web application always uploads JavaScript from the server to the browser, where JavaScript is organized in a browser and sent to server-side processing; this javascript will execute on the server side, Invokes the object on the server side. Give an example of soap containing JavaScript directives (just schematic, non-standard format):

<soap envelope>

<xml data>

<a>

<b>12</b>

</a>

<c>

<d>21</d>

</c>

<e>

<e>16</e>

</e>

</xml data>

<script>

Final_result = default;

RESULT1 = Service1.service (A.B);

if (Result1.ok) {

RESULT2 = Service2.service (C.D);

if (Result2.ok)

Final_result = Service3.service (E.F);

}

</script>

</soap envelope >