飞天小肥猪的简单人生

测试JS的速度

gouki — Thu, 21 Aug 2008 22:49:00 +0800

在mootools的官方网站有一个网页专门用来测试几个框架的速度，大概是：mootools,jquery,prototype,dojo,yui，测试下来jquery的平均速度应该算是最快的。

那个评测下来IE下JS运行速度慢果然是很明显的。同样的测试在IE下面比FF下面，速度慢了一倍左右啊。

不多了。自己测试一下看结果吧。。
http://mootools.net/slickspeed/

zendframework 1.6终于将SOAP放进去了

gouki — Wed, 20 Aug 2008 23:53:00 +0800

1.6版本的zf终于将SOAP放进来了，同时也增加了DOJO的支持。不过我没有想通。为什么那么多的JS框架，最终会选择了DOJO。

这些不是我能够想得通的。还是看看到底更新了什么再说吧。

An overview of new features:

Dojo Integration
- JSON-RPC
- Dojo Data packing
- Dojo View Helper
- Dijit integration with Zend_Form & Zend_View
- Dojo Library Distribution
SOAP
- SOAP Server
- SOAP Client
- Autodiscovery
- WSDL access
- WSDL Generation
Preview of Tooling Project in Laboratory (see /laboratory folder)
- Command Line Interface
- Project Asset Management
Unit Testing Harness for Controllers
Lucene 2.3 Index File Format Support
Zend_Session save handler for Database Tables
Paginator Component
Text/Figlet Support
ReCaptcha Service
Zend_Config_Xml Attribute Support
Character Set Option for DB Adapters
Zend File Transfer Component
New Media View Helpers (Flash, Quicktime, Object, and Page)
Support in Zend_Translate for INI File Format

This obviously marks a very important step towards a high-quality, highly tested 1.6 GA release. Thanks to everyone who has contributed to this release in any way: with patches/check ins, documentation/translations, and bug reports.

But our work is not yet over! Let's do our best to bring this release to the breaking point to find areas we can improve the release for General Availability. Based on your feedback we will determine in the next few weeks whether we require additional release candidates, so please provide feedback on our issue tracker (http://framework.zend.com/issues) as soon as you can and ask any questions/post your experiences on the appropriate mailing list.

Again, the Zend Framework community does NOT recommend this release for production use. We do, however, recommend evaluating new features in this release with existing and new applications.

Enjoy 1.6RC1, and see you on the issue tracker, wiki, and mailing lists!

————END————

不知道：Zend File Transfer Component，这个会给我们带来什么样的惊喜？大文件传输还是其他的？下载源码研究一下，哈哈

Zend_Acl and MVC Integration Part I (Basic Use)

gouki — Tue, 19 Aug 2008 23:20:00 +0800

原文地址：http://devzone.zend.com/article/3509-Zend_Acl-and-MVC-Integration-Part-I-Basic-Use

原文内容：

By Aldemar Bernal

So, what is wrong with Zend_Acl and the current MVC implementation in the Zend Framework? there is nothing wrong, it is just that it gets not too obvious for developers how to achieve an optimal integration between these two important parts of the framework.

First at all, this article is based on the following Zend Framework Proporsal (link), by this moment this proposal is in Pending Recommendation state.

Well, how it works? There are two key components in this proposal:

A Front Controller Plugin: This component resolves if the current user has access to the page which is being opened.
An Action Helper: This component allows you to check whether the current user has access inside a controller.

Based on these two components, let's try them with an example. Let's talk about a website like DevZone, we would need a controller that work with the user management and another one which will deal with article management, as well we need 3 types of users (roles), one for guests, one for writers and another one which will approve the articles; resuming, we have:

Resources:

user controller.
article controller.

Roles:

Guest.
Writer.
Admin.

Setting up the Zend_Acl component

After defined what we want to do, the next step will create a Zend_Acl instance which will reflect our model.

/** Creating the ACL object */
require_once 'Zend/Acl.php';
$myAcl = new Zend_Acl();

