lqxue

struts防止重復(fù)提交

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

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

posted @ 2008-05-29 10:16 lqx 閱讀(208) | 評(píng)論 (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 閱讀(278) | 評(píng)論 (0) | 編輯 收藏

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

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

     <GlobalConfiguration>：用于控制engine范圍的配置。可以包含以下子元素：

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

·            <role> : 設(shè)置一個(gè)SOAP actor/role URI，engine可以對(duì)它進(jìn)行識(shí)別。這允許指向這個(gè)role的SOAP headers成功的被engine處理。任意數(shù)量.

·            <requestFlow> : 全局的請(qǐng)求Handlers。在調(diào)用實(shí)際的服務(wù)之前調(diào)用.

·            <responseFlow> : 全局響應(yīng)Handlers，在調(diào)用完實(shí)際的服務(wù)后，還沒有返回到客戶端之前調(diào)用. 

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

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

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

     <handler [name="name"] type="type">位于頂層元素<deployment> or <undeployment>, or inside a <chain>, <requestFlow>, or <responseFlow>. 用于定義Handler，并定義handler的類型。"Type" 可以是已經(jīng)定義的Handler或者是"java:class.name"形式的QName。可選的"name"屬性允許將這個(gè)Handler的定義在其他部署描述部分中引用。可以包含任意數(shù)量的<parameter name="name" value="value">元素. 

     <service name="name" provider="provider" >部署/卸載一個(gè)Axis服務(wù)。這是最復(fù)雜的一個(gè)WSDD標(biāo)簽。Options可能通過以下元素來指定: <parameter name="name" value="value"/>, 一些常用的包括:·   className : 后臺(tái)實(shí)現(xiàn)的類 allowedMethods : 每個(gè)provider可以決定那些方法允許web services訪問

 Axis支持的providers有如下幾種:

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

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

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

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

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

例如:

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

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

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

     定義一個(gè)鏈。當(dāng)chain被調(diào)用的時(shí)候，按順序調(diào)用其中的handler。這樣就可以構(gòu)建一個(gè)常用功能的模塊，chain元素的子元素可以是handler或者chain。handler的定義形式可以是如下兩種方式:

     定義了一個(gè)服務(wù)器端的傳輸。當(dāng)一個(gè)輸入請(qǐng)求到達(dá)的時(shí)候，服務(wù)器傳輸被調(diào)用。服務(wù)器傳輸可能定義<requestFlow> and/or <responseFlow> 元素來指定handlers/chains，在請(qǐng)求和響應(yīng)被處理的時(shí)候被調(diào)用，這個(gè)功能和service元素中的功能一樣。典型的傳輸請(qǐng)求響應(yīng)handler實(shí)現(xiàn)了關(guān)于傳輸?shù)墓δ堋＠甾D(zhuǎn)換協(xié)議headers等等. 

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

     在上面的例子中，AxisServlet會(huì)處理的查詢字符串是?name，它調(diào)用的類是class.name。

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

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

     定義了一個(gè)客戶端的傳輸，當(dāng)發(fā)送SOAP消息的時(shí)候來調(diào)用。"pivot"屬性指定一個(gè)Handler來作為實(shí)際的傳輸sender，例如HTTPSender。請(qǐng)求和響應(yīng)流和服務(wù)器端的設(shè)置相同. <typeMapping qname="ns:localName" classname="classname" serializer="classname" deserializer="classname"/> 每個(gè)typeMapping將一個(gè)XML qualified名字和一個(gè)Java類進(jìn)行映射，使用一個(gè)序列器和反序列器。 

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

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

全局的Axis配置參數(shù)

服務(wù)默認(rèn)的是通過server-config.wsdd文件中的值來進(jìn)行配置的。但是熟練的Axis用戶可以寫自己的配置handler，這樣就可以將配置數(shù)據(jù)保存在LDAP服務(wù)器，數(shù)據(jù)庫(kù)或者遠(yuǎn)程的web service等等。查看源代碼來了解如何實(shí)現(xiàn)。也可以在web.xml文件中使自動(dòng)的獲取配置信息。但是Axis不推薦這樣使用，因?yàn)樽詈脤⑴渲眯畔⒎旁谝粋€(gè)位置。

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

