lqxue

struts防止重復提交

posted @ 2008-06-03 13:47 lqx 閱讀(350) | 評論 (0) | 編輯 收藏

[收藏]How to pass SOAP Attachments with JAX-RPC Web Service

posted @ 2008-05-29 10:16 lqx 閱讀(210) | 評論 (0) | 編輯 收藏

[收藏]Which style of WSDL should I use?

From:http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

A Web Services Description Language (WSDL) binding style can be RPC or document. The use can be encoded or literal. How do you determine which combination of style and use to use? The author describes the WSDL and SOAP messages for each combination to help you decide.

Introduction

A WSDL document describes a Web service. A WSDL binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This gives you four style/use models:

1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal

Add to this collection a pattern which is commonly called the document/literal wrapped pattern and you have five binding styles to choose from when creating a WSDL file. Which one should you choose?

Before I go any further, let me clear up some confusion that many of us have stumbled over. The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

Likewise, the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping, though, at least here, the traditional meanings of the words make a bit more sense.

For this discussion, let's start with the Java method in Listing 1 and apply the JAX-RPC Java-to-WSDL rules to it (see Resources for the JAX-RPC 1.1 specification).

public void myMethod(int x, float y);

Back to top

RPC/encoded

Take the method in Listing 1 and run it through your favorite Java-to-WSDL tool, specifying that you want it to generate RPC/encoded WSDL. You should end up with something like the WSDL snippet in Listing 2.

<message name="myMethodRequest">
            <part name="x" type="xsd:int"/>
            <part name="y" type="xsd:float"/>
            </message>
            <message name="empty"/>
            <portType name="PT">
            <operation name="myMethod">
            <input message="myMethodRequest"/>
            <output message="empty"/>
            </operation>
            </portType>
            <binding .../>
            <!-- I won't bother with the details, just assume it's RPC/encoded. -->

Now invoke this method with "5" as the value for parameter x and "5.0" for parameter y. That sends a SOAP message which looks something like Listing 3.

<soap:envelope>
            <soap:body>
            <myMethod>
            <x xsi:type="xsd:int">5</x>
            <y xsi:type="xsd:float">5.0</y>
            </myMethod>
            </soap:body>
            </soap:envelope>

A note about prefixes and namespaces For the most part, for brevity, I ignore namespaces and prefixes in the listings in this article. I do use a few prefixes that you can assume are defined with the following namespaces: xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" For a discussion about namespaces and the WSDL-to-SOAP mapping, see paper "Handle namespaces in SOAP messages you create by hand" (see Resources).

There are a number of things to notice about the WSDL and SOAP message for this RPC/encoded example:

Strengths

• The WSDL is about as straightforward as it's possible for WSDL to be.
• The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

Weaknesses

WS-I compliance The various Web services specifications are sometimes inconsistent and unclear. The WS-I organization was formed to clear up the issues with the specs. It has defined a number of profiles which dictate how you should write your Web services to be interoperable. For more information on WS-I, see the WS-I links in Resources.

• The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance.
• You cannot easily validate this message since only the <x ...>5</x> and <y ...>5.0</y> lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions.
• Although it is legal WSDL, RPC/encoded is not WS-I compliant.

Is there a way to keep the strengths and remove the weaknesses? Possibly. Let's look at the RPC/literal style.

Back to top

RPC/literal

The RPC/literal WSDL for this method looks almost the same as the RPC/encoded WSDL (see Listing 4). The use in the binding is changed from encoded to literal. That's it.

<message name="myMethodRequest">
            <part name="x" type="xsd:int"/>
            <part name="y" type="xsd:float"/%gt;
            </message>
            <message name="empty"/>
            <portType name="PT">
            <operation name="myMethod">
            <input message="myMethodRequest"/>
            <output message="empty"/>
            </operation>
            </portType>
            <binding .../>
            <!-- I won't bother with the details, just assume it's RPC/literal. -->

What about the SOAP message for RPC/literal (see Listing 5)? Here there is a bit more of a change. The type encodings have been removed.

<soap:envelope>
            <soap:body>
            <myMethod>
            <x>5</x>
            <y>5.0</y>
            </myMethod>
            </soap:body>
            </soap:envelope>

A note about xsi:type and literal use Although in normal circumstances xsi:type does not appear in a literal WSDL's SOAP message, there are still cases when type information is necessary and it will appear -- in polymorphism, for instance. If the API expects a base type and an extension instance is sent, the type of that instance must be provided for proper deserialization of the object.

Here are the strengths and weaknesses of this approach:

Strengths

• The WSDL is still about as straightforward as it is possible for WSDL to be.
• The operation name still appears in the message.
• The type encoding info is eliminated.
• RPC/literal is WS-I compliant.

Weaknesses

• You still cannot easily validate this message since only the <x ...>5</x> and <y ...>5.0</y> lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions.