Creating the roles

Now we create the roles in our Zend_Acl instance.

/** Creating Roles */
require_once 'Zend/Acl/Role.php';
$myAcl->addRole(new Zend_Acl_Role('guest'))
      ->addRole(new Zend_Acl_Role('writer'), 'guest')
      ->addRole(new Zend_Acl_Role('admin'), 'writer');

Creating the resources

And then we create the resources needed (one per controller) and their relationship with the roles we created.

/** Creating resources */
require_once 'Zend/Acl/Resource.php';
$myAcl->add(new Zend_Acl_Resource('user'))
      ->add(new Zend_Acl_Resource('article'));

Creating the permissions

Now that we added the roles and resources to our Zend_Acl instance, it's time to explain what actions must be available to which roles.

Guest won't have access to edit, add or approve an article.
Writer won't have access to approve an article.
Admin will have complete access.

/** Creating permissions */
$myAcl->allow('guest', 'user')
      ->deny('guest', 'article')
      ->allow('guest', 'article', 'view')
      ->allow('writer', 'article', array('add', 'edit'))
      ->allow('admin', 'article', 'approve');

Creating the access denied view file

We will need to create a view and an action which will address all those denied users, in order to do it, first we create a new action in our error controller:

class ErrorController extends Zend_Controller_Action
{
    ....

    public function deniedAction()
    {
    }

    ....
}

And then we create our view file (/application/views/scripts/error/denied.phtml) with some warning message:

<h1>Error</h1>
<h2>Access denied</h2>
<p>You are trying to access an area which you have not allowed.</p>

Finishing the configuration

Okay, we have setup our Zend_Acl configuration, so far, it doesn't look like something new, but the next step is register the controller plugin, this important part takes the Zend_Acl instance we created and then validates it against the current page being accessed by an user.

/** Setting up the front controller */ 
require_once 'Zend/Controller/Front.php'; 
$front = Zend_Controller_Front::getInstance(); 
$front->setControllerDirectory('path/to/controllers'); 
 
/** Registering the Plugin object */ 
require_once 'Zend/Controller/Plugin/Acl.php'; 
$aclPlugin = new Zend_Controller_Plugin_Acl($myAcl);
$aclPlugin->setRoleName($currentUserRole);

$front->registerPlugin(new Zend_Controller_Plugin_Acl($acl, 'guest')); 

/** Dispatching the front controller */ 
$front->dispatch();

After this configuration is done, once an user enters in our application, depending the role he/she has the page will be displayed or an access denied page will be displayed.

For more information about this you can go to:
Zend_Acl & MVC Integration
and here is a small implementation source code of this:
Source Code

————END————
由于本文并没有什么特别的地方，而且单词也没有什么，故不作翻译。

最常用的链接

gouki — Tue, 19 Aug 2008 23:18:00 +0800

日常工作中，有一些网站是经常要去的，因此在这里加上链接，以后就可以偷懒了，而且，也防止自己以后找不到相应的网站。[逐步更新中]

PHP官方网站　　　 PHP官方手册　　 PHP下载　　 PHP snap 　　pear for PHP

APACHE官方网站　　 APACHE手册　　 MYSQL官方网站　　 MYSQL官方中文手册

 SMARTY官方网站　　 SMARTY手册　　 smarttemplate官方网站(改名叫quickskin了)

jQuery官方网站　　 prototype官方网站　　 mootools官方网站

 PYTHON官方网站　　 PYTHON手册

下面是系统类的链接
FREEBSD操作手册

Google Reader shared items [2008-08-19]

Tue, 19 Aug 2008 00:00:00 +0800

jQuery---新闻内容切换.（改进版）

把上次发的修改了一下。、

演示：
http://www.cssrain.cn/demo/shownews/index2.htm

下载：
http://www.cssrain.cn/demo/shownews/shownews2.rar

转载请注明： cssrain.cn

电视也弹窗

gouki — Mon, 18 Aug 2008 17:08:00 +0800

