by shootsoft

yinjun@shootsoft.net

http://www.shootsoft.net

1. Eclipse的Subversion使用说明

开发工具以Eclipse为主，所以Eclipse首先需要安装一个Subversion的插件。参考下面的网址：

http://www.ibm.com/developerworks/cn/opensource/os-ecl-subversion/[shootsoft1] 

项目组的所有成员必须都要按照以上的操作安装好插件，并且注册Google的Gmail帐户。

2.Google Code Host说明

项目组组长到http://code.google.com/hosting/创建新项目（Create a new project）过程省略。最后会看到项目的协作平台网址：http://code.google.com/p/group6homework/。（group6homework是项目名称）组长创建完成后还需要把组员的帐户添加进来：通过[Administer]—[Project Members]就可以对项目组成员帐户进行管理。

创建完成后组长需要安装http://tortoisesvn.net/downloads Subversion的客户端插件进行项目首次的Check In操作。

操作如下：

到Eclipse的项目的workspace目录下，进入需要协作的项目的目录，比如我的：

D:\shootsoft\GP6Platform

单击鼠标右键，选择[TortoiseSVN]—[Import]然后输入：

https://group6homework.googlecode.com/svn/trunk/[番茄花园2] 

注意：

l         这里网址如果你不太清楚可以登录

http://code.google.com/p/group6homework/source查看

l         Google Code Host使用的密码是随机生成的，如果已经登录Google，可以查看以下网址获得密码：

http://code.google.com/hosting/settings

首次登录可能需要安装证书和输入密码。完成后TortoiseSVN就会自动把文件夹

D:\shootsoft\workspace\GP6Platform下的所有文件同步到服务器上去了。

3. Google Code Host与Eclipse

Check In操作完成后组长还需要将项目Check Out出来，真正和Eclipse中的项目结合，组员也需要这样做：

1.将自己的项目文件夹备份并且从Eclipse中删除。需要选择第一项，连同文件夹一起删除。

2.按照http://www.ibm.com/developerworks/cn/opensource/os-ecl-subversion/中的说明进行Import操作，操作结果如下所示：

3.这时点击Next按钮，选择第一项，然后点击Finish按钮。

    4.通过Windows菜单，[Show View]—[Other]

5.在弹出的新窗口中选择“SVN—SVN资源库”

6.在刚才Import进来的那个资源库上单击鼠标右键，选择“检出为(A)...”

7.然后在新窗口中中输入项目名称

点击“Finish”按钮。

稍微等待一会儿，程序就会全部下载回来了。

8.我的Tomcat5补丁放在了D:\Tomcat5补丁目录下，请各位参考我的未知把补丁放置好。

如果导入的项目有红叉叉，在项目上点击鼠标右键，选择“Close Project”然后再打开就好了。这时可以清楚的看到项目上图标发生了一点点变化：

在上面的第3步上，按道理应该可以作为项目可以直接检出，但是我这里操作总是出错，所以只有按照稍微烦琐一点的步骤来操作了。

4. Subversion的使用

如果你对某一个文件进行了修改，想要把这个文件提交到服务器上去，就需要在需要提交的文件上单击鼠标右键，通过Team菜单来[提交]

如果你需要把修改过的文件使用服务器上的来覆盖，可以通过Team菜单的[更新]来进行。

Subversion的使用非常简单，但是要深入探究也可以说上几千字，还是建议通过官方或者非官方的教程来学习：

http://www.baidu.com/s?tn=searches_dg&ie=utf-8&word=subversion+%E6%95%99%E7%A8%8B

http://www.baidu.com/s?wd=Subversion+Eclipse&cl=3

开发者在线 Builder.com.cn 更新时间:2007-09-23作者：中国IT实验室 来源:中国IT实验室

本文关键词： Ant 编程 Java

关于这一点，与其说是个增强，在我看来这似乎是设计思路上略微的转变。具体地说，在.NET 1.x，像这样的代码：

[Serializable]
class Person
...{
 public event EventHandler Birthday;
}

static void Main(string[] args)
...{
 Person p = new Person();
 p.Birthday += new EventHandler(p_Birthday);
 BinaryFormatter bf = new BinaryFormatter();
 MemoryStream ms = new MemoryStream();
 bf.Serialize(ms, p);
}