What about the document styles? Do they help overcome this weakness?

Back to top

Document/encoded

Nobody follows this style. It is not WS-I compliant. So let's move on.

Back to top

Document/literal

The WSDL for document/literal changes somewhat from the WSDL for RPC/literal. The differences are highlighted in bold in Listing 6.

				<types>
            <schema>
            <element name="xElement" type="xsd:int"/>
            <element name="yElement" type="xsd:float"/>
            </schema>
            </types>
            <message name="myMethodRequest">
            <part name="x" element="xElement"/>
            <part name="y" element="yElement"/>
            </message>
            <message name="empty"/>
            <portType name="PT">
            <operation name="myMethod">
            <input message="myMethodRequest"/>
            <output message="empty"/>
            </operation>
            </portType>
            <binding .../>
            <!-- I won't bother with the details, just assume it's document/literal. -->

The SOAP message for this WSDL is in Listing 7:

<soap:envelope>
            <soap:body>
            <xElement>5</xElement>
            <yElement>5.0</yElement>
            </soap:body>
            </soap:envelope>

A note about the message part I could have changed only the binding, as I did from RPC/encoded to RPC/literal. It would have been legal WSDL. However, the WS-I Basic Profile dictates that document/literal message parts refer to elements rather than types, so I'm complying with WS-I. (And using an element part here leads well into the discussion about the document/literal wrapped pattern.)

Here are the strengths and weaknesses of this approach:

Strengths

• There is no type encoding info.
• You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
• Document/literal is WS-I compliant, but with restrictions (see weaknesses).

Weaknesses

• The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans.
• The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
• WS-I only allows one child of the soap:body in a SOAP message. As you can see in Listing 7, this example's soap:body has two children.

The document/literal style seems to have merely rearranged the strengths and weaknesses from the RPC/literal model. You can validate the message, but you lose the operation name. Is there anything you can do to improve upon this? Yes. It's called the document/literal wrapped pattern.

Back to top

Document/literal wrapped

Before I describe the rules for the document/literal wrapped pattern, let me show you the WSDL and the SOAP message in Listing 8 and Listing 9.

<types>
            <schema>
            <element name="myMethod">
            <complexType>
            <sequence>
            <element name="x" type="xsd:int"/>
            <element name="y" type="xsd:float"/>
            </sequence>
            </complexType>
            </element>
            <element name="myMethodResponse">
            <complexType/>
            </element>
            </schema>
            </types>
            <message name="myMethodRequest">
            <part name="parameters" element="myMethod"/>
            </message>
            <message name="empty">
            <part name="parameters" element="myMethodResponse"/>
            </message>
            <portType name="PT">
            <operation name="myMethod">
            <input message="myMethodRequest"/>
            <output message="empty"/>
            </operation>
            </portType>
            <binding .../>
            <!-- I won't bother with the details, just assume it's document/literal. -->

The WSDL schema now has a wrapper around the parameters (see Listing 9).

<soap:envelope>
            <soap:body>
            <myMethod>
            <x>5</x>
            <y>5.0</y>
            </myMethod>
            </soap:body>
            </soap:envelope>

Notice that this SOAP message looks remarkably like the RPC/literal SOAP message in Listing 5. You might say it looks exactly like the RPC/literal SOAP message, but there's a subtle difference. In the RPC/literal SOAP message, the <myMethod> child of <soap:body> was the name of the operation. In the document/literal wrapped SOAP message, the <myMethod> clause is the name of the wrapper element which the single input message's part refers to. It just so happens that one of the characteristics of the wrapped pattern is that the name of the input element is the same as the name of the operation. This pattern is a sly way of putting the operation name back into the SOAP message.

These are the basic characteristics of the document/literal wrapped pattern:

• The input message has a single part.
• The part is an element.
• The element has the same name as the operation.
• The element's complex type has no attributes.

Here are the strengths and weaknesses of this approach:

Strengths

• There is no type encoding info.
• Everything that appears in the soap:body is defined by the schema, so you can easily validate this message.
• Once again, you have the method name in the SOAP message.
• Document/literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction that the SOAP message's soap:body has only one child.

Weaknesses

• The WSDL is even more complicated.

As you can see, there is still a weakness with the document/literal wrapped pattern, but it's minor and far outweighed by the strengths.

RPC/literal wrapped? From a WSDL point of view, there's no reason the wrapped pattern is tied only to document/literal bindings. It could just as easily be applied to an RPC/literal binding. But this would be rather silly. The SOAP message would contain a myMethod element for the operation and a child myMethod element for the element name. Also, even though it's legal WSDL, an RPC/literal part should be a type; an element part is not WS-I compliant.

Where is doc/lit wrapped defined?