單獨(dú)的Service(服務(wù))配置

單獨(dú)的Operation(操作)配置

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

同時(shí)Axis還定義日志配置以及一些預(yù)定義的Handler，詳細(xì)內(nèi)容，參考Axis的參考文檔。

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

Web Services和其他的技術(shù)的比較

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

java的call基于document/literal的webservice

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

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

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

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

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

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

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

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. 定義了目標(biāo)命名空間， 全局elementFormDefault=“qualified”。這時(shí)全局元素或者類型將歸于目標(biāo)命名空間，局部元素將以缺省方式歸于目標(biāo)命名空間。

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. 定義了目標(biāo)命名空間， 全局elementFormDefault=“unqualified”。這時(shí)全局元素（c）或者類型將歸于目標(biāo)命名空間。局部元素（c1，c2）以缺省方式歸于無名命名空間。局部元素（c3）在局部定義中使用form=“qualified”覆蓋全局設(shè)定的 unqualified，這使得c3歸于目標(biāo)命名空間（如果它有子元素，子元素將以缺省方式歸于目標(biāo)命名空間）。

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 閱讀(839) | 評(píng)論 (0) | 編輯 收藏

[收藏]MySQLInnoDB存儲(chǔ)引擎的事務(wù)隔離級(jí)別

[收藏]sql 語句的執(zhí)行過程

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

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

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

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

　　圖 3-1 SQL語句處理的各個(gè)階段

　　DML語句的處理

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

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

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

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

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

　　第1步: 創(chuàng)建游標(biāo)(Create a Cursor)

由程序接口調(diào)用創(chuàng)建一個(gè)游標(biāo)（cursor）。任何SQL語句都會(huì)創(chuàng)建它，特別在運(yùn)行DML語句時(shí)，都是自動(dòng)創(chuàng)建游標(biāo)的，不需要開發(fā)人員干預(yù)。多數(shù)應(yīng)用中，游標(biāo)的創(chuàng)建是自動(dòng)的。然而，在預(yù)編譯程序(pro*c)中游標(biāo)的創(chuàng)建，可能是隱含的，也可能顯式的創(chuàng)建。在存儲(chǔ)過程中也是這樣的。

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

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

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

　　以上任何一步出現(xiàn)錯(cuò)誤，都將導(dǎo)致語句報(bào)錯(cuò)，中止執(zhí)行。

　　只有在共享池中不存在等價(jià)SQL語句的情況下，才對(duì)SQL語句作語法分析。在這種情況下，數(shù)據(jù)庫(kù)內(nèi)核重新為該語句分配新的共享SQL區(qū)，并對(duì)語句進(jìn)行語法分析。進(jìn)行語法分析需要耗費(fèi)較多的資源，所以要盡量避免進(jìn)行語法分析，這是優(yōu)化的技巧之一。

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

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

　　查詢語句的處理

　　查詢與其它類型的SQL語句不同，因?yàn)樵诔晒?zhí)行后作為結(jié)果將返回?cái)?shù)據(jù)。其它語句只是簡(jiǎn)單地返回成功或失敗，而查詢則能返回一行或許多行數(shù)據(jù)。查詢的結(jié)果均采用表格形式，結(jié)果行被一次一行或者批量地被檢索出來。從這里我們可以得知批量的fetch數(shù)據(jù)可以降低網(wǎng)絡(luò)開銷，所以批量的fetch也是優(yōu)化的技巧之一。

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

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

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

　　描述階段只有在查詢結(jié)果的各個(gè)列是未知時(shí)才需要；例如，當(dāng)查詢由用戶交互地輸入需要輸出的列名。在這種情況要用描述階段來決定查詢結(jié)果的特征（數(shù)據(jù)類型，長(zhǎng)度和名字）。

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

　　在查詢的定義階段，你指定與查詢出的列值對(duì)應(yīng)的接收變量的位置、大小和數(shù)據(jù)類型，這樣我們通過接收變量就可以得到查詢結(jié)果。如果必要的話，Oracle會(huì)自動(dòng)實(shí)現(xiàn)數(shù)據(jù)類型的轉(zhuǎn)換。這是將接收變量的類型與對(duì)應(yīng)的列類型相比較決定的。

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

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

