你得到人家的 UDDI , WSDL 之类的 XML ，就可以用 Digester/ JAXB 取出你要的值，因为这些都是标准的 XML 格式 你肯定能得到 schema ， 生成客户端 可能就是在 非标准的返回值类型映射 不知道怎么写 serializer/deserializer , 不知道怎么实现运行时 自动处理 / 加解密 我想 容器可以帮我们做吧？ 那么多重量级的 J2EE 容器，======================================
我也是刚学。
我也是刚学。
=============================================
我的意思就是说事实上webservice解决的问题就是远程调用中的调用请求和响应的封装问题。
webservice是定义了一堆schema来解决问题，大家都知道格式。
而rmi中却把格式定义留给了具体实现，同样的解决问题，但是却是私有的。谢谢回复啊。ps:
多进来几个朋友，特别有实际开发经验的朋友进来指导指导啊。
Web Service与WEB应用是不一样,就是说它不是用来仅仅为了搭建某个网站的.比如说"股票查询价格"这个例子,很多不用WEB SERVICE架构的网站也能实现此功能,我想web service主要是把服务出售给
企业级的应用.使企业用应用程序就能调用web service所提供的服务吧.
疑问：
1，1中定义的格式是纯文本（plain text）的，其实和rmi中的marshal/unmarshal没有区别，不同的后者是binary stream,格式不公开，
==> 这个是对的，但 Web Service 是松散耦合的，他是跨系统跨语言的，应用面更广。2，1中定义的格式是纯文本的，也就是说整个过程需要自己保证安全，进行加密等！！！
==>是对的。对于重要的数据，用binary一样也要加密。3，2中返回的结果是给人看的，不是给机器看的，也就是说同样没有办法根据uddi返回的结果编写程序利用服务，必须自己写相关代码。
==>错误，返回的结果是给机器看的。看的这个机器上有事先作好的程序，而这个程序是根据接口做好了的。当然以后的web service会更自动化。可以临时生成响应程序。4，soap其实和webservice没有任何联系。
＝>错误。SOAP和web service密不可分。SOAP是一个基于XML的数据交换协议，他是web service的基础。5，大家平时都用webservice做什么，场景是什么？能不能举几个实际的例子，然后说说为什么要用webservice而不是别的技术框架来做。
==>场景很多，主要是跨系统的数据交互。比如电信公布的短信接口就是一个典型的场合。6，大家能不能推荐几本好的入门的书啊。
==>现在市面上已经有很多书了。
==> web services中有两种style的信息交换，rpc和document。rpc很像java中的RMI－IIOP，用JAX-RPC实现的话，也有stub等概念，传输协议用SOAP，而RMI-IIOP用IIOP。由于web services是用xml来作交互的，对于java和.net都可以实现，所以应用范围更广。
至于document style，我个人认为是更广义的rpc，不止可以调用远程方法，也可以传输异步信息等。2，1中定义的格式是纯文本的，也就是说整个过程需要自己保证安全，进行加密等！！！
==>SOAP在http之上，可以利用http的安全机制来保证传输的安全。3，2中返回的结果是给人看的，不是给机器看的，也就是说同样没有办法根据uddi返回的结果编写程序利用服务，必须自己写相关代码。
==>只要获得了WSDL就可以自动编译生成客户端的stub，然后需要编写client程序来利用service4，soap其实和webservice没有任何联系。
＝>应该这么说，web services只是定义了一套规范，一定要用WSDL定义服务接口，但是传输协议不一定用SOAP。但是现在的BP规定只能用SOAP来作传输协议。5，大家平时都用webservice做什么，场景是什么？能不能举几个实际的例子，然后说说为什么要用webservice而不是别的技术框架来做。
==>web servies有更广大的应用范围，不会局限在java范畴内，实际上任意实现了web servies的系统之间就可以使用对方的服务，而不用考虑对方的实现方法（可以是java或是.net）。所以应用前景非常广阔。
6，大家能不能推荐几本好的入门的书啊。
==>入门可以看J2EE Web Services (Richard Monson-Haefel)我也刚学，还请指教。
疑问：
1，1中定义的格式是纯文本（plain text）的，其实和rmi中的marshal/unmarshal没有区别，不同的后者是binary stream,格式不公开，
==> 这个是对的，但 Web Service 是松散耦合的，他是跨系统跨语言的，应用面更广。
--------------------------------------------------
个人认为是很紧的耦合，因为Web Service的服务发布方和服务使用者之间根根据文档内容定义死死的绑在一起，换句话说：在提供和享受服务的同时，双方建立了这样的强约定,发布特定格式的参数，返回特定格式的响应（这还不设计彼此的逻辑意义，仅仅是物理意义，比如需要三个参数，其中第2个参数必须能够转化为整数）。
个人认为webservice定义了rpc和document两种style是个不够精简的契约（希望这个名词是合适的）。webservice其实核心做的是一件事：双方交互的信息的内容是一个xml文件，请求的xml对应的schema和响应的xml对应的schema是定义好的，不可更改的。（当然这里没有涉及注册/查找服务行为的定义，与此类似）
定义了rpc只能说java提供了这么一套api或者说sdk中的类，如果我自己写socket,然后socket的内容用xml,xml遵守各个schema，和webservice有什么本质性的区别呢？2，1中定义的格式是纯文本的，也就是说整个过程需要自己保证安全，进行加密等！！！
==>是对的。对于重要的数据，用binary一样也要加密。
----------------------
恩。
3，2中返回的结果是给人看的，不是给机器看的，也就是说同样没有办法根据uddi返回的结果编写程序利用服务，必须自己写相关代码。
==>错误，返回的结果是给机器看的。看的这个机器上有事先作好的程序，而这个程序是根据接口做好了的。当然以后的web service会更自动化。可以临时生成响应程序。
--------------------------------
可能我说的不清楚，对于一个程序的调用过程，比如我的一个请求封装在类A里面（仅仅和业务相关，不涉及webservice api,下面的类B同），响应的结果在类B中，我觉得Webservice中还没有那么自动化，根据从Uddi返回的自动构建类A和类B,当然某些代码生成技术可以这么做，但是那是技巧，和web service无关的技巧，不是技术。
我们实际的操作过程还是看了看uddi中注册的请求和相应格式，新增一个Class A,其中有property 1,2,3,新增响应 Class B,其中有property 4,5,6,这两个类应该存在而且webservice没有办法自动生成或者忽略过去（也就是说没有）。
4，soap其实和webservice没有任何联系。
＝>错误。SOAP和web service密不可分。SOAP是一个基于XML的数据交换协议，他是web service的基础。
--------------------------------------
SOAP定义了什么，它定义了它是Http的一个实现（可能这么说不精确）。定义了自己附加的头部，在http头后面，然后是SOAP-HEAD，然后是是SOAP-BODY,当然SOAP在Http基础上添加的部分孤立出来也是一个规整的xml片断，但是这个xml片断和web service的请求/响应，注册/查找相关的schema不相干。
就如我上面说的，我自己写socket,代替SOAP，难道不行么？或者反过来，我用soap传输一些乱七八糟的东西，好像不是webservice吧。
可能和我的观点有关：webservice应该仅仅定义我以什么样的格式交互，这是显得有新意，和传统的rpc方式不一致的地方，定义以什么样的途径交互，看起来很完备，实际上是个瑕疵，或者说让人看起来有些新瓶老酒的味道（我还不会soa，据说那个味道更浓 ^_^）。同样，我用snmp做我的webservice的传输协议好像也可以的哈。5，大家平时都用webservice做什么，场景是什么？能不能举几个实际的例子，然后说说为什么要用webservice而不是别的技术框架来做。
==>场景很多，主要是跨系统的数据交互。比如电信公布的短信接口就是一个典型的场合。
-----------------------------
有没有人干过那种傻事：定义了一个ini格式的接口。或者说定义了这么一个ini接口和webservice有本质性的区别么？6，大家能不能推荐几本好的入门的书啊。
==>现在市面上已经有很多书了。
-----------------------------
打开一看，都是说webservice是未来的趋势 -----我在北京的书店看到的怎么都是老书哈？谁能推荐几本，带书名推荐，看好书，少走弯路哈。
再次谢谢大家支持。
就如我上面说的，我自己写socket,代替SOAP，难道不行么？或者反过来，我用soap传输一些乱七八糟的东西，好像不是webservice吧。
可能和我的观点有关：webservice应该仅仅定义我以什么样的格式交互，这是显得有新意，和传统的rpc方式不一致的地方，定义以什么样的途径交互，看起来很完备，实际上是个瑕疵，或者说让人看起来有些新瓶老酒的味道（我还不会soa，据说那个味道更浓 ^_^）。同样，我用snmp做我的webservice的传输协议好像也可以的哈。---->那要看你的Web servies概念是什么了，最原始的web servies并没有绑定SOAP，但是后来由于web servies的规范太宽范，不利于交互，WS-I 定义了Basic Profile 1.0，规定了web servies实现的一些具体协定，比如一定要用SOAP，SOAP一定要基于HTTP等，当然你也可以不遵守这些协定，如果你不遵守的话可能对于一些web servies你就不能交互了
那么做ws就有两种了：1.彻彻底底的做ws服务端的开发，2.完完全全的使用wsdl提供的method进行二次开发。
他唯一的好处是有个标准，这是唯一的好处。因为跨应用跨操作系统都可以通过别的途径来实现
比如通过调用一个url(是个servlet)，返回一个字符串，只要大家的格式都是定好的就可以了
我们公司就提供了url的工作流接口，供c和java使用
至于为了将老的应用供其它人使用，所以封装为ws的方式，也是可以的，因为封装好了告诉别人，我是ws，如果别人不熟悉，你就可以说，我是标准的啊，你不会用，去学。
但如果是你自己的一种做法，比如用servlet或者soket，别人就会说，你是搞的什么乱七八糟的啊，不好用，你就没话说了。
但我郁闷的说，这个东西的开发竟然不是非常简单，一个说起来很弱智的技术，但开发却复杂，这就是我叫他垃圾的原因。
对象访问可以表示成字符串的话，就可以有 EL , JXPath , 就可以用 Naming & Map ，JXPathContext 之类的 表示和处理，也就是说：取得 UDDI 之后可以把本该用抽象类对象实例表示的东西可以用 String + Naming, Map 或JXPathContext 表示传入的和将要传出的， 最后，你可以不用写代码，给一个 UDDI ,WSDL 等的 URL ,剩下的你只需要找个 工具搞定 ( 我以为所有的东西都可以表示成字符串，复杂的只不过是层次化的组合)。问题可能只是事先不知道返回结果的 树型结构的情况下，可能你得到的结果 ，不容易被有效利用，你也许不能把关键的东西有效过滤出来。 看 IBM 通用测试客户端 和 WebService 测试浏览器，都能给你一个 Web 界面，让你选个 WSDL ，它列举 其中可用的Service，你选一个 然后输入必要的参数， 它返回一个结果给你，我想用人的眼睛在知道为什么选择这个WSDL中的 Service 的时候你肯定知道返回结果是什么东西。工具总是会因为人们需要而出现，大家努力他可能出现的更快,或许已经有了只是我们没有发觉。
1，wsdl文件动态生成stub的可能性,
2，如果1不成立的情况下，webservice的可操作性ps:
决定再学习三个月，然后再发贴和大家讨论。 ^_^