This wrapped style originates from Microsoft®. There is no specification that defines this style; so while this style is a good thing, unfortunately, the only choice right now, in order to interoperate with Microsoft's and other's implementations, is to make educated guesses as to how it works based on the output of the Microsoft WSDL generator. This pattern has been around for awhile, and the industry has done a good job of understanding it, but while the pattern is fairly obvious in this example, there are corner cases in which the proper thing to do is not particularly clear. Our best hope is that an independent group like the WS-I organization will help stabilize and standardize this in the future.

Back to top

Why not use document/literal wrapped all the time?

So far, this article has given the impression that the document/literal wrapped style is the best approach. Very often that's true. But there are still cases where you'd be better off using another style.

Reasons to use document/literal non-wrapped

If you have overloaded operations, you cannot use the document/literal wrapped style.

Imagine that, along with the method you've been using all along, you have the additional method in Listing 10.

public void myMethod(int x, float y);
            public void myMethod(int x);
            

A note about overloaded operations WSDL 2.0 will not allow overloaded operations. This is unfortunate for languages like the Java language which do allow them. Specs like JAX-RPC will have to define a name mangling scheme to map overloaded methods to WSDL. WSDL 2.0 merely moves the problem from the WSDL-to-SOAP mapping to the WSDL-to-language mapping.

WSDL allows overloaded operations. But when you add the wrapped pattern to WSDL, you require an element to have the same name as the operation, and you cannot have two elements with the same name in XML. So you must use the document/literal, non-wrapped style or one of the RPC styles.

Reasons to use RPC/literal

Since the document/literal, non-wrapped style doesn't provide the operation name, there are cases where you'll need to use one of the RPC styles. For instance, say you have the set of methods in Listing 11.

public void myMethod(int x, float y);
            public void myMethod(int x);
            public void someOtherMethod(int x, float y);
            

Now assume that your server receives the document/literal SOAP message that you saw back in Listing 7. Which method should the server dispatch to? All you know for sure is that it's not myMethod(int x) because the message has two parameters and this method requires one. It could be either of the other two methods. With the document/literal style, you have no way to know which one.

Instead of the document/literal message, assume that the server receives an RPC/literal message such as the one in Listing 5. With this message it's fairly easy for a server to decide which method to dispatch to. You know the operation name is myMethod, and you know you have two parameters, so it must be myMethod(int x, float y).

Reasons to use RPC/encoded

The primary reason to prefer the RPC/encoded style is for data graphs. Imagine that you have a binary tree whose nodes are defined in Listing 12.

<complexType name="Node">
            <sequence>
            <element name="name" type="xsd:string"/>
            <element name="left" type="Node" xsd:nillable="true"/>
            <element name="right" type="Node" xsd:nillable="true"/>
            </sequence>
            </complexType>

With this node definition, you could construct a tree whose root node -- A -- points to node B through both its left and right links (see Figure 1).

The standard way to send data graphs is to use the href tag, which is part of the RPC/encoded style (Listing 13).

<A>
            <name>A</name>
            <left href="12345"/>
            <right href="12345"/>
            </A>
            <B id="12345">
            <name>B</name>
            <left xsi:nil="true"/>
            <right xsi:nil="true"/>
            </B>

Under any literal style, the href attribute is not available, so the graph linkage is lost (see Listing 14 and Figure 2). You still have a root node, A, which points to a node B to the left and another node B to the right. These B nodes are equal, but they are not the same node. Data have been duplicated instead of being referenced twice.

<A>
            <name>A</name>
            <left>
            <name>B</name>
            <left xsi:nil="true"/>
            <right xsi:nil="true"/>
            </left>
            <right>
            <name>B</name>
            <left xsi:nil="true"/>
            <right xsi:nil="true"/>
            </right>
            </A>

There are various ways you can do graphs in literal styles, but there are no standard ways; so anything you might do would probably not interoperate with the service on the other end of the wire.

Back to top

SOAP response messages

So far I have been discussing request messages. But what about response messages? What do they look like? By now it should be clear to you what the response message looks like for a document/literal message. The contents of the soap:body are fully defined by a schema, so all you have to do is look at the schema to know what the response message looks like. For instance, see Listing 15 for the response for the WSDL in Listing 8.

<soap:envelope>
            <soap:body>
            <myMethodResponse/>
            </soap:body>
            </soap:envelope>

But what is the child of the soap:body for the RPC style responses? The WSDL 1.1 specification is not clear. But WS-I comes to the rescue. WS-I's Basic Profile dictates that in the RPC/literal response message, the name of the child of soap:body is "... the corresponding wsdl:operation name suffixed with the string 'Response'." Surprise! That's exactly what the conventional wrapped pattern's response element is called. So Listing 15 applies to the RPC/literal message as well as the document/literal wrapped message. (Since RPC/encoded is not WS-I compliant, the WS-I Basic Profile doesn't mention what an RPC/encoded response looks like, but you can assume the same convention applies here that applies everywhere else.) So the contents of response messages are not so mysterious after all.