偶在网上闲逛。突然发现一段内容，对应家中现有的有线电视情况，突然感到好紧张。。。贴上部分内容，陪我一起震惊吧。

原文：http://www.dbanotes.net/mylife/fuck_huashu_tv.html

自从用了这个遥控器，我就感觉不对劲儿，怎么赛事正精彩的时侯屏幕上会出来个小窗口提示有奖答题呢? 第一次看到以为是央视搞的，后来频繁的出现感觉有点不对，按遥控器的"退出"键，居然提示，"确定退出么?" 按"确定"，居然也要半天才能消失这个小浮动窗口。真是有些震惊啊，这下真的互动了，弹窗广告居然搞到电视上来了!
流氓会武术，谁都挡不住! 相信这个技术会被更多有线电视运营商采用的。到时候面对时不时的弹窗广告，加上原来就有的贴片广告，以及那些"精彩绝伦"的电视购物广告，这电视还能看下去么? 奥运过后，电视关闭!

好佩服现在的厂商呀。这是否和当年的分众一个想法？只是这个想法比分众还疯狂啊。估计是和电信学的吧？

smarty中的注释

gouki — Mon, 18 Aug 2008 14:47:00 +0800

写代码的时候不可避免的会使用到注释。大多数的情况下，我们都是使用，因为这是HTML自带的注释功能，在这里的代码都不会被显示到浏览器。

然而，使用了smarty之类，我们确实不是很建议这样使用，因为，在标记里的smarty代码其实还是被解析了，如果是这样的话，那么，我们其实是多做了很多事情，却没有被显示出来，那就是说，我们其实多做了很多无用功。

因此，我们在使用smarty模版的时候，应该根据smarty的规范来。让我们看看手册怎么说：

所有例子中，我们假定你使用缺省的分隔符。Smarty中，所有在分隔符之外的内容被显示为静态内容，或者说不会被改变。一旦Smarty遇见分隔符，它将尝试解释它们，然后在其位置处显示合适的内容。

注释

模板注释由星号包围，继而由分隔符包围，型如：{* 这是一个注释 *}。Smarty注释不会在最终模板的输出中显示，这点和不同。前者对于在模板中插入内部注释有用，因为没有人能看到。;-)

模版中的注释

{* 这是Smarty注释，不出现在编译后的输出中 *}
<html>
<head>
<title>{$title}</title>
</head>
<body>
{* 另一个单行Smarty注释 *}
{* 这是一个多行
Smarty注释
并不发送到浏览器
*}
{*********************************************************
多行注释块，包含了版权信息
@ author: bg@example.com
@ maintainer: support@example.com
@ para: var that sets block style
@ css: the style output
**********************************************************}
{* 包含了主LOGO和其他东西的头文件 *}
{include file='header.tpl'}
{* 开发注解：$includeFile变量在foo.php脚本中赋值 *}
{include file=$includeFile}
{* 该<select>块是多余的 *}
{*
<select name="company">
{html_options options=$vals selected=$selected_id}
</select>
*}
{* 模板的cvs标记。下面的36应该是美元符号。
但是在CVS中被转换了。 *}
{* $Id: Exp $ *}
{* $Id: *}
</body>
</html>

smarty中的变量使用

gouki — Mon, 18 Aug 2008 14:31:00 +0800

smarty中的变量和平时使用有点区别，比如$aa.bb其实代表的是$aa['bb']，具体如何个使用法，其实在手册里已经有详细说明了

Smarty可以识别嵌入在双引号中赋值的变量，只要变量名只包含数字，字母，下划线和方括号[]（参见命名）。如果有其它字符（如句点，对象引用等），变量必须由反引号对`backticks`包含。你不可以嵌入修饰符，它们必须永远在引号之外使用。

实际使用中应该是这样的：