static void p_Birthday(object sender, EventArgs e)
...{
 Console.WriteLine("Birthday is coming!");
}

会抛出一个这样的异常：

An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in mscorlib.dll
Additional information: Serialization will not deserialize delegates to non-public methods.

提示信息是很明确的，它不支持绑定到非公有方法（non-public method）的委托。要解决这个问题，你得在p_Birthday方法前加一个public关键字。然而，对于类Person的设计者来说，他不知道事件Birthday将被绑定到什么样的方法之上，所以这带来了一定程度的不确定性。

.NET 2.0已经把这个行为改掉了，这段代码现在可以正常运行。这样，在做序列化/反序列化操作时，这增强了应用程序的稳定性。

2、可选字段增强了不同版本的应用程序之间的互操作性

.NET/FCL 2.0的System.Runtime.Serialization命名空间引入了一个新的名为OptionalFieldAttribute的特性类：

Specifies that a field can be missing from a serialization stream so that the BinaryFormatter and the SoapFormatter does not throw an exception.

This attribute allows you to specify that new fields in a serializable type (a type to which the SerializableAttribute is applied to) are ignored by the BinaryFormatter or the SoapFormatter. This enables version-tolerant serialization of types created for older versions of an application that serializes data. For example, when the formatters encounter a stream produced by a version that does not include the new fields, no exception is thrown, and the existing data on the older type is processed as normal.

这个feature在新/旧版本的应用程序用.NET Remoting进行互操作时特别有用。新版本的类型可能增加了一些新的字段（而老版本没有），这样，对于旧类型的对象通过序列化得到的数据，当你试图通过反序列化生成新类型的对象时，会发生找不到类型成员的错误。现在，你可以用这个OptionalFieldAttribute特性类标记那些新字段，使新/旧版本的应用程序互相兼容。

需要注意的是，要使新/旧版本的应用程序互相兼容，这个OptionalFieldAttribute特性类只是提供了一个approach而已，它不保证忽略（缺少）一些字段后的对象仍然有正常的行为。显而易见，这就像在运行时突然把一个对象的某个私有字段改成null或0值，谁也不知道将会发生什么事情。所以，使用这个特性类时，还需要有设计方面的保证。

然而，要设计这样一个向后兼容的新类型，就算使用非常senior的程序员再加上非常细心的设计也很难保证不出错 — 特别是类型很复杂的情形。对我来说，不到万不得已是不会冒险使用这个OptionalFieldAttribute的。

3、序列化/反序列化事件可以让你更容易地自定义序列化行为

在.NET 1.x，要自定义序列化行为，你得让类型继承ISerializable接口（当然还是要应用[Serializable]特性），实现GetObjectData方法和一个反序列化构造函数，像这样：

[Serializable]
class Person : ISerializable
...{
 public Person()
 ...{
 }

 protected Person(SerializationInfo info, StreamingContext context)
 ...{
 }

 public void GetObjectData(SerializationInfo info, StreamingContext context)
 ...{
 }
}

这确实提供了自定义序列化/反序列化行为的途径，你可以在GetObjectData方法中向SerializationInfo手工添加任何数据（哪怕不是对象的成员），然后在反序列化构造函数中从SerializationInfo重新取出数据，再手工初始化对象。

这是一个完备的方案，但是有些情况下它未免有点麻烦。

根据我的experiance，需要自己实现ISerializable接口的情形，往往是因为“大部分字段可以自动序列化（比如int、string），而少数字段不支持序列化（比如Thread、WaitHandle），但这些字段对于对象又是必不可少的”的需求。也就是说，这些不支持序列化的字段在反序列化后仍不允许为空时，你得自己控制序列化/反序列化行为，在反序列化构造函数重新建立它们的实例。

这里的问题是，大部分字段都可以自动序列化的；但是为了少数几个不支持序列化的字段，却需要编写代码为所有字段都进行手工的序列化 — 这些代码不但冗繁，而且容易出错（比如忘掉了处理某个字段）。我一直希望能自己参与自动序列化/反序列化的行为，比如在自动反序列化之后，运行时能自动调用一段我自己的代码，处理那些不支持序列化的字段。

