分类: 模式与架构

  • 那些项目中的接口

    一个糟糕的的程序接口的设计不仅仅是对接口调用者的摧残,更是对整个系统估值的贬低以及对设计者的能力的贬低。

    下午工作的时候,发现在现在的项目,很对接口设计都令人抓狂,在一些地方不仅仅是设计的不好,而是似乎没有经过设计。比如,在一个接口中,明明是只需要一个Device ID (int)列表就能达到目的,却要求传入一个完全的Device列表,调用者不得不构建一个个的Device对象,如果构建这些Device对象是通过web service的方式获取的话,那么会在性能上照成严重的拖累。

    软件设计的最少知识原则(PLK)也是KISS原则(Keep It Simple and Stupid)的一种体现,它们都希望使用你设计的接口或者界面的用户,只希望通过最少的操作就能达到他们的目标。就我个人而言,是非常推崇这种设计的,正如那句广告,简约而不简单。 (更多…)

  • REST-ful URI design

    What are the criteria for a good REST-ful URI?

    I assert:

    • Short (as possible). This makes them easy to write down or spell or remember.
    • Hackable ‘up the tree’. The user should be able to remove the leaf path and get an expected page back. e.g. http://example.com/cars/alfa-romeos/gt you could remove the gt bit and expect to get back all the alfa-romeos.
    • Meaningful. Describes the resource. I should have a hint at the type of resource I am looking at (a blog post, or a conversation). Ideally I would have a clue about the actual content of the URI (e.g. a uri like uri-design-essay)
    • Predictable. Human-guessable. If your URLs are meaningful they may also be predictable. If your users understand them and can predict what a url for a given resource is then may be able to go ‘straight there’ without having to find a hyperlink on a page. If your URIs are predictable, then your developers will argue less over what should be used for new resource types.
    • Help visualize the site structure. This helps make them more ‘predictable’.
    • Readable.
    • Nouns, not verbs.
    • Query args (everything after the ?) are used on querying/searching resources (exclusively). They contain data the affects the query.
    • Consistent. If you use extensions, do not use .html in one location and .htm in another. Consistent patterns make URIs more predictable.
    • Stateless.
    • Return a representation (e.g. XML or json) based on the request headers, like Accept and Accept-Language rather than a change in the URI.
    • Tied to a resource. Permanent. The URI will continue to work while the resource exists, and despite the resource potentially changing over time.
    • Report canonical URIs. If you have two different URIs for the same resource, ensure you put the canonical URL in the response.
    • Follows the digging-deeper-path-and-backspace convention. URI path can be used like a backspace.

    Some of these criteria pull against each other. For example, how can I make a meaningful-yet-short uri? URI-design rightly remains an art not a science. (更多…)

  • CAS单点登录(SSO)

    一、教程前言

    1. 教程目的:从头到尾细细道来单点登录服务器及客户端应用的每个步骤
    2. 单点登录SSO):请看百科解释猛击这里打开
    3. 本教程使用的SSO服务器是Yelu大学研发的CAS(Central Authentication Server),
      官网:http://www.jasig.org/cas
    4. 本教程环境:
      • Tomcat6.0.29
      • JDK6
      • CAS Server版本:cas-server-3.4.3.1
      • CAS Client版本:cas-client-3.1.12
      • 教程撰写日期:2010-11-05
      • 教程作者:咖啡兔 (更多…)
  • 追MM与Java的23种设计模式

    我在Java论坛看到这篇文章,作者以轻松的语言比喻了java的32种模式,有很好的启发作用,但可惜没有给出具体的意思,我就在后边加上了。这些都是最简单的介绍,要学习的话建议你看一下阎宏博士的《Java与模式》一书。

    创建型模式

    1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

    工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 (更多…)

  • 如何开发出一个高质量的J2EE系统zz

    J2EE学习者越来越多,J2EE本身技术不断在发展,涌现出各种概念,本文章试图从一种容易理解的角度对这些概念向初学者进行解释,以便掌握学习J2EE学习方向。
    首先我们需要知道Java和J2EE是两个不同概念,Java不只是指一种语言,已经代表与微软不同的另外一个巨大阵营,所以Java有时是指一种软件系统的流派,当然目前主要是.NET和Java两大主流体系。 (更多…)

  • OAUTH协议简介

    摘要:OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。同时,任何第三方都可以使用OAUTH认证服务,任何服务提供商都可以实现自身的OAUTH认证服务,因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP,JavaScript,Java,Ruby等各种语言开发包,大大节约了程序员的时间,因而OAUTH是简易的。目前互联网很多服务如Open API,很多大头公司如Google,Yahoo,Microsoft等都提供了OAUTH认证服务,这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。

    一、OAUTH产生的背景

    典型案例:如果一个用户拥有两项服务:一项服务是图片在线存储服务A,另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的,所以用户在这两家服务提供商的网站上各自注册了两个用户,假设这两个用户名各不相同,密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时,用户该如何处理?法一:用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印,这种方式安全但处理比较繁琐,效率低下;法二:用户将在服务A上注册的用户名与密码提供给服务B,服务B使用用户的帐号再去服务A处下载待打印的图片,这种方式效率是提高了,但是安全性大大降低了,服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

    很多公司和个人都尝试解决这类问题,包括Google、Yahoo、Microsoft,这也促使OAUTH项目组的产生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的,目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。通过官方网址:http://oauth.net可以阅读更多的相关信息。 (更多…)

  • 通行证系统——跨域登陆与跨域验证

    在为多个WEB App开发统一的Passport系统一直一些多主域名系统需要解决的问题。根据我的经验和研究,有一个类似 Google 的通行证的方案实施后,效果还是可以的。

    SSO的主要效果是用户在任意一个 web app 登录后,别的 app 可以免于再次登陆,但用户浏览到别的 app 的域名下的时候,可以判断用户已经登录的状态,因此用户不用在同一个大平台下的不同域的 app 上多次登录,能有效的提高用户体验。 (更多…)