语法例子：
{func var="test $foo test"}       <-- 使用$foo
{func var="test $foo_bar test"}   <-- 使用$foo_bar
{func var="test $foo[0] test"}    <-- 使用$foo[0]
{func var="test $foo[bar] test"}  <-- 使用$foo[bar]
{func var="test $foo.bar test"}   <-- 使用$foo（不是$foo.bar）
{func var="test `$foo.bar` test"} <-- 使用$foo.bar
{func var="test `$foo.bar` test"|escape} <-- 修饰符在引号外！

实际例子：
{include file="subdir/$tpl_name.tpl"} <-- 将以实际值替换$tpl_name
{cycle values="one,two,`$smarty.config.myval`"} <-- 必须有反引号！

看清楚哦。平时在使用的时候应该是感觉不出问题的，只有用在函数、循环里面，这才会成为使用中的问题。

Google Reader shared items [2008-08-18]

Mon, 18 Aug 2008 00:00:00 +0800

ACE中的设计模式应用场景---模式初学者勿入
摘要: 最近在整理以前所看文章内容时，发现了几篇2003年程序员合订本里关于 ACE的文章，当年这几篇文章中所谈到的内容就让人非常兴奋，因为在那个国内热火朝天学习设计模式的几年里，这几篇文章因为其内容涉及到了bridge, strategy, adapter, facade等模式在这个..
IIS客户端证书访问配置
摘要: 本文给出了如何配置IIS通过SSL安全通道进行访问的方法，并在此基础上详细讨论了IIS如何设置要求对客户端提供客户端证书进行身份验证。IIS端SSL服务器证书申请和安装，从而配置SSL安全访问通道。客户端证书的申请和安装，IIS端如何映射客户端证书到服务器上的win..

一个程序员的13口决！

gouki — Sun, 17 Aug 2008 22:25:00 +0800

看到这段，觉得有理。。。记录下来，实在不知道原作者是谁。。。。

一个程序员的13口决！
1、编程就像吃饭，不可能一口变成胖子。
2、还没练几天就想要高工资，不如去批发白菜好了。
3、程序员也民工，不觉得自己太高尚。
4、你的代码永远存在可优化的可能，所以有空要回头再看看。
5、编程时要永远开着记事本，测试数据，测试方法，搜到的代码等等要常放进去，存起来以备不时之需。
6、不要再回忆你的代码有多牛B，第二天早上别人的代码就可把你的程序替换了。
7、每一天都不是糟糕的，更糟的还在后面。
8、整理你的代码，文档，思维方式，以及行为方式。
9、第一次看到时千万别说你已经理解了。。。未来的变数还很大。
10、任何事物都是由简单开始，并最终回归简单。只是层次不同了而已。
11、首先感谢自己，然后再谢别人。还要感谢人民政府给你提供了就业机会。
12、永远都知道自己当前该做什么。
13、理解正念，并认真执行。

成语新解

gouki — Sun, 17 Aug 2008 20:51:00 +0800

1.知书达礼：仅知道书本知识是不够的，还要学会送礼；
2.度日如年：日子非常好过，每天像过年一样；
3.杯水车薪：每天办公室喝喝茶，月底可以拿到一车工资；
4.知足常乐：知道有人请自己洗脚，心里就感到快乐；
5.见异思迁：看见漂亮的异性就想搬到她那里去住；
6.语重心长：别人话讲得重了，心里怀恨很长时间；
7.有机可乘：出门考察有飞机可以乘坐；
8.不学无术：不要白费工夫学那些不实用的东西；
9.夫唱妇随：丈夫进了歌厅，妻子跟踪尾随。

好不要脸的说明

gouki — Sun, 17 Aug 2008 10:16:00 +0800

国内很多软件开发在叫嚣着开源，但，有几个是真正做到的？最初的discuz，直到现在还是有一些目录是加密的，主要是一些API，现在又看到不少自称是开源的。请你们扪心自问，你们做到了吗？
虽然国内开发人员的素质参差不齐，但靠欺骗的手段来达到听引人的目录，你们对得起自己的良心吗？？
什么是开源？？？看看吧。。。
开放源代码并不仅仅意味着对源代码的访问权。开放源代码软件的发布条款必须满足以下条件：

