月度归档:2008 年九月

用sed命令批量替换文件内容[原]

今天测试一个替换一个目录下所有.htm文件的脚本。

replace.sh

#!/bin/bash
DIR=/home/tom/test/data
for f in $(ls $DIR/*.htm); do
TMP_FILE=$f.tmp
sed -e ‘s/<table width=”100%” border=”0″ cellpadding=”0″
cellspacing=”0″>/<!–#include virtual=”\/test.html”
–>\n<table width=”100%” border=”0″ cellpadding=”0″
cellspacing=”0″>/g’ $f >> $TMP_FILE
mv $TMP_FILE $f
done

对于初学shell编程的同学来说有以下几点需要注意:

1. #!/bin/bash不能忘记写;

2.赋值号前后不能有空格;

3.变量$f取到的文件名是有可能会带路径的;

4.sed命令好像在替换以后不能自动保存到文件,所以需要重定向到临时文件,然后mv一下;

5.当中的/要转义,\n可以代表回车;

6.如果想递归遍历,不能用‘ls -R $DIR’直接来处理,目前想到的方法是用‘find $DIR | grep -F ‘.htm’’命令来代替。

十大WordPress的SEO优化技巧

WordPress系统本身,默认安装的情况下使用默认模板,实际上对搜索引擎并不友好,并没有针对搜索引擎进行很好的设计,下面我介绍一些技巧和方法可以使得WordPress能否对搜索引擎更为友好。

1、文章URL链接结构的优化

Permalink里面要包含postname.一般的服务器都支持mod_rewrite功能,使用这个功能可以优化Permalink(永 久链接),在Option-Permalink里的Common options里进行设置,我比较倾向于使用/%year%/%monthnum%/%postname%.html这种链接结构,一来链接目录只有两 级,利于索引,二来这种链接结构和Blogspot和Movable Type的链接结构一致,比较利于系统平滑迁移或切换。postname使用英文,如果是写英文Blog的话,系统会自动将标题的post slug做为postname.

2、文章Post Slug的优化

文章标题中最好包含文章最关键的关键字,不要使用一些没有意义的标题,对于英文Blog来讲,最好启用一个名叫SEO Slugs的插件,该插件能够自动将post slug中的the、in等“没用”的单词删除,有利于SEO.

3、文章Title的优化

WordPress默认的Title是“博客名-文章名”,这对SEO很不好,我觉得应该使用“文章名-博客名”的形式,建议安装一个名叫 All in One SEO Pack的插件,可以自动将Title进行优化,并增加Descriptions和Keywords的Meta.

4、robots.txt的优化

在博客根目录下放置一个robots.txt的文件,可以指定搜索引擎只收录指定的内容。 对于WordPress来说,有一些地址是不应该被搜索引擎索引的,比如后台程序、日志文件、FEED地址等,一个针对WordPress的robots.txt的例子如下:

User-agent: * Disallow: /wp- Disallow: /feed/ Disallow: /comments/feed Disallow: /trackback/

5、Sitemap的优化

对于Google搜索引擎来讲,使用Sitemap可以让搜索引擎更为有效的进行索引,安装一个名叫Sitemap Generator的插件可以自动完成Google Sitemap的生成,然后将这个地址提交到Google Webmaster即可。

6、防止垃圾留言评论

垃圾留言评论会影响Blog在搜索引擎中的表现,因此需要安装一个自动过滤垃圾留言评论的的插件,推荐使用Akismet.

7、相关文章

通过tag的标记来实现相关文章,不过我建议使用WordPress 2.3里面的tag系统来实现,那样效率会更高一些。

8、搜索引擎来源的优化

安装一个名叫Landing sites的插件,可以让那些从搜索引擎搜索过来的用户体验更好,通过这个插件能够选择显示给用户搜索关键字相关的文章。

9、不要轻易做变动

不要总是草率的变动自己的域名、博客名、链接结构、链接地址等,早期应该做全局的规划,中途进行大的变动是非常不明智的。

10、更新你的博客

记着经常更新,并且写出高质量的内容,这才是SEO中最关键的地方,写出高质量的文章,将会更容易实现SEO的目标。

J2EE架构分析

J2EE架构是当前主流的架构之一,目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足无需太多费用而 又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台,J2EE降低了开发多层应用的费用和复杂性,同时提供对现有应用程序集成强 有力支持,完全支持Enterprise JavaBeans,有良好的向导支持打包和部署应用,添加目录支持,增强了安全机制,提高了性能。

高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上,相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:

  • 状态管理服务 – 让开发人员写更少的代码,不用关心如何管理状态,这样能够更快地完成程序开发。
  • 持续性服务 – 让开发人员不用对数据访问逻辑进行编码就能编写应用程序,能生成更轻巧,与数据库无关的应用程序,这种应用程序更易于开发与维护。
  • 分布式共享数据对象CACHE服务 – 让开发人员编制高性能的系统,极大提高整体部署的伸缩性。

支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于 J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的 组件,把他们部署到异构环境中,节省了由自己制订整个方案所需的费用。

可伸缩性: 企业必须要选择一种服务器端平台,这种平台应能提 供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与 大型机系统,这种系统单机可支持64至256个处理器。J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈,允许多台服务器集成部 署。这种部署可达数千个处理器,实现可高度伸缩的系统,满足未来商业应用的需要。

J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。传统的J2EE多层企业级应用模型将 两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层,以下是 J2EE 典型的四层结构:

Ø    运行在客户端机器上的客户层组件

Ø    运行在J2EE服务器上的Web层组件

Ø    运行在J2EE服务器上的业务逻辑层组件

Ø    运行在EIS服务器上的企业信息系统(Enterprise information system)层软件

通常认为,J2EE平台就广泛的认为是这个架构,运行在J2EE服务器上的EJB容器可以认为是此结构的核心,EJB容器管理着所有EJB的执行,以及EJB的生命周期,并且为EJB提供所有系统级的服务。EJB组件则负责接受,处理WEB容器的客户请求和连接提供整个企业使用的数据,服务的EIS层。

此“经典”架构中,所有的数据访问都要通过entity bean,业务对象都是带远程接口的无状态session bean,运行在EJB容器中。 EJB中包含了各种服务(比如声明式的事务管理),而且提供了一个共享的中间层,可支持可支持各种类型的J2EE客户端。但结构中应用性能和开发开销的负 担很重,一些负载来在于EJB,而很大还是与分布式架构的特性有关。此外为了分布化,牺牲了OO原则,并且难以测试,因为业务逻辑通常编写在EJB的实现 类中,而这些类完全依赖于EJB容器的。

此“经典”架构的一种改进,便是把远程EJB替换为本地EJB,实现了架构的重用,解决了分布化的种种问题。但架构还是相当的复杂。EJB的很多负担还是存在,从EJB中获得益处反而不多。

所以随着企业级应用开发的不断复杂,对架构设计的要求也会提出新的要求:

  • 架构简单,但功能强大。
  • 架构可以通过配置WEB容器集群来达到横向扩展。
  • 在不同的应用服务器之间具有高移植性。
  • 便于在应用服务器之外进行业务对象的单元测试,而且,一些集成测试甚至可以让一些轻量级容器(如Junit)来完成。

为了解决经典架构中有EJB引起的一系列问题以及满足不断发展的企业应用,提出了非EJB架构的“轻量级容器”。轻量级容器与EJB架构都是有容器管理业 务服务对象,然后再围绕着这个服务层组织整个架构。但是业务对象不是运行在EJB容器中,而是运行在“轻量级容器”中。轻量级容器并没有和J2EE绑定, 所以它既可以运行在WEB容器里,也可以在一个标准应用程序中运行,如必要也可以运行在EJB容器中。这个容器也没有和servlet API绑 定?D?D这一点与MVC结构的WEB框架不同。轻量级容器的启动开销很小,而且无需EJB的部署。

轻量级容器提供了一种 管理、定位业务对象的办法。用不着JNDI寻址、定制服务器之类的额外辅助;轻量级容器为应用对象提供注册服务。其较之EJB容器而言,不仅功能强大,而 且避免了容器强制业务对象采用特定的接口,最低程度的降低了侵入性,实现了效果极佳的架构重用。

轻量级容器中所有的Java类都运行在同一个虚拟机中。

WEB层是由MVC框架提供的(Struts或WebWork,或Spring架构的MVC结构)

业务对象是POJO,运行在轻量级容器里。AOP的拦截机制能够增强业务对象,从而实现企业级服务。与EJB容器不同,业务对象不依赖于容器的API, 所以这些对象在容器外也可以使用,更利于单元测试。业务对象仅仅通过接口来访问,当更改具体业务对象的实现类后,业务对象无需修改。实现了面向接口编程。

数据访问机制可以通过轻量级的O/R Mapping,该层能提供透明的持久化,该持久层实现了对数据访问方式JDBC的轻量级封装。

JBoss,Geronimo还是Tomcat?

作者:李功健
来源:JavaWorld

摘要:

像JBoss、Tomcat和Apache Geronimo这样的开源JavaEE应用服务器轻松地立足于同类商业产品之中,并且真正地在技术革新中处于市场领先地位。但是这些开源JavaEE应用服务器并不完全等同。在这篇文章中作者将从特性、部署和性能方面对JBoss 4.2,Geronimo 2和Tomcat6三种服务器进行了比较。 继续阅读

用J2EE架构企业级应用 (2)

◆ Web容器 服务器端容器,包括两种组件JSP和Servlet,JSP和Servlet都是Web服务器的功能扩展,接受Web请求,返回动态的Web页面。Web容器中的组件可使用EJB容器中的组件完成复杂的商务逻辑。

◆ EJB容器 服务器端容器,包含的组件为EJB(Enterprise
JavaBeans),它是J2EE的核心之一,主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架,以简化企业级
应用的开发,使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。

◆ Applet容器
客户端容器,包含的组件为Applet。Applet是嵌在浏览器中的一种轻量级客户端,一般而言,仅当使用Web页面无法充分地表现数据或应用界面的时
候,才使用它。Applet是一种替代Web页面的手段,我们仅能够使用J2SE开发Applet,Applet无法使用J2EE的各种Service和
API,这是为了安全性的考虑。

◆ Application Client容器 客户端容器,包含的组件为Application Client。Application Client相对Applet而言是一种较重量级的客户端,它能够使用J2EE的大多数Service和API。

通过这四个容器,J2EE能够灵活地实现前面描述的企业级应用的架构。

在View部分,J2EE提供了三种手段:Web容器中的JSP(或
Servlet)、Applet和Application
Client,分别能够实现面向浏览器的数据表现和面向桌面应用的数据表现。Web容器中的Servlet是实现Controller部分业务流程控制的
主要手段;而EJB则主要针对Model部分的业务逻辑实现。至于与各种企业资源和企业级应用相连接,则是依靠J2EE的各种服务和API。

在J2EE的各种服务和API中,JDBC和JCA用于企业资源(各种企业信息系统和数据库等)的连接,JAX-RPC、JAXR和SAAJ则是实现Web Services和Web Services连接的基本支持。

J2EE的各种组件

我们就J2EE的各种组件、服务和API,进行更加详细的阐述,看看在开发不同类型的企业级应用时,根据各自需求和目标的不同,应当如何灵活使用并组合不同的组件和服务。

· Servlet

Servlet是Java平台上的CGI技术。Servlet在服务器端运行,动态
地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比,Java
Servlet具有更高的效率并更容易使用。对于Servlet,重复的请求不会导致同一程序的多次转载,它是依靠线程的方式来支持并发访问的。

· JSP

JSP(Java Server
Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看,非常类似Microsoft
ASP、PHP等技术。借助形式上的内容和外观表现的分离,Web页面制作的任务可以比较方便地划分给页面设计人员和程序员,并方便地通过JSP来合成。
在运行时态,JSP将会被首先转换成Servlet,并以Servlet的形态编译运行,因此它的效率和功能与Servlet相比没有差别,一样具有很高
的效率。

· EJB

EJB定义了一组可重用的组件:Enterprise
Beans。开发人员可以利用这些组件,像搭积木一样建立分布式应用。在装配组件时,所有的Enterprise
Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低
层平台的桥梁管理着EJB容器,并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务,控制了EJB
的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节,简化了商业逻辑的开发。EJB中定义了三种
Enterprise Beans:

◆ Session Beans

◆ Entity Beans

◆ Message-driven Beans

· JDBC

JDBC(Java Database
Connectivity,Java数据库连接)API是一个标准SQL(Structured Query
Language,结构化查询语言)数据库访问接口,它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC
API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC
API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的
ODBC(Open Database Connectivity)。

· JMS

JMS(Java Message
Service,Java消息服务)是一组Java应用接口,它提供创建、发送、接收、读取消息的服务。JMS
API定义了一组公共的应用程序接口和相应语法,使得Java应用能够和各种消息中间件进行通信,这些消息中间件包括IBM
MQ-Series、Microsoft MSMQ及纯Java的SonicMQ。通过使用JMS
API,开发人员无需掌握不同消息产品的使用方法,也可以使用统一的JMS
API来操纵各种消息中间件。通过使用JMS,能够最大限度地提升消息应用的可移植性。
JMS既支持点对点的消息通信,也支持发布/订阅式的消息通信。

· JNDI

由于J2EE应用程序组件一般分布在不同的机器上,所以需要一种机制以便于组件客户
使用者查找和引用组件及资源。在J2EE体系中,使用JNDI(Java Naming and Directory
Interface)定位各种对象,这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI
API为应用程序提供了一个统一的接口来完成标准的目录操作,如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的,应用还可以使用
JNDI访问各种特定的目录服务,如LDAP、NDS和DNS等。

· JTA

JTA(Java Transaction
API)提供了J2EE中处理事务的标准接口,它支持事务的开始、回滚和提交。同时在一般的J2EE平台上,总提供一个JTS(Java
Transaction Service)作为标准的事务处理服务,开发人员可以使用JTA来使用JTS。

· JCA

JCA(J2EE Connector
Architecture)是J2EE体系架构的一部分,为开发人员提供了一套连接各种企业信息系统(EIS,包括ERP、SCM、CRM等)的体系架
构,对于EIS开发商而言,它们只需要开发一套基于JCA的EIS连接适配器,开发人员就能够在任何的J2EE应用服务器中连接并使用它。基于JCA的连
接适配器的实现,需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。

· JMX

JMX(Java Management
Extensions)的前身是JMAPI。JMX致力于解决分布式系统管理的问题。JMX是一种应用编程接口、可扩展对象和方法的集合体,可以跨越各种
异构操作系统平台、系统体系结构和网络传输协议,开发无缝集成的面向系统、网络和服务的管理应用。JMX是一个完整的网络管理应用程序开发环境,它同时提
供了厂商需要收集的完整的特性清单、可生成资源清单表格、图形化的用户接口;访问SNMP的网络API;主机间远程过程调用;数据库访问方法等。

· JAAS

JAAS(Java Authentication and
Authorization Service)实现了一个Java版本的标准Pluggable Authentication
Module(PAM)的框架。JAAS可用来进行用户身份的鉴定,从而能够可靠并安全地确定谁在执行Java代码。同时JAAS还能通过对用户进行授
权,实现基于用户的访问控制。

· JACC

JACC(Java Authorization Service Provider Contract for Containers)在J2EE应用服务器和特定的授权认证服务器之间定义了一个连接的协约,以便将各种授权认证服务器插入到J2EE产品中去。

· JAX-RPC

通过使用JAX-RPC(Java API for XML-based
RPC),已有的Java类或Java应用都能够被重新包装,并以Web
Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API,使开发人员可以方便地使用SOAP消息来完成RPC
调用。同样,对于那些使用EJB(Enterprise
JavaBeans)的商业应用而言,同样可以使用JAX-RPC来包装成Web服务,而这个Web
Servoce的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现,对Web服务的开发人员而
言,SOAP/WSDL变得透明,这有利于加速Web服务的开发周期。

· JAXR

JAXR(Java API for XML
Registries)提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范相兼容的Web
Servcices,这里的Web Services即为注册服务。一般来说,注册服务总是以Web
Services的形式运行的。JAXR支持三种注册服务类型:JAXR Pluggable Provider、Registry-specific
JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML
Registry/Repository等)。

· SAAJ

SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一个增强,为进行低层次的SOAP消息操纵提供了支持。

企业级应用示例

下面我们通过假设一个企业应用的J2EE实现,来了解各种组件和服务的应用。假设应用对象是
计算机产品的生产商/零售商的销售系统,这个销售系统能够通过自己的网站发布产品信息,同时也能将产品目录传送给计算机产品交易市场。销售系统能够在线接
受订单(来自自己的Web网站或者来自计算机产品交易市场),并随后转入内部企业管理系统进行相关的后续处理。

参见图3,这个企业应用可以这种方式架构。该企业应用的核心是产品目录管理和产品定购管理这两个业务逻辑,使用EJB加以实现,并部署在EJB容器中。由于产品目录和定购信息都需要持久化,因此使用JDBC连接数据库,并使用JTA来完成数据库存取事务。

图3 J2EE应用示例

然后使用JSP/Servlet来实现应用的Web表现:在线产品目录浏览和在线定购。为了
将产品目录发送给特定的交易市场,使用JMS实现异步的基于消息的产品目录传输。为了使得更多的其它外部交易市场能够集成产品目录和定购业务,需要使用
Web
Services技术包装商业逻辑的实现。由于产品定购管理需要由公司内部雇员进行处理,因此需要集成公司内部的用户系统和访问控制服务以方便雇员的使
用,使用JACC集成内部的访问控制服务,使用JNDI集成内部的用户目录,并使用JAAS进行访问控制。由于产品订购事务会触发后续的企业ERP系统的
相关操作(包括仓储、财务、生产等),需要使用JCA连接企业ERP。

最后为了将这个应用纳入到企业整体的系统管理体系中去,使用Application Client架构了一个管理客户端(与其它企业应用管理应用部署在一台机器上),并通过JMX管理这个企业应用。

用J2EE架构企业级应用 (1)

企业级应用是指那些为商业组织、大型企业而创建并部署的解决方案及应用。这些大型企业级应用的结构复杂,涉及的外部资源众多、事务密集、数据量大、用户数多,有较强的安全性考虑。

当代的企业级应用决不可能是一个个的独立系统。在企业中,一般都会部署多个彼此连接
的、相互通过不同集成层次进行交互的企业级应用,同时这些应用又都有可能与其它企业的相关应用连接,从而构成一个结构复杂的、跨越Intranet和
Internet的分布式企业应用群集。其中,连接企业内部各种应用的技术称为EAI(Enterprise Application
Integration, 企业应用集成),而连接企业间各种应用的技术称为B2BI(Business-To-Business
Integration, 企业间集成),采用EAI、B2BI技术及早先的N层体系架构就是当今企业级应用的最大特征。

此外,作为企业级应用,其不但要有强大的功能,还要能够满足未来业务需求的变化,易于升级和维护。

企业级应用架构

下面我们使用一个图示来简单地解析一下企业级应用的架构,见图1。


图1 企业级应用的体系架构

这个体系架构的主体是MVC架构。MVC是Model/View/Control的缩写。
Model/View/Control是软件设计的典型结构。在这种设计结构下,一个应用被分为三个部分:Model、View和Controller,
每个部分负责不同的功能。Model是指对业务数据/信息的处理模块,包括对业务数据的存取、加工、综合等;View是指用户界面,也就是面向用户的数据
表示;Controller则负责View和Model之间的流程控制,也就是完成两个方向的动作:1.将用户界面(View)的操作映射到具体的
Model,以完成具体的业务逻辑;2. 将通过Model处理完的业务数据及时反应到用户界面(View)上。

MVC架构使得应用程序的结构更加清晰,通过将代码按照层次划分为业务逻辑/数
据、用户界面和应用流程控制这三个层次,增强代码稳定性。我们知道,对于Model、View、Controller这三部分功能来讲,View的实现一
般是由界面设计人员和界面程序员来完成,Model则是由业务逻辑程序员来完成,Controller则一般由负责整体控制的程序员来完成。
Controller部分的代码比较稳定,一般会实现一个通用的架构;而Model则跟随商务流程的变化而变化;View的更改则是随着用户需求的更改而
更改。这种模块功能的划分有利于在代码修改过程中进行模块的隔离,而不需要把具有不同功能的代码混杂在一起造成混乱。对于项目开发而言,有利于在项目小组
内按照小组成员各自的擅长进行分工,有利于三个部分并行开发、加快项目进度。

企业级资源连接

对于Model部分,也就是业务逻辑的处理部分,一般总是对商务数据进行处理、加工、综合等。对于企业级应用而言,商务数据有两种来源,一种是数据库,另一种则是其它的企业级应用系统。

对于数据库而言,这应当是大家熟悉的领域。我们通过使用数据库驱动程序,利用SQL来查询、操纵数据库。而对于其它的企业级应用而言,一般这些应用都会提供API,通过这些API,其它的应用就能够存取访问其中的数据,甚至是触发这些企业级应用中的一些业余流程。

企业级平台的特征

企业级应用需要使用优秀的企业级应用体系结构,而优秀的企业级应用体系结构通常来自于优秀的
解决方案。应用程序设计开始就要考虑其体系结构的合理性、灵活性、健壮性,从而既可满足企业级应用的复杂需求,也能为今后系统的调整和升级留有余地。体系
结构影响了整个应用的生命周期,实际上能够延长整个应用的生命周期,同时增强了用户在多变的商业社会中的适应性,减少了系统维护的开销和难度,从而给用户
带来最大的利益。

一个理想的企业级应用系统平台应该具有如下特征:

◆ 部署、开发和维护的有效性;

◆ 系统运行的健壮性和可靠性;

◆ 具备失败恢复的能力;

◆ 能够处理海量的数据;

◆ 能够同时支持数百个用户;

◆ 具备很高的安全性;

◆ 数据的高可用性;

◆ 可以迅速地开发和部署新的应用程序;

◆ 简化组件重用;

◆ 直观的编程模型;

◆ 支持行业标准和通用编程接口;

◆ 适用与小、中、大各种规模的应用系统;

◆ 系统费用随系统规模的增长而线性增长;

◆ 不断进行技术升级,以满足不断涌现的需求。

使用J2EE架构企业级应用

为了满足架构企业级应用的需求,Java的创始人Sun公司在早期的J2SE(Java
2 Platform Standard Edition)基础上,针对企业级应用的各种需求,主导并创造了J2EE(Java 2 Platform
Enterprise Edition)。

那么到底什么是J2EE呢?从整体上讲,J2EE是使用Java技术开发企业级应
用的一种事实上的工业标准(Sun公司出于其自身利益的考虑,至今没有将Java及其相关技术纳入标准化组织的体系),它是Java技术不断适应和促进企
业级应用过程中的产物。目前,Java平台有三个版本:适用于小型设备和智能卡的J2ME(Java 2 Platform Micro
Edition)、适用于桌面系统的J2SE和适用于企业级应用的J2EE。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊
病,迎合Browser/Server架构的潮流,为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业
级平台,从而简化企业应用的开发、管理和部署。J2EE是一个标准,而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用
服务器,J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范,因此,使用J2EE技术开发的企业级应用可以部署在各种
J2EE应用服务器上。

为了推广并规范化使用J2EE架构企业级应用的体系架构,Sun同时给出了一个建
议性的J2EE应用设计模型:J2EE Blueprints。J2EE
Blueprints提供了实施J2EE企业级应用的体系架构、设计模式和相关的代码,通过应用J2EE
Blueprints所描述的体系模型,能够部分简化架构企业级应用这项复杂的工作。J2EE
Blueprints是开发人员设计和优化J2EE组件的基本原则,同时为围绕开发工作进行职能分工给出了指导性策略,以帮助应用开发设计人员合理地分配
技术资源。

下面我们参照J2EE Blueprints,结合最新版的J2EE规范(J2EE 1.4),从整体上阐述如何使用J2EE架构企业级应用。


图2 使用J2EE架构企业级应用的体系架构

图2给出了使用J2EE架构企业级应用的体系架构。J2EE将组成一个完整企业级应用的不同
部分纳入不同的容器(Container),每个容器中都包含若干组件(这些组件是需要部署在相应容器中的),同时各种组件都能使用各种J2EE
Service/API。J2EE容器包括:

优化结果页数展示的四种方法

优化结果页数展示的四种方法

1、    对于第一个查询,读取并缓存所有结果。这样可以很容易知道一共有多少结果,数据库不必再额外读取后来的页。这种模型下,展示大多数人期望的那样“共找到X个结果,显示共N/M页”。

2、    不显示所有结果。即使是Google也不会让你看到百万多个结果。你只是查看了N个结果,然后就找到了你所需要的。限制结果数到100、500或其它数量。对于结果列表查看的越远,就说明在这个限制下,扫描并丢弃了更多的数据行。如果你想显示500个结果,你可以读取501个,只要第501存在,展示“找到多于500个结果”。
梁婷 说:

3、   
不显示结果总数或是到其他页的直接链接。只显示“下一个”链接。(如果用户想查看“前一个”结果,他们可以使用浏览器的回退按钮。)实现方法就是读取数量
比想要展示的结果数多一个——例如,读取21个结果,只显示20个。如果存在第21个结果,给出“下一个”链接;如果不存在,显示“这是最后一个结果”。
这种方法不需计算到底一共有多少结果,如果缓存困难的话,还有其它可以减小代价的方法。

4、    预测一共会有多少结果。Google是这么做的,而且得到了大家的认可。使用EXPLAIN查看“rows”列——在某些假设下,这是个很好的预测方法。

十个增强读者体验的方法

  1. 让读者更容易联系你,并建议一个 about 页面
  2. 确保访问你 blog 的速度不错
  3. 用 Category(分类) 来组织你的文章,而不是用日期
  4. 在文章中加入图片
  5. 组织好你的文章内容,让读者一目了然
  6. 不要放广告
  7. 及时回复评论,回访发表评论者
  8. 在博客上显示 Top Posts(最受欢迎文章) 和 Related Posts(相关文章)
  9. 使用一个比较独特,个性化的 theme(主题)
  10. 验证你的 blog ,如 XHTML, CSS

语言文件 po 和 mo 的互相转换

没事想汉化一些 wordpress 插件玩,今天找到两个不错的软件,推荐给大家。

反编译 mo 文件成 po 文件,使用 gettext 的 msgunfmt.exe 工具,命令如下

msgunfmt.exe d:\test.mo -o d:\test.po

编码 po 文件为 mo 文件,使用 poedit 的 msgfmt.exe 工具,命令如下

msgfmt.exe -o d:\test.mo d:\test.po