Back to top

Summary

There are four binding styles (there are really five, but document/encoded is meaningless). While each style has its place, under most situations the best style is document/literal wrapped.

Resources

• Be prepared for those times when you have to create your SOAP message by hand and deal with namespace issues without the help of a tool by reading (developerWorks, May 2005).
  
  
• Read the Web Services Description Language (WSDL) 1.1, the specification of WSDL.
  
  
• For a preview of where WSDL is going, read the WSDL 2.0 draft specifications.
  
  
• Try the SOAP 1.2 Primer, an introduction to the SOAP 1.2 specification.
  
  
• Java API for XML-Based RPC (JAX-RPC) Downloads & Specifications provides links to the JAX-RPC 1.1 specification itself, as well as javadocs, class files, and Sun's JAX-RPC reference implementation.
  
  
• Browse the WS-I (Web Services Interoperability) organization's Web pages.
  
  
• Read the WS-I's profiles. Particularly relevant is the basic profile.
  
  
• Browse for books on these and other technical topics.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  

About the author

		Russell Butek is an SOA and Web services consultant for IBM. He has been one of the developers of IBM WebSphere Web services engine. He has also been a member the JAX-RPC Java Specification Request (JSR) expert group. He was involved in the implementation of Apache's AXIS SOAP engine, driving AXIS 1.0 to comply with JAX-RPC 1.0.

posted @ 2008-05-27 17:19 lqx 閱讀(279) | 評論 (0) | 編輯 收藏

[收藏]Axis中WSDL描述文件的詳細介紹Axis中WSDL描述文件的詳細介紹

     <deployment>：告訴Axis Engine這是一個部署描述文件。一個部署描述文件可以表示一個完整的engine配置或者將要部署到一個活動active的一部分組件。

     <GlobalConfiguration>：用于控制engine范圍的配置?？梢园韵伦釉兀?/span>

·            <parameter> : 用來設置Axis的各種屬性，參考Global Axis Configuration，可以配置任意數量的參數元素.

·            <role> : 設置一個SOAP actor/role URI，engine可以對它進行識別。這允許指向這個role的SOAP headers成功的被engine處理。任意數量.

·            <requestFlow> : 全局的請求Handlers。在調用實際的服務之前調用.

·            <responseFlow> : 全局響應Handlers，在調用完實際的服務后，還沒有返回到客戶端之前調用. 

         <requestFlow [name="name"] [type="type"] >可以放置任意多個<handler> or <chain>在<requestFlow>中，但是可能只有一個<requestFlow>. 

         <responseFlow [name="name"] [type="type"] >可以放置任意多個<handler> or <chain>在< responseFlow >中，但是可能只有一個< responseFlow >. 

         <undeployment>部署文檔的根元素，用于指示Axis這是個卸載描述文件.

     <handler [name="name"] type="type">位于頂層元素<deployment> or <undeployment>, or inside a <chain>, <requestFlow>, or <responseFlow>. 用于定義Handler，并定義handler的類型。"Type" 可以是已經定義的Handler或者是"java:class.name"形式的QName?？蛇x的"name"屬性允許將這個Handler的定義在其他部署描述部分中引用?？梢园我鈹盗康?/span><parameter name="name" value="value">元素. 

     <service name="name" provider="provider" >部署/卸載一個Axis服務。這是最復雜的一個WSDD標簽。Options可能通過以下元素來指定: <parameter name="name" value="value"/>, 一些常用的包括:·   className : 后臺實現的類 allowedMethods : 每個provider可以決定那些方法允許web services訪問

 Axis支持的providers有如下幾種:

   Java RPC Provider (provider="java:RPC") 默認情況下所有的public方法都可以web service方式提供Java MsgProvder (provider="java:MSG") 為了更進一步的限制上面的方法，allowedMethods選項用于指定一個以空格分隔的方法名，只有這些方法可以通過web service訪問。也可以將這個值指定為”*”表示所有的方法都可以訪問。同時operation元素用來更進一步的定義被提供的方法，但是它不能決定方法的可見性. 注意，發布任何web service都有安全含義.

·        allowedRoles : 都好分離的允許訪問服務的角色列表。注意，這些是安全角色，和SOAP角色相反。安全角色控制訪問，SOAP角色控制哪些SOAPheaders會被處理。

·        extraClasses : 指定一個空格或者都好分離的類名稱列表，這些類的名字應該被包含在WSDL文檔的類型定義部分。當服務接口引用一個基類的時候，或者希望WSDL文件包含其他類的XML Schema類型定義的時候，這個參數很有用。

    如果希望為服務定義handler，可以在<service>元素中添加<requestFlow>和<responseFlow>子元素。他們的語義和<chain>元素中的定義時一樣的。也就是說，它們可以包含<handler> and <chain> 元素，根據指定的順序被調用.