.NET/FCL 2.0满足了我的这个需求，它提供了四个序列化/反序列化事件：OnSerializing、OnSerialized、OnDeserializing、OnDeserialized。它们对应了四个加了Attribute后缀的特性类。这里绑定事件的方法不同于普通.NET事件：事件绑定是通过为方法应用特性来实现的（而不是普通的+=和-=）。不必再详细描述，直接看代码：

[Serializable]
class Person : ISerializable
...{

 public Person()
 ...{
 }

 protected Person(SerializationInfo info, StreamingContext context)
 ...{
  Console.WriteLine(".ctor(SerializationInfo, StreamingContext)");
 }

 public void GetObjectData(SerializationInfo info, StreamingContext context)
 ...{
  Console.WriteLine("GetObjectData");
 }

 [OnSerializing]
 internal void OnSerializing(StreamingContext context)
 ...{
  Console.WriteLine("OnSerializing");
 }

 [OnSerialized]
 internal void OnSerialized(StreamingContext context)
 ...{
  Console.WriteLine("OnSerialized");
 }

 [OnDeserializing]
 internal void OnDeserializing(StreamingContext context)
 ...{
  Console.WriteLine("OnDeserializing");
 }

 [OnDeserialized]
 internal void OnDeserialized(StreamingContext context)
 ...{
  Console.WriteLine("OnDeserialized");
 }
}

static void Main(string[] args)
...{
 BinaryFormatter bf = new BinaryFormatter();
 Person p = new Person();
 MemoryStream ms = new MemoryStream();
 bf.Serialize(ms, p);
 ms.Position = 0;
 p = bf.Deserialize(ms) as Person;
}

Console输出：

OnSerializing
GetObjectData
OnSerialized
OnDeserializing
.ctor(SerializationInfo, StreamingContext)
OnDeserialized

这里加了ISerializable接口只是为了演示事件发生顺序之用，一般情况下，既然已经使用了这四个事件，那这里是不需要这个ISerializable接口的。

SendingAttachmentsWithSOAP.gif(9.9 K)

clip_image001.gif(9.2 K)

clip_image003.gif(16.2 K)

clip_image005.gif(76.4 K)

clip_image007.gif(49.1 K)

SOAP applications often have to deal with more than just simple messages. The payload for a SOAP message can often include a word processing or PDF document, image, or other binary file. This article explains how to use the Message Transmission Optimization Mechanism (MTOM) to send and receive these messages.

Prerequisites

This article uses the WSO2 Web Services Application Server (WSAS.) It is recommended that you download and install WSO2 WSAS 2.0. The article uses the servlet edition installed on Apache Tomcat. Any application server can be used with the servlet version, just follow the installation instructions included with WSO2 WSAS. You don't have to use an application server at all, as WSO2 WSAS works great in a standalone format. WSO2 WSAS requires Java 1.4 or 1.5 but there are no other prerequisites for it. Of course web services and SOAP especially is used, so familiarity with that will help.

When XML is not enough: binary data

There are endless ways to send data over the network. There are numerous protocols and data formats. Standardization around SOAP has taken away a lot of the guesswork in sending data between systems. SOAP standardizes the protocol (HTTP) and the data format (XML.)

One of the main criticisms of SOAP is its use of XML. XML is text based. This not only makes for large messages, but makes it incompatible with binary data. For example, let's say your message needs to include an image. This poses a problem when your message format is text.

Ok, so you need to send binary data between applications. You'd like to use SOAP, but it's limited to text. So should you just give up on SOAP all together? Of course not, there are too many advantages to SOAP. You just need a way to combine it with binary data. You see web pages do this all the time; it can't be that hard, right? Let's explore some solutions to this problem.

One way you might try is to simply dump the binary into a text node. It might look something like Listing 1.

Listing 1. XML with Binary Data: First Try

<?xml version="1.0" encoding="UTF-8"?> 
 <message> 
 	<data><!-- binary data goes here --></data> 
 </message> 
 

Remember that characters are also bytes, just like binary data. An XML parser, whether it's a DOM, SAX, or StAX parser, must use the character set encoding of the document to interpret all the bytes in the document as characters. So our binary data could easily have characters that correspond to reserved XML characters, like < or > or &. Any such byte sequence in text node above will cause the parser on the other side to break. So this approach will not work.