1. 自由地再发布

如果被发布的软件是由不同来源的程序组成的，许可证不得限制任何当事人或组织（party）销售或赠送作为被发布软件成分之一的开放源码软件。

许可证不得从此项销售中索取使用费或其它任何费用。（理由）

2. 源代码

程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支付合理范围之外的任何费用的手段以获得源代码---从网络上免费下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含混晦涩是不允许的。也不允许给出预处理器或翻译器处理的中间结果。（理由）

3. 派生作品

许可证必须允许修改软件和派生软件，并且必须允许它们按照原软件的许可证的条款进行发布。（理由）

4. 作者的源代码的完整性

只有在许可证允许与源代码一同发布"补丁文件"（该"补丁文件"以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的发布。许可证必须明确地允许发布由修改后的源代码生成的程序。许可证可以要求派生的作品采用不同的名称或不同的版本号以区别于原来的软件。（理由）

5. 不得歧视任何个人或团体

许可证不得歧视任何个人或者由多人组成的团体。（理由）

6. 不得歧视任何应用领域（fields of endeavor）

许可证不得限制任何人把程序应用于任何领域。例如，不得规定程序不能应用于商业领域或基因研究领域。（理由）

7. 许可证的发布

与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者也不需要为了使用该程序而获得其它许可证的许可。（理由）

8. 许可证不能针对于一个产品

与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。（理由）

9. 许可证不能影响其它软件

许可证不得向与采用它的软件一同发布的其它软件提出任何限制。例如，许可证不能坚持要求在同一媒体上发布的其它程序都是开放源代码软件。（理由）

阅读全文

YUI 3.0 Preview Release 1

gouki — Sun, 17 Aug 2008 10:05:00 +0800

几天不见，YUI居然release了，虽然是preview版本。
官方这么说：

The YUI development team has issued YUI 3.0 Preview Release 1, an early look at the next generation of the Yahoo! User Interface Library (YUI). This developer preview shows you where the library is headed as we pursue goals of size, performance, consistency, power, security, and openness.

You can read the introduction to the new release on YUIBlog and get a sense of the new syntactical style in this blog post, which reviews Dav Glass's Draggable Portable example — one of more than 60 examples that accompany the preview's extensive documentation.

YUI 3.0 PR 1 is an early preview — not suitable for production deployment. The development team is looking forward to your feedback in the YUI 3.x community forum as we refine the API toward a 2009 release.

Work continues on YUI's main 2.x codeline, too, and YUI 2.x is still the foundation for current projects. Check out the library's Roadmap for a up-to-date picture of what we're planning for upcoming releases.

有点期待。

Google Reader shared items [2008-08-17]

Sun, 17 Aug 2008 00:00:00 +0800

memcached全面剖析–PDF总结篇
memcached全面剖析的连载已经结束，翻译工作也已经全部完成了。为了方便阅读，现将原来的翻译结果打包成PDF文档。可在本文末尾处下载。原来的各篇翻译的地址如下：第1章：http://tech.idv2.com/2008/07/10/memcached-001/ 第2章：http://tech.idv2.com/2008/07/11/..

Adobe to contribute AMF support to Zend Framework

gouki — Sat, 16 Aug 2008 12:16:00 +0800

Copy from framework.zend.com , it's submitted of Thursday, July 31, 2008
It's full contents :

XML/HTML

Andi Gutmans, the CTO of Zend, blogged yesterday about a new proposal making it’s way through the Zend Framework process.
Adobe has made a proposal for an AMF (Action Message Format) component in Zend Framework. This ZF component will allow for client-side applications built with Flex and Adobe AIR to communicate easily and efficiently with PHP on the server-side. Leading the design of the component for Adobe is Wade Arnold. Wade already has a track record of bringing the Adobe RIA technologies to PHP as a result of all of his work on AMFPHP.
I know everybody over on the Zend Framework team is real excited about this proposal. If you work with Zend Framework then you are going to want to keep an eye on it.

and someone were comments for this news,

XML/HTML代码