通過服務的Handlers來控制角色，可以在服務聲明中指定任意數量的<role>元素。

例如:

    可以通過使用<operation>標簽指定關于服務的特殊操作的元數據。這可以將方法的java參數名和特定的XML名進行映射，為參數指定特定的模式，并將特定的XML名字映射到特定的操作。例如

<operation name="method"> </operation>  

<chain name="name"><subelement/>...</chain>

     定義一個鏈。當chain被調用的時候，按順序調用其中的handler。這樣就可以構建一個常用功能的模塊，chain元素的子元素可以是handler或者chain。handler的定義形式可以是如下兩種方式:

     定義了一個服務器端的傳輸。當一個輸入請求到達的時候，服務器傳輸被調用。服務器傳輸可能定義<requestFlow> and/or <responseFlow> 元素來指定handlers/chains，在請求和響應被處理的時候被調用，這個功能和service元素中的功能一樣。典型的傳輸請求響應handler實現了關于傳輸的功能。例如轉換協議headers等等. 

     對于任何種類的傳輸，經常是指HTTP傳輸，當特定的查詢字符串傳遞到servlet的時候用戶可能允許Axis servlets執行任意的動作，以plug-in的方式。 (參考Axis Servlet Query String Plug-ins).當查詢字符串handler的類名被指導后，用戶可以通過在<transport>中添加合適的<parameter>來啟用它(插件)。

     在上面的例子中，AxisServlet會處理的查詢字符串是?name，它調用的類是class.name。

   <parameter>元素的name屬性必須加上前綴qs來表示這個元素定義了一個查詢字符串handler。value屬性值相實現了org.apache.axis.transport.http.QSHandler 接口的類。默認情況下，Axis提供了三個Axis servlet查詢字符串handlers (?list, ?method, and ?wsdl). 查看Axis服務器配置文件來了解它們的定義。如果不希望使用默認的handlers，就設置"useDefaultQueryStrings" 為false。默認會被設置成true.

       <transport name="name" pivot="handler type" >

     定義了一個客戶端的傳輸，當發送SOAP消息的時候來調用。"pivot"屬性指定一個Handler來作為實際的傳輸sender，例如HTTPSender。請求和響應流和服務器端的設置相同. <typeMapping qname="ns:localName" classname="classname" serializer="classname" deserializer="classname"/> 每個typeMapping將一個XML qualified名字和一個Java類進行映射，使用一個序列器和反序列器。 

<beanMapping qname="ns:localName" classname="classname">講話的類型映射，使用一個預定義的序列器/反序列器來編碼/解碼JavaBeans。 

      <documentation>在<service>, <operation> 或者操作的<parameter>中使用。.是文檔說明，生成wsdl的<wsdl:document>元素.

全局的Axis配置參數

服務默認的是通過server-config.wsdd文件中的值來進行配置的。但是熟練的Axis用戶可以寫自己的配置handler，這樣就可以將配置數據保存在LDAP服務器，數據庫或者遠程的web service等等。查看源代碼來了解如何實現。也可以在web.xml文件中使自動的獲取配置信息。但是Axis不推薦這樣使用，因為最好將配置信息放在一個位置。

在server-config文件中，有一個全局配置部分，支持以名/值對的形式作為嵌套元素使用。

單獨的Service(服務)配置

單獨的Operation(操作)配置

    由于Service的配置和Operation的配置很容易理解，各個參數也都使用了self-explanation的表示，所以這里就不再贅述了。

同時Axis還定義日志配置以及一些預定義的Handler，詳細內容，參考Axis的參考文檔。

posted @ 2008-05-27 17:18 lqx 閱讀(1044) | 評論 (0) | 編輯 收藏

Web Services和其他的技術的比較

posted @ 2008-05-27 10:25 lqx 閱讀(239) | 評論 (0) | 編輯 收藏

java的call基于document/literal的webservice

posted @ 2008-05-26 11:09 lqx 閱讀(1543) | 評論 (1) | 編輯 收藏

[收藏]XML Namespace、elementFormDefault、請問Schema中elementFormDefault="qualified"是起什么作用呀？

一個schema中聲明的元素或者類型只能歸到兩個命名空間中的某一個去，這兩個是，無名命名空間和由targetSchema屬性指明的目標命名空間。而targetSchema屬性只能在xs：schema的定義中聲明，因而，一個schema中的定義的元素或類型只可能歸屬于一個有名命名空間（但是還有可能歸屬于無名命名空間）。

當elementFormDefault="qualified" 時，所有全局元素的子元素將被以缺省方式放到目標命名空間，連同全局元素或者類型將被放到目標命名空間；而當elementFormDefault="unqualified" 時，所有全局元素的子元素將被以缺省方式放到無名命名空間。而屬性的命名空間類似地由attributeFormDefault="？"來指明。