　　此過程稱之為將變量值捆綁進(jìn)來。程序必須指出可以找到該數(shù)值的變量名（該變量被稱為捆綁變量，變量名實(shí)質(zhì)上是一個(gè)內(nèi)存地址，相當(dāng)于指針）。應(yīng)用的最終用戶可能并沒有發(fā)覺他們正在指定捆綁變量，因?yàn)镺racle 的程序可能只是簡(jiǎn)單地指示他們輸入新的值，其實(shí)這一切都在程序中自動(dòng)做了。因?yàn)槟阒付俗兞棵谀阍俅螆?zhí)行之前無須重新捆綁變量。你可以改變綁定變量的值，而Oracle在每次執(zhí)行時(shí)，僅僅使用內(nèi)存地址來查找此值。如果Oracle 需要實(shí)現(xiàn)自動(dòng)數(shù)據(jù)類型轉(zhuǎn)換的話（除非它們是隱含的或缺省的），你還必須對(duì)每個(gè)值指定數(shù)據(jù)類型和長(zhǎng)度。關(guān)于這些信息可以參考o(jì)racle的相關(guān)文檔，如Oracle Call Interface Programmer's Guide

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

　　ORACLE 可以在SELECTs, INSERTs, UPDATEs, MERGEs, DELETEs語句中執(zhí)行相應(yīng)并行查詢操作，對(duì)于某些DDL操作，如創(chuàng)建索引、用子查詢創(chuàng)建表、在分區(qū)表上的操作，也可以執(zhí)行并行操作。并行化可以導(dǎo)致多個(gè)服務(wù)器進(jìn)程(oracle server processes)為同一個(gè)SQL語句工作，使該SQL語句可以快速完成，但是會(huì)耗費(fèi)更多的資源，所以除非很有必要，否則不要使用并行查詢。

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

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

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

　　在fetch階段，行數(shù)據(jù)被取出來，每個(gè)后續(xù)的存取操作檢索結(jié)果集中的下一行數(shù)據(jù)，直到最后一行被取出來。上面提到過，批量的fetch是優(yōu)化的技巧之一。

　　第9步: 關(guān)閉游標(biāo)(Close the Cursor)

　　SQL語句處理的最后一個(gè)階段就是關(guān)閉游標(biāo)

　　DDL語句的處理(DDL Statement Processing)

　　DDL語句的執(zhí)行不同與DML語句和查詢語句的執(zhí)行，這是因?yàn)镈DL語句執(zhí)行成功后需要對(duì)數(shù)據(jù)字典數(shù)據(jù)進(jìn)行修改。對(duì)于DDL語句，語句的分析階段實(shí)際上包括分析、查找數(shù)據(jù)字典信息和執(zhí)行。事務(wù)管理語句、會(huì)話管理語句、系統(tǒng)管理語句只有分析與執(zhí)行階段，為了重新執(zhí)行該語句，會(huì)重新分析與執(zhí)行該語句。

　　事務(wù)控制(Control of Transactions)

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

　　例如，在兩個(gè)帳號(hào)之間的轉(zhuǎn)帳(這是一個(gè)事務(wù)或邏輯工作單元)，應(yīng)該包含從一個(gè)帳號(hào)中借錢(由一個(gè)SQL完成)，然后將借的錢存入另一個(gè)帳號(hào)(由另一個(gè)SQL完成)。這2個(gè)操作作為一個(gè)邏輯單元，應(yīng)該同時(shí)成功或同時(shí)失敗。其它不相關(guān)的操作，如向一個(gè)帳戶中存錢，不應(yīng)該包含在這個(gè)轉(zhuǎn)帳事務(wù)中。

　　在設(shè)計(jì)應(yīng)用時(shí)，除了需要決定哪種類型的操作組成一個(gè)事務(wù)外，還需要決定使用BEGIN_DISCRETE_TRANSACTIO存儲(chǔ)過程是否對(duì)提高小的、非分布式的事務(wù)的性能有作用。

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

[收藏]請(qǐng)教iframe和父窗口的問題。

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

非常感謝版主！

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

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

答：不能

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