This is really great news! I am currently using JSON as the interface format between my Zend Framework and Flex app. This week I've been considering switching to amfphp (Lee Brimelow prepared a screencast http://www.gotoandlearn.com/player.php?id=78), but I didn't want to refactor/change all of my code. Zend_Amf is great news. I can't wait to begin using it. Cheers Adobe!

这样看来，以后ADOBE或许也会主动参与了吧？

Google Reader shared items [2008-08-16]

Sat, 16 Aug 2008 00:00:00 +0800

闪烁和感光症
感光症癫痫（Photosensitive Epilepsy）是一种罕见的癫痫症。高速闪烁的灯光、连续出现的图案、闪烁的视频，甚至树叶被风吹动时摇曳的影子都有可能会引起感光症发作。感光症引起各国的重视，是由于1997年的口袋妖怪事件。 1997年12月16日，《口袋妖怪》第38话《电脑..

详解REST与SOAP的“风格”

gouki — Fri, 15 Aug 2008 23:57:00 +0800

摘要:REST是代表性状态传输的名称首字母缩写，与其说它是标准，不如说是一种风格。然而，在我的前一篇文章中，正如我们所讨论的，众多从事Web服务的软件设计师们认为SOAP过度复杂，于是，类似eBay和Google的服务都采用了REST风格的约束来暴露其大量数据

REST是代表性状态传输的名称首字母缩写，与其说它是标准，不如说是一种风格。然而，在我的前一篇文章中，正如我们所讨论的，众多从事Web服务的软件设计师们认为SOAP过度复杂，于是，类似eBay和Google的服务都采用了REST风格的约束来暴露其大量数据。

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着 HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。Web服务描述语言或WSDL

为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息

用于传送信息的传输协议(例如，通道数)

用于所有可使用功能的名称和接口使用方法

在所有的请求和响应中所使用的数据类型

2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web 服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——

原文来自：http://it.mie168.com/SOA/2007-01/78597.htm

PHP+MYSQL的OA为何没有Java的值钱

gouki — Fri, 15 Aug 2008 23:54:00 +0800

本文来自于天极网。意见不敢苟同，COPY过来也是想听听大家的意见。
原文如下：

为什么PHP+MYSQL的OA不如JAVA写的值钱？？？