But wait, maybe there's a way to fix this approach. What about using a CDATA block? That will tell the parser to ignore the characters inside the block. This modified approach might look like Listing 2.

Listing 2. XML with Binary: Using CDATA

<?xml version="1.0" encoding="UTF-8"?> 
 <message> 
 	<data><<![CDATA[ binary data goes here ]]></data> 
 </message> 
 

Now if we have bytes that would be interpreted as a > (for example,) they will be ignored. However, the parser has to figure out where the CDATA section ends. It does this by looking for the byte sequence corresponding to the characters ]]> . It might seem unlikely, but our binary data could have just such a byte sequence in the middle of it. That would cause any parser to think that the CDATA section had ended and the subsequent characters would be interpreted just like in our first attempt. So that's not going to work either. We need a way to make sure those bytes aren't interpreted at all.

There is a solution to this variant of our problem. One common way to do this is to use Base 64 encoding. This technique has been around (as a standard) since the 80's. It involves using a 64 character “alphabet” consisting of the lower case characters, a-z, the upper case characters, A-Z, the numbers 0-9, and the + and / symbols. Every byte gets mapped to these characters, so there's no way for any byte to get misinterpreted as anything that would choke an XML parser.

So there, problem solved, right? Yes, but … it's a rather inefficient solution. Base 64 encoded binary winds up being, on average, 37% larger (number of bytes) than the raw, non-encoded binary data. In addition, the parser on the other side needs to know about the encoding so that it can decode the payload. One could imagine that if Base 64 encoding was part of the SOAP standard, then there would be some standard way to indicate this SOAP message processors. This is not the case, though. It may be a solution, but it is both inefficient and non-standard. We need something that is both more efficient and standardized.

One solution to the problem is to use what is known as SOAP with Attachments. The idea here is to just put the binary data outside the SOAP message completely. Figure 1 provides a nice visualization of this.

Figure 1. SOAP with Attachments

This is very similar to how binary files can be attached to emails. The SOAP message contains a reference to the binary file that is attached to the message. This is both more efficient and standardized, but it has some flaws in its design. The binary attachment is not part of the SOAP message at all. It's similar in a lot of ways to just passing a URI for the binary data and leaving it up to the message processor to retrieve the actual binary data. It presents some real problems for things like WS-Security. Still, this is what was used for a while, until a better solution was proposed: MTOM.

MTOM: Best of both worlds

MTOM stands for SOAP Message Transmission Optimization Mechanism. It combines the efficiency of SOAP with Attachments, but it does so without having to break the binary data outside of the SOAP message. How can this be? The key is a technology called XML-binary Optimized Packaging or XOP.

XOP allows binary data to be included as part of the XML Infoset. In fact the XML Infoset becomes a superset of the traditional Infoset known as the XOP Infoset. It allows for the binary data to be stored outside of the XML document, just like in SOAP with Attachments. It uses a special XOP:include element to tell the processor to replace the contents with the referenced binary data, thus encapsulating the logic of discrete storage and retrieval of the binary data. This logic becomes inherent to the XML parser, and allows the SOAP parser to treat the binary data as part of the XML document, with no special retrieval logic. Similarly it allows for a SOAP server to create a SOAP message in a uniform way, no special logic for breaking out that binary data from the SOAP message.

MTOM in WSO2 WSAS

We've talked a lot about the need for MTOM and how it should work in theory. It doesn't do us a lot of good without a real implementation. Luckily there's an easy way to get a great MTOM implementation, just use WSO2 WSAS. WSO2 WSAS is built on top of tried and true technologies, including Apache Axis2. Axis2 gives WSO2 WSAS its MTOM implementation. Let's take a look at how to tap into the power of WSAS/Axis2's MTOM implementation.

MTOM support on Axis2 builds on the same classes used throughout Axis2. It uses Axis2's Object Model (OM). Axis2 supports both Base 64 encoding and MTOM, and makes it relatively simple to switch between them. Why? Well for very small files, it can actually be more efficient to use Base 64 encoding.

To achieve this seamless switching between optimized and non-optimized transport, Axis2 treats binary data as an XML text node. The only difference is that you need to pass in a javax.activation.DataHandler for accessing the data, as shown in Listing 3.