需要明白的是，elementFormDefault="？" 是有作用域的，并且是被繼承的，除非在子定義中覆蓋父定義。

下面三個例子說明了elementFormDefault的使用效果。紅色表示屬于已命名空間的元素，藍色表示屬于未命名空間的元素。

1.定義了目標命名空間， 全局elementFormDefault=“unqualified”。這時除了全局元素或者類型將歸于目標命名空間外，局部元素將歸于無名命名空間。

unqualified.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="aaaa" elementFormDefault="unqualified" attributeFormDefault="unqualified">
 <xs:element name="c">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="c1" type="xs:double"/>
    <xs:element name="c2" type="xs:string"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema>

unqualified.xml

<?xml version="1.0" encoding="UTF-8"?>
<n:c xmlns:n="aaaa" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="aaaa unqualified.xsd">
 <c1>3.141593E0</c1>
 <c2>String</c2>
</n:c>

2. 定義了目標命名空間， 全局elementFormDefault=“qualified”。這時全局元素或者類型將歸于目標命名空間，局部元素將以缺省方式歸于目標命名空間。

qualified.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="aaaa" elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="c">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="c1" type="xs:double"/>
    <xs:element name="c2" type="xs:string"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema>

qualified.xml

<?xml version="1.0" encoding="UTF-8"?>
<c xmlns="aaaa" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="aaaa qualified.xsd">
 <c1>3.141593E0</c1>
 <c2>String</c2>
</c>

3. 定義了目標命名空間， 全局elementFormDefault=“unqualified”。這時全局元素（c）或者類型將歸于目標命名空間。局部元素（c1，c2）以缺省方式歸于無名命名空間。局部元素（c3）在局部定義中使用form=“qualified”覆蓋全局設定的 unqualified，這使得c3歸于目標命名空間（如果它有子元素，子元素將以缺省方式歸于目標命名空間）。

qualified2.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="aaaa" elementFormDefault="unqualified" attributeFormDefault="unqualified">
 <xs:element name="c">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="c1" type="xs:double"/>
    <xs:element name="c2" type="xs:string"/>
    <xs:element name="c3" type="xs:integer" form="qualified"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema>

qualified2.xml

<?xml version="1.0" encoding="UTF-8"?>
<n:c xmlns:n="aaaa" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="aaaa qualified2.xsd">
 <c1>3.141593E0</c1>
 <c2>String</c2>
 <n:c3>0</n:c3>
</n:c>

posted @ 2008-05-23 17:52 lqx 閱讀(840) | 評論 (0) | 編輯 收藏

[收藏]MySQLInnoDB存儲引擎的事務隔離級別

[收藏]sql 語句的執行過程

第1章 SQL語句處理的過程　　在調整之前我們需要了解一些背景知識，只有知道這些背景知識，我們才能更好的去調整sql語句。
本節介紹了SQL語句處理的基本過程，主要包括：
　　· 查詢語句處理
　　· DML語句處理(insert, update, delete)
　　· DDL 語句處理(create .. , drop .. , alter .. , )
　　· 事務控制(commit, rollback)

　　SQL 語句的執行過程(SQL Statement Execution)

　　 圖3-1 概要的列出了處理和運行一個sql語句的需要各個重要階段。在某些情況下，Oracle運行sql的過程可能與下面列出的各個階段的順序有所不同。如DEFINE階段可能在FETCH階段之前，這主要依賴你如何書寫代碼。

　　對許多oracle的工具來說，其中某些階段會自動執行。絕大多數用戶不需要關心各個階段的細節問題，然而，知道執行的各個階段還是有必要的，這會幫助你寫出更高效的SQL語句來，而且還可以讓你猜測出性能差的SQL語句主要是由于哪一個階段造成的，然后我們針對這個具體的階段，找出解決的辦法。

　　圖 3-1 SQL語句處理的各個階段

　　DML語句的處理

　　本節給出一個例子來說明在DML語句處理的各個階段到底發生了什么事情。假設你使用Pro*C程序來為指定部門的所有職員增加工資。程序已經連到正確的用戶，你可以在你的程序中嵌入如下的SQL語句：
EXEC SQL UPDATE employees
SET salary = 1.10 * salary WHERE department_id = :var_department_id; var_department_id是程序變量，里面包含部門號，我們要修改該部門的職員的工資。當這個SQL語句執行時，使用該變量的值。

　　每種類型的語句都需要如下階段：
　　· 第1步: Create a Cursor 創建游標
　　· 第2步: Parse the Statement 分析語句
　　· 第5步: Bind Any Variables 綁定變量
　　· 第7步: Run the Statement 運行語句
　　· 第9步: Close the Cursor 關閉游標

　　如果使用了并行功能，還會包含下面這個階段：
　　· 第6步: Parallelize the Statement 并行執行語句