现在市场上的oa基本上可归结为两大阵营，即php阵营和java阵营。但对接触oa不久的用户来说，看到的往往只是它们的表相，只是明显的价格差异，却很难看出它们之间的实际差异。其实， PHP + MYSQL 不值钱不仅仅局限于oa软件，而是整体上PHP + MYSQL开发的软件都不如java开发的软件值钱。为什么PHP + MYSQL 的OA为什么不值钱呢？首先得明白php和java之间的差异才行。
　　1、系统的技术架构比较
　　分层是将系统进行有效组织的方式，分而治之的思想是计算机领域中非常重要的思想。在好的分层思想引导下，便能实现“高内聚、低耦合”，也能将具体的问题割裂开来，易于控制、易于延展，更易于分配资源。PHP只能实现简单的分布式两层或三层的架构，而JAVA在这方面就十分强大，可以实现多层的网络架构。运用MVC的设计模式，可使oa系统具有更加高效、合理的系统架构。技术架构的落后，使运用php编写的oa软件系统先天不足，而后天又无法补足其先天上的劣势。使得系统在可拓展性、需求应变性上与JAVA编写的oa软件系统的差距越来越大。架构的差距，注定了php做的oa充其量是个小家碧玉，始终无法和java这种大家闺秀同台竞技。
　　2、数据库访问比较
　　PHP可编译成具有与许多数据库相连接的函数。将自己编写外围的函数去间接存取数据库。通过这样的途径当更换使用的数据库时，可以轻松地修改编码以适应这样的变化。但PHP提供的数据库接口支持彼此不统一，比如对Oracle, MySQL，Sybase的接口，彼此都不一样。由于PHP对于不同的数据库采用不同的数据库访问接口，所以数据库访问代码的通用性不强。
　　而Java通过JDBC来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库，访问数据库的接口比较统一。如果同样是将开发的web应用从MYSQL数据数转到ORACLE数据，PHP需要做大量的修改工作，而且比较繁琐。但JAVA开发的便只需要很少的更改便能实现。
　　数据库访问方式的差异，奠定了php开发出的oa和java开发出来的oa是马车和火车的差距，前者只能亦步亦趋而且额度有限，后者却是工业化的结晶，不仅能够包容万物而且速度上稳步提升。
　　3、安全性对比
　　在同是开源和跨平台的java面前，php丢掉了很多的优势。在代码的安全性上尤为突出。php的开发程序在别人拿到代码后，可以很容易的进行修改。而 java开发的程序由于无法看到完整的源代码，只能看到一些编译好的类文件，所以安全性较高。加之系统架构的优势，在安全性上php和java是相去甚远。
　　如果非要将php和java在安全性上做个比较的话，同一个小偷光顾php那是随便拿来随便改，想拿什么拿什么，拿的高兴还能大笔一辉某某到此一游。而光顾java的时候，便会发现警察把守，内设自动报警装置，即便突破重重阻扰后进入居室。那值钱的东西都放在加密后的保险柜中，只能望洋兴叹、铩羽而归。
　　4、前瞻性和拓展性
　　从整体来说，php适用于中小型系统，而java适用于大型系统。Php能够将单一的事件做好，但却不适合完成集成度较高的多项并发事件。为什么说php适合中小型系统而不适合做大系统呢？
　　首先， php缺乏多层结构支持。而对于大型的系统负荷站点，只能采用分布计算。将数据库、应用逻辑层和表示逻辑层彼此分开，并将同层的根据流量分开，组成二维数组。而php恰恰缺乏这种支持。
　　其次，PHP提供的数据库接口不统一，要将多个不同的数据库数据统一需要花费很大的力气。而JAVA则没有这种缺陷，可通过SUN Java的Java Class和EJB获得规模支持，通过EJB/CORBA以及众多厂商的Application Server获得结构支持。如IBM的E－business，它的核心是采用JSP/Servlet的Web Sphere，是通过CGI来提供支持的。
　　如果将Php比作将才，具备独挡一方的能力。那么java便是帅才，具有较好的前瞻性和拓展性，整体布局和协同能力强。能够指挥千军万马，最后逐鹿中原。
　　5、开发成本比较
　　既然php在诸多方面都不如java优异，那么php开发出的oa产品何以与java产品竞争呢？在于Php阵营普遍走的是低端路线，而java阵营走的是中高端路线。两者之间交叉的区域较小。
　　软件价格的高低很大程度上和自身成本和功能相挂钩。php的入门门槛较低，绝大多数学过c的程序员都很容易转型为php程序员，这使得php程序员的泛滥成灾的同时，低成本的php软件产品也层出不穷。以PHP最经典的组合PHP + MySQL + Apache为例，由于所有软件都是开源免费的，所以投入并不高。
　　而java开发需要特定的环境，成长为一个合格的java程序员需要一定的时间，java程序员的成本也是php成本的几倍。Java的web应用服务器免费的有Tomcat、JBoss等，而要想具有很好的商业化服务便必须选用Web Sphere和 Web logic。这其中投入的成本无形中便超是php成本的N倍。所以，java开发oa的成本要远远高于php开发出来的同类软件产品。但也正由于java 开发的成本较高，很难实现抄袭和短期内逾越的可能，也使得java用开发出的产品门槛更高。
　　不怕不识货，就怕货比货。Php开发出来的产品也能用，但是和java开出的同类产品是没法比较的。正因为php开发的产品整体性能和java开发的相去甚远，所以php运用低成本的低价优势和同类的java产品抗争，以价格落差来平衡购买者的心态。所以，PHP + MYSQL 的OA不值钱也就不足为怪了。