Listing 3. Adding Binary Data with the Axiom API

OMFactory messageFactory = OMAbstractFactory.getOMFactory(); 
 OMNamespace ns = messageFactory.createOMNamespace("urn:foo" , "foo"); 
  
 OMElement binaryElement = messageFactory.createOMElement("payload",ns); 
 FileDataSource src = new FileDataSource("temp.dat"); 
 DataHandler handler = new DataHandler(src); 
 OMText textNode = messageFactory.createOMText(handler, true); 
 binaryElement.addChild(textNode); 
 

In the example in Listing 3, a javax.activation.FileDataSource is used to provide the DataHandler with access to the binary data. You can use any class that implements the javax.activation.DataSource interface. For example, when working with images, the org.apache.axis2.attachments.ImageDataSource can be used. It implements the DataSource interface and can be more convenient when working with images.

So how does Axis2, and thus WSO2 WSAS, know to use MTOM to optimize the binary data? That is actually what Axis2 will do by default. You can manually override this by adding just one line of code, as shown in Listing 4.

Listing 4. Turning off MTOM

textNode.setOptimize(false);

That single line of code will tell Axis2 to not optimize, i.e. don't use MTOM. Thus Axis2 will use Base 64 encoding of the binary data, and it really will be a text node. Otherwise, MTOM will kick in, and an XOP include will be used to optimize the transport of the binary data within the SOAP message.

Of course to get all this wonderful, automatically optimized behavior, you do need to enable MTOM. You can do this through your axis2.xml file very easily, as shown in Listing 5.

Listing 5. Enabling MTOM in axis.xml

<parameter name="enableMTOM">true</parameter>

It can't get anymore painless than that, right? This is a global setting, and is the default setting on WSO2 WSAS. You can actually enable MTOM at four different levels: global, service group, service, and operation. You use the same semantics for each level. You can use the Management Console to manage MTOM at each of these levels. For example of this take a look at Figure 2.

Figure 2. Managing MTOM at the Service Group Level

Here we see MTOM being managed at the Service Group level. Each service in the group can also be individually managed, as shown in Figure 3.

Figure 3. Managing MTOM at the Service Level

Of course each service can have one or more operations. WSAS lets you manage MTOM at that level too, as shown in Figure 4.

Figure 4.

Notice that at each level, MTOM has three possible values: true, false, and optional. If the property is set to true, then the service will send an optimized message when necessary, i.e. when binary data is included. If the value is set to false, then optimization will never be used, and Base 64 encoding will be used for any binary data. If it is set to optional, then WSAS will optimize if and only if the request came in was optimized. The type of request will indicate to WSAS if it should use MTOM or not.

Why do we need this kind of flexibility? As mentioned earlier, it is often advantageous to use Base 64 encoding on small files. Thus you could decide that certain operations should use MTOM and others should not. Or you could make it optional on an operation, programmatically do a check for the size of the data being sent, and then choose to override the default MTOM if the file is small. Then you're sending MTOM. Let's take a look at how easy WSAS makes it to send an MTOM message from a web service client.

Sending a MTOM message from a client is just as easy as sending an MTOM message from a web service. Axis2 provides several convenient APIs. An example is shown in Listing 6.

Listing 6. Client code for sending MTOM message

ServiceClient wsClient = new ServiceClient(); 
 Options clientOptions = new Options(); 
 clientOptions.setTo(new   EndpointReference("http://some/service")); 
 clientOptions.setAction("foo"); 
        clientOptions.setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE); 
 wsClient.setOptions(clientOptions); 
 

As you can see in Listing 6, the key thing to do is to enable MTOM in options for the web service client. Once you do that, then Axis2 will optimize any binary data you send to the web service using MTOM automatically. We've seen how to send MTOM messages from a web service and to a web service, now let's look at how to work with data that has been sent using MTOM.

Now let's assume you have a web service that accepts binary data as part of a SOAP message from a client. If your web service is running on WSAS, you don't need to do anything special to be able to handle optimized binary data from your clients. Your clients can send SOAP messages that use MTOM or Base 64 encoding. It's all seamless with WSAS. Listing 7 shows an example of receiving optimized data.