　　如果是查詢語句，則需要以下幾個額外的步驟，如圖 3所示：
　　· 第3步: Describe Results of a Query 描述查詢的結果集
　　· 第4步: Define Output of a Query 定義查詢的輸出數據
　　· 第8步: Fetch Rows of a Query 取查詢出來的行

　　下面具體說一下每一步中都發生了什么事情：.

　　第1步: 創建游標(Create a Cursor)

由程序接口調用創建一個游標（cursor）。任何SQL語句都會創建它，特別在運行DML語句時，都是自動創建游標的，不需要開發人員干預。多數應用中，游標的創建是自動的。然而，在預編譯程序(pro*c)中游標的創建，可能是隱含的，也可能顯式的創建。在存儲過程中也是這樣的。

　　第2步:分析語句(Parse the Statement)

　　在語法分析期間，SQL語句從用戶進程傳送到Oracle，SQL語句經語法分析后，SQL語句本身與分析的信息都被裝入到共享SQL區。在該階段中，可以解決許多類型的錯誤。

　　語法分析分別執行下列操作：
l 翻譯SQL語句，驗證它是合法的語句，即書寫正確
l 實現數據字典的查找，以驗證是否符合表和列的定義
l 在所要求的對象上獲取語法分析鎖，使得在語句的語法分析過程中不改變這些對象的定義
l 驗證為存取所涉及的模式對象所需的權限是否滿足
l 決定此語句最佳的執行計劃
l 將它裝入共享SQL區
l 對分布的語句來說，把語句的全部或部分路由到包含所涉及數據的遠程節點

　　以上任何一步出現錯誤，都將導致語句報錯，中止執行。

　　只有在共享池中不存在等價SQL語句的情況下，才對SQL語句作語法分析。在這種情況下，數據庫內核重新為該語句分配新的共享SQL區，并對語句進行語法分析。進行語法分析需要耗費較多的資源，所以要盡量避免進行語法分析，這是優化的技巧之一。

　　語法分析階段包含了不管此語句將執行多少次，而只需分析一次的處理要求。Oracle只對每個SQL語句翻譯一次，在以后再次執行該語句時，只要該語句還在共享SQL區中，就可以避免對該語句重新進行語法分析，也就是此時可以直接使用其對應的執行計劃對數據進行存取。這主要是通過綁定變量(bind variable)實現的，也就是我們常說的共享SQL，后面會給出共享SQL的概念。

　　雖然語法分析驗證了SQL語句的正確性，但語法分析只能識別在SQL語句執行之前所能發現的錯誤(如書寫錯誤、權限不足等)。因此，有些錯誤通過語法分析是抓不到的。例如，在數據轉換中的錯誤或在數據中的錯（如企圖在主鍵中插入重復的值）以及死鎖等均是只有在語句執行階段期間才能遇到和報告的錯誤或情況。

　　查詢語句的處理

　　查詢與其它類型的SQL語句不同，因為在成功執行后作為結果將返回數據。其它語句只是簡單地返回成功或失敗，而查詢則能返回一行或許多行數據。查詢的結果均采用表格形式，結果行被一次一行或者批量地被檢索出來。從這里我們可以得知批量的fetch數據可以降低網絡開銷，所以批量的fetch也是優化的技巧之一。

有些問題只與查詢處理相關，查詢不僅僅指SELECT語句，同樣也包括在其它SQL語句中的隱含查詢。例如，下面的每個語句都需要把查詢作為它執行的一部分：
INSERT INTO table SELECT...
UPDATE table SET x = y WHERE...
DELETE FROM table WHERE...
CREATE table AS SELECT...

　　具體來說，查詢
· 要求讀一致性
· 可能使用回滾段作中間處理
· 可能要求SQL語句處理描述、定義和取數據階段

　　第3步: 描述查詢結果(Describe Results of a Query)

　　描述階段只有在查詢結果的各個列是未知時才需要；例如，當查詢由用戶交互地輸入需要輸出的列名。在這種情況要用描述階段來決定查詢結果的特征（數據類型，長度和名字）。

　　第4步: 定義查詢的輸出數據(Define Output of a Query)

　　在查詢的定義階段，你指定與查詢出的列值對應的接收變量的位置、大小和數據類型，這樣我們通過接收變量就可以得到查詢結果。如果必要的話，Oracle會自動實現數據類型的轉換。這是將接收變量的類型與對應的列類型相比較決定的。

　　第5步: 綁定變量(Bind Any Variables)

　　此時，Oracle知道了SQL語句的意思，但仍沒有足夠的信息用于執行該語句。Oracle 需要得到在語句中列出的所有變量的值。在該例中，Oracle需要得到對department_id列進行限定的值。得到這個值的過程就叫綁定變量(binding variables)