在作者眼里，PHP好象就只能处于低层次的开发。其实开发这东西也是双面性的，你让一个新手写JAVA和让我一个老手写PHP，写出来的东西你认为哪个值钱？
之所以JAVA比PHP值钱，归根结底还是观念，大多数人认为JAVA是科班出身，而PHP则是扎根草堆，虽然最近两年也开始逐步有培训班的出现，但和JAVA比起来就差远了。
就象大腕里说的：你要用PHP写的OA，你都不好意思提出口，怎么着也得是JAVA，.NET之类的吧。

REST与SOAP之比较——SOAP篇

gouki — Fri, 15 Aug 2008 23:41:00 +0800

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息
用于传送信息的传输协议(例如，通道数)
用于所有可使用功能的名称和接口使用方法
在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71772.html
仅作参考

REST与SOAP的比较——REST篇

gouki — Fri, 15 Aug 2008 23:40:00 +0800

　我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，否则的话，开发人员很快就会将其抛之脑后。比如Ajax、SOAP以及REST就证明了这一点。

REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。这个术语是由Roy Fielding创造的。Fielding毕业于Irvine市加利福尼亚大学，在他的博士学位论文中第一次提出了REST这个概念。在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。他在Web标准方面非常有经验，这为他的这篇博士论文奠定了坚实的基础。

Fielding指出，使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件，可以充分利用 Web 的有用特性，万维网(World Wide Web)才能够达到最佳的工作效果。可以这样理解REST——当一个浏览器得到并且显示构成HTML页面的各个元素时，它正在获取资源的当前状态的表现形式。在Fielding的博士论文中，他列举了REST风格的设计约束，并且解释了为什么这些约束能够充分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论，以及这些Web风格是如何导致设计无法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统需要侦察出所承载的协议。由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙，因此，你可以发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为，如果你打算使用HTTP的话，就应该与充分利用HTTP本身的含义。

REST风格强调，通过有限的操作或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提升客户与服务之间的交互。通过为每一个资源分配其自己的URL，来实现灵活性，REST可以调用包含上百个URI的资源类型的客户，其中的关键是REST能够给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。举个例子，GET只能够简单地返回资源的表现形式，而不能够创建任何其他的内容。

在Web发展的初期，由于人们都在试验通过收集各种不同来源的元素，从而把Web应用程序融合在一起，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面创建者没有计划到的用途。这种“屏幕抓取”的Web类比表明，REST风格的方法是先于那些更加复杂的Web服务而出现的。

REST是一种风格而不是一个标准

你可能会把软件的架构风格当作对上层设计模式的抽象。然而，根据Fielding所说，设计模式的堆砌并不等同于架构风格，因为模式是非常接近于特定问题的。

由于REST是超文本系统的一种风格，而不是Web服务的，因此，本文的标题“REST与SOAP之比较”就有些让人误解。然而，很多软件设计人员会将其混淆，他们在考虑如何创建Web服务时，会得出这样的结论：SOAP过于复杂，而简单的类似于REST的设计却更加适合。

REST与RPC风格之比较

远程过程调用的架构，是应用在基于XML-RPC或者 RPC风格的SOAP的Web服务中的，它却有着完全不同的风格。客户端发出命令，以使服务做出特定的操作。换句话说，RPC有动词的倾向。

REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。

一个简单的REST举例

假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：

http://company.com/catalog/description/n1996-01

在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。

REST的商业应用

最近几年，大多数Web商业企业开始对REST非常感兴趣。Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。对服务的HTTP GET请求的响应结果是，采用Atom或者是RSS联合格式的XML数据。Google也使用Atom以及POST、PUT和DELETE操作来完成公共协议。eBay服务提供通过使用不同语言工具来访问服务，这些工具包括文档/文字风格的SOAP以及REST风格。

那么，对于XML-RPC和SOAP所具有的RPC风格而言，REST风格是否是一个具有竞争力的替代者呢?当然，我决不这样认为，在下一篇文章中，我将尽量向大家展现SOAP所向无敌的领域。
———END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71777.html
仅作参考