Listing 7. Web Service receiving Optimized SOAP

OMElement dataElement; // Optimized element 
 OMText dataNode = (OMText) dataElement.getFirstOMChild(); 
 DataHandler handler = (DataHandler) dataNode.getDataHandler(); 
 InputStream stream = handler.getDataSource().getInputStream(); 
 // read from the stream, proces data, save to file or database, etc. 
 

As we saw earlier, the Axiom API treats the binary data as a text node. This allows a single API for dealing with optimized and non-optimized (Base 64 encoded) data. You simply access the DataHandler associated to the text node (that contains the binary data) and use that to obtain an InputStream. Once you have the InputStream, you can read all the bytes and process them however you need to. WSAS makes it easy to handle SOAP messages with optimized binary data payloads. Let's take a look at how easy it is to work with MTOM on clients.

There's no magic to handling an MTOM web service response. We've already seen how to setup the request. In Figure 8 you see how to deal with a response that contains binary data optimized with MTOM.

ServiceClient wsClient = new ServiceClient(); 
 Options clientOptions = new Options(); 
 clientOptions.setTo(new EndpointReference("http://some/service")); 
 clientOptions.setAction("foo"); 
 clientOptions.setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE); 
 wsClient.setOptions(clientOptions); 
 OMElement payload; 
 OMElement response = wsClient.sendReceive(payload); 
 OMElement dataElement = response.getFirstElement(); 
 OMText binNode = (OMText) dataElement.getFirstOMChild(); 
 DataHandler dataHandler2 = (DataHandler) binNode.getDataHandler(); 
 InputStream stream = dataHandler.getInputStream(); 
 

Again the key here is using the Axiom API. It lets us treat the binary data as a text node, and then use the DataHandler to get an InputStream to the data. Again, once you have the InputStream, you can process the data however you need.

Summary

We've seen how MTOM provides the perfect combination of SOAP standardization and efficiency for transporting binary data within a web service message. We've seen how WSO2 WSAS implements the MTOM specification using Axis2. We've taken a look at how to setup both web service servers and clients to both send and receive MTOM optimized messages. Now we have everything we need for adding binary data to our web services using WSO2 WSAS.

Resources

• You're going to want to download WSO2 WSAS.
  
• Read about the latest features in WSO2 WSAS 2.0.
  
• Learn from and interact with the WSO2 community on the WSAS Wiki.
  
• Learn about exposing your services as Web services easily with Axis2.
  
• Learn how Axis2 can enable your SOA designs in the developerWorks article SOA with Axis2.
  
• Learn all about Axis interoperability with other Web service implementations in this entry in the TSS Interoperability blog.
  
• Dive into the AXIOM API in the developerWorks article Get the most out of XML processing with AXIOM.
  
• Read all about XOP and MTOM in this blog entry by Mark Nottingham.
  
• Interoperability is the name of the game when it comes to web service, so learn about using MTOM with .NET in the article Sending files in chunks with MTOM Web Services and .NET 2.0.
  

About the Author

Michael Galpin is an architect at eBay in San Jose, CA. He's been developing software since 1998, and holds a degree in mathematics from the California Institute of Technology.

http://java.sun.com/webservices/reference/tutorials/wsit/doc/DataBinding.html

Data Contracts

This chapter describes guidelines for  :

A WSIT client/service uses JAXB 2.0 for XML serialization, generating XML schemas from Java classes and generating Java classes from XML schemas. A WCF client/service uses either XmlSerializer or DataContractSerializer for like tasks. JAXB 2.0 and the WCF XML serialization mechanisms differ in two fundamental ways. First, JAXB 2.0 supports all of XML schema. .NET's DataContractSerializer and XmlSerializer support different XML schema sets. Second, WCF's XMLSerializer/DataContractSerializer and JAXB 2.0 differ in their mapping of programming language datatypes to XML Schema constructs. As a result, a XML schema generated from a programming language on one platform and consumed on another platform may result in less than developer-friendly bindings. This chapter discusses some of the common databinding differences between the two systems and recommends ways to address them.

二 论坛:
http://forums.java.net/jive/thread.jspa?threadID=23398

Summary: There are multiple threads related to DataSet in these forums. This is an area that needs some guidelines in general.