　　此過程稱之為將變量值捆綁進來。程序必須指出可以找到該數值的變量名（該變量被稱為捆綁變量，變量名實質上是一個內存地址，相當于指針）。應用的最終用戶可能并沒有發覺他們正在指定捆綁變量，因為Oracle 的程序可能只是簡單地指示他們輸入新的值，其實這一切都在程序中自動做了。因為你指定了變量名，在你再次執行之前無須重新捆綁變量。你可以改變綁定變量的值，而Oracle在每次執行時，僅僅使用內存地址來查找此值。如果Oracle 需要實現自動數據類型轉換的話（除非它們是隱含的或缺省的），你還必須對每個值指定數據類型和長度。關于這些信息可以參考oracle的相關文檔，如Oracle Call Interface Programmer's Guide

　　第6步: 并行執行語句(Parallelize the Statement )

　　ORACLE 可以在SELECTs, INSERTs, UPDATEs, MERGEs, DELETEs語句中執行相應并行查詢操作，對于某些DDL操作，如創建索引、用子查詢創建表、在分區表上的操作，也可以執行并行操作。并行化可以導致多個服務器進程(oracle server processes)為同一個SQL語句工作，使該SQL語句可以快速完成，但是會耗費更多的資源，所以除非很有必要，否則不要使用并行查詢。

　　第7步: 執行語句(Run the Statement)

　　到了現在這個時候，Oracle擁有所有需要的信息與資源，因此可以真正運行SQL語句了。如果該語句為SELECT查詢或INSERT語句，則不需要鎖定任何行，因為沒有數據需要被改變。然而，如果語句為UPDATE或DELETE語句，則該語句影響的所有行都被鎖定，防止該用戶提交或回滾之前，別的用戶對這些數據進行修改。這保證了數據的一致性。對于某些語句，你可以指定執行的次數，這稱為批處理(array processing)。指定執行N次，則綁定變量與定義變量被定義為大小為N的數組的開始位置，這種方法可以減少網絡開銷，也是優化的技巧之一。

　　第8步: 取出查詢的行(Fetch Rows of a Query)

　　在fetch階段，行數據被取出來，每個后續的存取操作檢索結果集中的下一行數據，直到最后一行被取出來。上面提到過，批量的fetch是優化的技巧之一。

　　第9步: 關閉游標(Close the Cursor)

　　SQL語句處理的最后一個階段就是關閉游標

　　DDL語句的處理(DDL Statement Processing)

　　DDL語句的執行不同與DML語句和查詢語句的執行，這是因為DDL語句執行成功后需要對數據字典數據進行修改。對于DDL語句，語句的分析階段實際上包括分析、查找數據字典信息和執行。事務管理語句、會話管理語句、系統管理語句只有分析與執行階段，為了重新執行該語句，會重新分析與執行該語句。

　　事務控制(Control of Transactions)

　　一般來說，只有使用ORACLE編程接口的應用設計人員才關心操作的類型，并把相關的操作組織在一起，形成一個事務。一般來說，我門必須定義事務，這樣在一個邏輯單元中的所有工作可以同時被提交或回滾，保證了數據的一致性。一個事務應該由邏輯單元中的所有必須部分組成，不應該多一個，也不應該少一個。
　　· 在事務開始和結束的這段時間內，所有被引用表中的數據都應該在一致的狀態(或可以被回溯到一致的狀態)
　　· 事務應該只包含可以對數據進行一致更改(one consistent change to the data)的SQL語句

　　例如，在兩個帳號之間的轉帳(這是一個事務或邏輯工作單元)，應該包含從一個帳號中借錢(由一個SQL完成)，然后將借的錢存入另一個帳號(由另一個SQL完成)。這2個操作作為一個邏輯單元，應該同時成功或同時失敗。其它不相關的操作，如向一個帳戶中存錢，不應該包含在這個轉帳事務中。

　　在設計應用時，除了需要決定哪種類型的操作組成一個事務外，還需要決定使用BEGIN_DISCRETE_TRANSACTIO存儲過程是否對提高小的、非分布式的事務的性能有作用。

posted @ 2008-05-17 16:56 lqx 閱讀(615) | 評論 (0) | 編輯 收藏

[收藏]請教iframe和父窗口的問題。

答1: <form target="_top"> 答2： D.asp [code] <% ' 清空Session 的操作 %> <script>top.location.reload();</script> [/code] 答3： 把 iframe 的內容尺寸設置的比 iframe 外尺寸小即可。就是說，定義 iframe 的 src 頁內容讓它的尺寸小於 A 頁上 iframe 元素的的尺寸。

非常感謝版主！

再請教一個問題：是否可以在b.asp頁上不做css設置，使它能和父頁面a.asp共用一個style.css文件？ 謝謝！

哦，不知道二者能不能共用一個CSS文件，而不用要分別做CSS鏈接， 再頂一下，盼高手指點，謝謝！

答：不能

posted @ 2008-05-08 00:13 lqx 閱讀(583) | 評論 (0) | 編輯 收藏