First, consider how a DataSet is mapped.

    [DataContract]
    public class Foo {
 
        [DataMember]
        public DataSet ds;
     }
 

will map to

[ code ]
<xs:complexType name="Foo">
<xs:sequence>
<xs:element minOccurs="0" name="ds" nillable="true">
<xs:complexType>
<xs:annotation>
<xs:appinfo>
<ActualType Name="DataSet" Namespace="http://schemas.datacontract.org/2004/07/System.Data" xmlns="http://schemas.microsoft.com/2003/10/Serialization/" />
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element ref="xs:schema" />
<xs:any />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="Foo" nillable="true" type="tns:Foo" />

[/code]

Notice that <element ref="xs:schema"/> . This will cause wsimport to fail. There is an issue already logged against this. https://jaxp.dev.java.net/issues/show_bug.cgi?id=14 . The generated schema allows the schema to be deferred until runtime ; since a DataSet can be filled at runtime, there is no way of knowing what the schema is at design time.

One way to avoid to this to pass a strongly typed dataset. For example,

[DataContract]
public class Foo {
 
        [DataMember]
        public  BooksDataSet bds;
}
 
public class BooksDataSet : DataSet {...}
 

This will generate a different schema. Notice that <element ref ="xs:schema"/> is no longer generated.

  <xs:complexType name="Foo">
    <xs:sequence>
      <xs:element minOccurs="0" name="bds" nillable="true" type="tns:BooksDataSet" />
    </xs:sequence>
  </xs:complexType>
  <xs:element name="Foo" nillable="true" type="tns:Foo" />
  <xs:complexType name="BooksDataSet">
    <xs:sequence>
      <xs:any namespace="" />
    </xs:sequence>
  </xs:complexType>
  <xs:element name="BooksDataSet" nillable="true" type="tns:BooksDataSet" />

The above should be consumable by wsimport. However, the object model is driven by the above schema. So one would get java.lang.Object for xs:any.

In short, DataSets work well in MS specific environment but not cross platform.
Other suggestions on the forum and/or elsewhere indicate that other types could be used instead of a strongly typed DataSet - e.g. arrays, XmlNode, or XmlDataDocument.


This is an area where we could use guidlines. Please post your feedback on this thread and I will incorporate it into a future version of the DataContracts chapter
(go to http://weblogs.java.net/blog/sekhar/archive/2007/02/jaxb_and_wcf_da_2.html ; follow the link to Data Contracts chapter).

Message was edited by: sekhar


----------------------------------------
The suggestion was not to expose DataSet to from the .NET service. Instead, map DataSet to another .NET type and expose that datatype. For e.g in your .NET service,
1. Use a strongly typed dataset instead of DataSet (above example).
2. Map DataSet to a jagged array ( e.g. object[][] )
3. Map DataSet to a System.Xml.XmlNode . For e.g.

    DataSet ds;
    //... fill in dataset
    XmlNode xmlnode = new XmlDataDocument( ds );
   

A few months ago I wrote a couple of articles (WCF-ORA, ORA-WCF) about Message Transmission Optimization Mechanism (MTOM) interoperability between Oracle Application Server and Microsoft Windows Communication Foundation (WCF).  Most of the feedback I got from those posts was related with MTOM interoperability scenarios using other Web Service technologies toolkits. Based on that, I decided to post a few more demos that reflect MTOM interoperability scenarios for different vendors. Specifically, this paper shows how to achieve MTOM interoperability between Oracle App Server and Sun Web Service Interoperability Technology (WSIT - Project Tango).  Believe it or not, I am sorry .NET developers; there is no .NET code in this paper.

This post does not intend to provide a formal introduction to MTOM. Suffice to say that after a few years and three predecessors' specifications, MTOM has become the preferred Standard for SOAP-encoded binary messaging optimization. MTOM relies on the XML Optimized Processing (XOP) Standard as the serialization mechanism to represent binary data as a MIME/Multipart Related package. If you are interested in the importance of MTOM interoperability you might want to read my previous paper or this post by John Evdemon.

Sun WSIT and MTOM

WSIT is part of Project Metro which is the Web Services stack from Sun Microsystems. Specifically, WSIT is the component of Project Metro that implements some of the most important WS-* protocols emphasizing in interoperability with Microsoft WCF. Needless to say, that WSIT also interoperates really well with other Web Services technologies including Oracle App Server. At the moment WSIT implements some of the most important WS-* protocols for areas such as Security, Reliability, Transactions and messaging optimization (a.k.a MTOM). The typical scenarios for applying MTOM are Web Services that handles binary data like byte[] as part of their contract. The following code illustrates a WSIT Service that can be highly optimized with the use of MTOM.

 Now we need to configure the service policy in order to optimize the message exchange using MTOM.  The trick here, in order to achieve interoperability with Oracle App Server, is to remove the default WSIT WS-Addressing settings. This is due to the fact that Oracle App Server and Sun WSIT implement different versions of WS-Addressing. The change is not required if the client side supports MTOM with WS-Addressing 1.0 like WCF does. Also, If you are using a development IDE such as NetBeans there is no need to manually configure the policy except for removing the use of WS-Addressing; instead you can the Web Service configuration editor which provides a nice interface for configuring the different WS-* protocols for a particular service.

Now we are ready to deploy the service, for the purposes of this demo we used Sun Glassfish.

Oracle App Server and MTOM

Now it's time to implement an Oracle client for the WSIT service created on the previous section. The first natural step is to generate the proxy using the Web Service Proxy Wizard included in JDeveloper or the corresponding command-line tool. In order to interface with WCF using MTOM, the client code should set the MTOM_SUPPORT property to "True" either programmatically or using the configuration file. The following code shows a sample client that interacts with the WCF service created in the previous section

 Messages Messages

After hosting the WSIT service in Sun Glassfish and running the Oracle client the following message sequence is produced

 SOAP request produced by the Oracle client

SOAP response produced by the Sun WSIT service

You can notice that the byte[] in the request message its been optimized using MTOM and XOP.

In the next weeks I will be posting more demos about WS-* protocols interoperability between some of the top Web Services technologies in the market.

主要包括三部分内容，一是EndpointReference定义，实际上一个定义了一个服端点的模型。二是MAP属性的定义，即消息寻址需要设定和支持的相关属性，三是协议的绑定方式，即如何将协议绑定到现有的协议实现之上如WSDL和SOAP。

主要用来解决以下问题：一是实现与底层传输的隔离，通过将寻址信息放在SOAP头部从而摆脱了对底层协议寻址的依赖。二是结合实现基于消息的路由，可以根据ReplyTo属性实现基于消息的路由。三是实现有状态的会话，基于MessageID和RelatesTO属性实现对会话状态保存机制，从而提供有状态的服务。

下面基于以上内容对Axis2和CXF关于WS-Addressing的实现情况进行简单的对比

EndPointReferance在Axis2里是一个核心概念，它通过EndpointReference类型来实现，它所提供的方法完全支持WS-Addressing协议所定义infoset中所有元素的操作。在Axis2中对服务的定位全部是基于EndPointReferance的。

MDP所定义的属性和相应的操作接口都提供了实现。

WSDL addressing-binding在目前版本中没有明确支持，但在一个开发成员的邮件中显示目前已经准备提供支持，但尚无发布相应模块。SOAP -binding在Axis2内核中得到完全的支持。需要明确引入Addresing模块才能处理，事实上仅仅在输入输出流中打开了相关的处理选项。

使用方法：

1．服务端：

在服务端默认情况下Addressing处理是已经嵌入的。加入Addressing需要将Addressing.mar模块放到module目录下，可以有以下几种方式：

一是通过在Axis2.xml配置文件中添加<module ref="addressing"/>，并在相应的管道如in flow和in faultflow中添加AddressingBasedDispatcher即可（注：Axis2中默认已经添加相应内容）

二是在管理控制台Engage相应addressing模块。在axis2.xml 配置文件中添加以下模块引用<module ref="addressing"/>

2．客户端：

在客户总端有两种方式加入Addressing处理模块:

一是在程序中显示加入。如下所示：（注意需要将Addressing.mar放到可访问路径下）

stub._getServiceClient().engageModule(new　

javax.xml.namespace.QName( org.apache.axis2.Constants.MODULE_ADDRESSING ) );

二是在axis2.xml 配置文件中添加以下模块引用<m