公司电脑归为两大类：客户机、服务器。所谓客户机就是主动发起连接请求的机器，所谓服务器就是被动响应提供某些服务的机器。
      服务器又可以分仅供企业内网使用和为外网提供服务两种。  

       如果把对外提供服务的服务器放到企业内网，一旦被攻陷入侵，黑客就可以利用这台机器（肉鸡）做跳版，利用局域网的漏洞与共享等来攻克其他机器。

       所以有必要建立一个特殊的区，就叫DMZ。 

       为什么不把这些对外网提供服务的机器单独弄一条线连到公网呢？因为一般中小企业都仅有一个出口。 

       只要按以下规则配置防火墙，就构造了一个DMZ区：

        1.内网可以访问外网
        内网的用户显然需要自由地访问外网。在这一策略中，防火墙需要进行源地址转换。  

        2.内网可以访问DMZ
        此策略是为了方便内网用户使用和管理DMZ中的服务器。  

        3.外网不能访问内网
        很显然，内网中存放的是公司内部数据，这些数据不允许外网的用户进行访问。  

        4.外网可以访问DMZ
        DMZ中的服务器本身就是要给外界提供服务的，所以外网必须可以访问DMZ。同时，外网访问DMZ需要由防火墙完成对外地址到服务器实际地址的转换。  

        5.DMZ不能访问内网
        很明显，如果违背此策略，则当入侵者攻陷DMZ时，就可以进一步进攻到内网的重要数据。  

        6.DMZ不能访问外网
        此条策略也有例外，比如DMZ中放置邮件服务器时，就需要访问外网，否则将不能正常工作。



二,配置实例:

1,防火墙一配置:
1)将 eth0网卡网线于ADSL MODEM相连,并配置好ppp拨号连接.
2)将eth1网卡网线于DMZ区交换机相连,并配置DMZ区IP地址,如图IP:192.168.2.37 ,子网掩码:255.255.255.0
3)使用echo 1 >/proc/sys/net/ipv4/ip_forward打开Linux内核的IP转发功能.
4)使用iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.36 -j MASQUERADE对192.168.2.36进行NAT转发.
5)使用iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.1 -j MASQUERADE对192.168.2.1进行NAT转发.
6)在防火墙配置文件/etc/sysconfig/iptables中添加如下行:
-P FORWARD DROP
-A FORWARD -m state --state
ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -s 192.168.2.36 -j ACCEPT
-A FOEWARD -s 192.168.2.1 -j ACCEPT
注释掉如下行:
#-A FORWARD -j REJECT --reject-with icmp-host-
prohibited
以上配置中的规则允许192.168.2.36及192.168.2.1的数据包通过防火墙进行双向转发.

2,防火墙二配置:
1)将eth0网卡网线于企业内网交换机相连,并配置内网IP地址,如图IP:192.168.10.36 ,子网掩码:255.255.255.0
2)将eth1网卡网线于DMZ区交换机相连,并配置DMZ区IP地址,如图IP:192.168.2.36 ,子网掩码:255.255.255.0
3)将防火墙二的默认网关设置为:192.168.2.37
4)下载pptpd-1.3.4.tar.gz,使用tar命令将包解压,使用./configure;make;make install进行编译安装.
5)配置pptpdVPN服务器:
a,使用vi /etc/pptpd.conf,输入如下内容:
speed 115200
option /etc/ppp/pptpd-options
debug
localip 192.168.0.1(PPTPD服务器网关地址)
remoteip 192.168.1.2-3(PPTPD客户端地址)
enable chap
b,使用vi /etc/ppp/pptpd-options,输入如下内容:
lock
debug
bsdcomp 0
auth
require-chap
proxyarp
,使用vi chap-secrets,输入如下内容:
# Secrets for authentication using CHAP
# client server secret
IP addresses
"wuxinlang" * "wuXinLang" 192.168.1.2
"wuxinlang2" * "12345678" 192.168.1.3

6)启动PPTPD服务进程:
在Linux系统#提示符后输入:pptpd字符回车启动PPTPD服务进程,在Linux系统#提示符后输入:ps –aux | grep pptpd字符回车后系统返回如下信息:
Warning: bad syntax, perhaps a bogus '-'
See /usr/share/doc/procps-3.2.7/FAQ
root 6760 0.0 0.0 1700 536 Ss
Dec22 0:00 pptpd
root 21487 0.0 0.0 4156 672 pts/0 S+
08:53 0:00 grep pptpd
说明PPTPD服务进程启动.

7)添加pppoe可户端访问规则:
a,使用echo 1 >/proc/sys/net/ipv4/ip_forward打开Linux内核的IP转发功能.
b,在/etc/sysconfig/iptables文件中加入如下行:
-A INPUT -p tcp --dport 1723 -s 192.168.10.133 -j
ACCEPT
-A INPUT -p tcp --dport 47 -s 192.168.10.133 -j
ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED
-j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp
--dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-
prohibited
-P FORWARD DROP
-A FORWARD -m state --state
ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -s 192.168.1.2 -j ACCEPT
并注释掉如下行:
-A FORWARD -j REJECT --reject-with icmp-host-
prohibited
打开192.168.2.2对内网访问权限:
iptables -A FORWARD -s 192.168.2.2 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s
192.168.2.2 -j MASQUERADE
这样我们通过启动防火墙配置就只允许 192.168.10.133进行PPPOE拨号连接.
我们可以定义多行包含需要进行PPPOE拨号的IP地址.这样就能够实现特定IP的PPPOE拨号连接并在防火墙中放行定义IP的数据包双向转发.
,iptables -t nat -A POSTROUTING -o eth1 -s
192.168.1.2 -j MASQUERADE对pppoe拨入的IP为192.168.1.2的主机进行NAT转发.
为了启动方便在防火墙一上编写如下脚本:
vi /etc/init.d/iptables_forward_up
:
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net 10.109.1.0/24 gw 192.168.1.37 eth2
iptables -t nat -F
iptables -t nat -A POSTROUTING -o ppp0 -s
192.168.1.37 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -s
192.168.1.38 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -s
192.168.1.39 -j MASQUERADE
#iptables -t nat -A POSTROUTING -o bond0 -j
MASQUERADE ##允许所有IP转发
iptables -I PREROUTING -t mangle -s 192.168.1.37
-j MARK --set-mark 1
iptables -I PREROUTING -t mangle -s 192.168.1.38
-j MARK --set-mark 2
tc qdisc del dev ppp0 root
tc qdisc add dev ppp0 root handle 100: cbq
bandwidth 100Mbit avpkt 1000
tc class add dev ppp0 parent 100:0 classid 100:1
cbq bandwidth 100Mbit rate 100Mbit allot 1514 weight
1Mbit prio 8 maxburst 8 avpkt 1000 bounded
tc class add dev ppp0 parent 100:1 classid 100:2
cbq bandwidth 10Mbit rate 50Kbit allot 1513 weight
5Kbit prio 5 maxburst 8 avpkt 1000 bounded
tc qdisc add dev ppp0 parent 100:2 sfq quantum
1514b perturb 15
tc filter add dev ppp0 parent 100:0 protocol ip
prio 1 handle 1 fw classid 100:2
tc filter add dev ppp0 parent 100:0 protocol ip
prio 2 handle 2 fw classid 100:2
tc qdisc del dev eth2 root
tc qdisc add dev eth2 root handle 200: cbq
bandwidth 100Mbit avpkt 1000
tc class add dev eth2 parent 200:0 classid 200:1
cbq bandwidth 100Mbit rate 100Mbit allot 1514 weight
20Kbit prio 8 maxburst 8 avpkt 1000 bounded
tc class add dev eth2 parent 200:1 classid 200:2
cbq bandwidth 100Mbit rate 50Kbit allot 1513 weight
5Kbit prio 5 maxburst 8 avpkt 1000 bounded
tc qdisc add dev eth2 parent 200:2 sfq quantum
1514b perturb 15
tc filter add dev eth2 parent 200:0 protocol ip
prio 25 u32 match ip dst 192.168.1.0/24 flowid 200:2
vi /etc/init.d/iptables_forward_down:
#!/bin/sh
echo 0 > /proc/sys/net/ipv4/ip_forward
route del -net 10.109.1.0/24 gw 192.168.1.37 eth2
iptables -t nat -F
#iptables -t nat -D POSTROUTING -o bond0 -j
MASQUERADE ##允许所有IP转发
在防火墙二上编写如下脚本:
vi /etc/init.d/ppp_iptables_up
:
#!/bin/bash
route add -host 10.108.72.188 gw 10.109.1.1
echo 1 > /proc/sys/net/ipv4/ip_forward
/usr/local/sbin/pptpd
iptables -t nat -A POSTROUTING -o eth0 -s
192.168.3.2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s
192.168.3.3 -j MASQUERADE
vi /etc/init.d/ppp_iptables_down:
#!/bin/bash
route del -host 10.108.72.188 gw 10.109.1.1
echo 0 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -F
pid=$(ps -ex | grep pptpd | awk '{print $1}');kill
-9 $pid
//查找并KILL掉pptpd进程
通过以上配置,我们的DMZ区就可以进行安全的网络
授权访问.随着业务的发展我们可以将防火墙1的互连网接
入改为静态IP.这样我们可以使用Iptables提供的DNAT及
SNAT对互连网访问DMZ区的数据进行转发和相关的安全审
查.这样就有效的保证了在提高企业数据共享度及远程客
户通过互连网访问企业网站或进行网络交易时企业私有网
的网络安全.

Fedora10多媒体解决方案
一 :mp3播 放 器Audacious
#yum install audacious audacious-plugins audacious-
plugins-freeworld
audacious-plugins-freeworld-*
二 :Mplayer
#yum install mplayer smplayer
安 装 所 有 的 多 媒 体 解 码 器
到 这 里 下 载
http://www.mplayerhq.hu/MPlayer/releases/codecs/all-
20071007.tar.bz2
解 压之后
#chmod u+x *
#cp * /usr/lib/codecs/
#/sbin/ldconfig

     摘要:   阅读全文

简介

面向消息的中间件（Message-oriented middleware，MOM）作为一种开放技术，在当今的事件驱动型应用程序领域，如股票交易、基于事件的供应链管理、空中交通管制和在线拍卖等领域，得到了日益广泛的应用。此外，发布订阅范例在许多新软件架构和和技术领域中都作为构建块使用，如企业服务总线（Enterprise Service Bus，ESB）、企业应用集成（Enterprise Application Integration，EAI）、面向服务的架构（Service-Oriented Architecture，SOA）和事件驱动架构（Event-Driven Architecture，EDA）。然而，新型的消息传递应用程序也带来了一系列严重的性能和可伸缩性挑战。例如，基于RFID技术的下一代事件驱动供应链管理将在很大程度上依赖于可伸缩且高效的后台系统，以支持处理获取的实时数据并与企业应用程序和业务流程集成。一些大型零售商，如Wal-Mart、Metro或Tesco，都希望其吞吐率能够达到6000亿消息/年。要在行业中成功应用这些软件，用于处理这些消息的底层MOM平台的性能和可伸缩性将是至关重要的。

为了保证应用程序能够满足服务质量（Quality of Service，QoS）的需求，使用基准测试工具检测和验证开发应用程序平台的性能和可伸缩性是必备之需。虽然行业中出现了一些专门针对MOM服务器的基准测试工具（如 SonicMQ Test Harness 和 IBM的Performance Harness），并且支持性能测试和产品比较，但它们未能为性能比较提供公平竞争的场地。原因在于，其中大多数软件都使用人工虚拟的负荷，而这恰恰无法反映任何真实的应用程序场景。此外，它们往往过分强调单独且孤立的MOM特性，而没有提供一个全面且有代表性的工作负荷，以评估整体MOM服务器的性能。

为了解决这些问题，标准性能评估机构（SPEC）于2005年9月发起了一个项目，目的是开发一个标准的基准测试工具，用于评估MOM产品的性能和可伸缩性。这款新的基准测试工具就是SPECjms2007，它由SPEG的OSG-java分委员会携Technische Universität Darmstadt、IBM、Sun、Oracle、BEA、Sybase和Apache共同开发。SPECjms2007通过所有主要MOM厂商支持的 JMS (Java Message Service) 标准接口来测试消息传递产品。

需求和目标

SPECjms2007基准测试工具的目的是为检测和评估基于JMS的MOM平台的性能和可伸缩性提供一个标准的工作负荷和规则。为了实现此目的，SPECjms2007的工作负荷必须满足以下几个重要条件。首先，它必须以有代表性的工作负荷场景为基础，这个场景能反映平台服务在现实系统中的实现方式。在基准测试应用场景中，不同方传送和接收的通信方式和消息类型应该代表一个典型的事务组合。目标是允许用户将观测到的行为与他们自己的应用程序和环境联系起来。其次，工作负荷应该是全面的，因为它应该测试MOM应用程序中使用的所有平台特性，包括P2P和发布/订阅（pub/sub）消息传递机制。被强调的特性和服务应该根据它们在现实系统中的作用被赋予不同的重要性。

定义工作负荷事务组合时必须考虑以下几点：

• 事务消息和非事务消息；
• 持久消息和非持久消息；
• 不同的消息类型，如TextMessages、ObjectMessages、StreamMessages和MapMessages；
• 不同大小（小，中，大）的消息；
• P2P和pub/sub通信；
• 一对一、一对多和多对多交互；
• 长期和非长期订阅；
• 消息生产者与消息消费者的比例。

第三，工作负荷应该专注于测试MOM服务器的软硬件组件的性能和可伸缩性。它应该最大程度地降低对在所选应用场景经常使用的其他组件和服务造成的影响。例如，如果数据库用于存储业务数据和管理应用程序的状态，那么以使用其他基准测试工具（如ECperf）显示的经验来看，它就很容易地成为基准测试工具的限制因素。因此，SPECjms2007的工作负荷不能有任何内在的可伸缩性的限制。用户应该能够根据增加接收方（队列和主题）的数目和到达接收方的消息量来扩展工作负荷。

通过生成和发布标准结果来实现营销目的的结果仅仅是SPECjms2007的一种应用场景。在使用基准测试工具时，许多用户将会对调整和优化他们的平台或分析某些特定MOM特性的性能感兴趣。在科研机构中，有些用户为了研究的目的而使用基准测试工具，例如，某些用户可能是因为对评估用于构建高性能MOM服务器的新方法和新技术的性能和可伸缩性感兴趣，而使用了此软件。所有的这些应用场景都有一个共同的要求，即基准测试工具的框架允许用户去精确地配置将要生成的工作负荷和事务组合。提供这种可配置性是一个极大的挑战，因为它需要以这样的一种方式来设计和实现交互，即某用户可以根据自己所期望的事务组合以不同的结合方式来运行它们。

工作负荷场景

SPECjms2007选择的工作负荷场景以超市公司的供应链为模型，涉及的参与者包括超市公司、商店、配送中心和供应商。如图1所示，该场景为定义用于强调MOM服务器提供的不同功能性子集的交互提供了良好的基础，如不同的消息类型、P2P和pub/sub通信。此外，它还支持通过自然的方式扩展工作负荷，如扩展超市数量和每个超市销售的产品数目。

现在我们来进一步研究场景中的参与者。

图1：业务场景——超市供应链

公司总部

公司总部（HQ）负责管理公司的财务审计、超市的货物信息和产品销售价格，以及监控货物和货币在供应链中的流动情况。

配送中心

配送中心（DC）供应货物给超市。每个配送中心负责一定区域内的超市。配送中心的货物由外部供应商供应。配送中心参与以下活动：从超市获取订单，从供应商处订购货物，送货到超市，以及向公司总部上交销售统计表（比如说，用于数据挖掘）。

超市

超市（SM）销售货物给消费者。该场景专注于超市的库存管理，包括仓库管理。有些超市比较小，所以它们没有足够的空间来存放所有产品；有些超市可能专门销售部分产品，如特定类型的食物。我们假定每个超市都有专门的配送中心为其送货。

供应商

供应商发货给超市公司的配送中心。不同的供应商负责发送不同的产品，它们根据超市公司的订单发货。也就是说，它们必需先从超市公司获得订单，然后根据订单发货。

建立的交互模型

SPECjms2007为超市中供应链中的参与者建立了七种交互模型：

1. SM和对应DC之间的订购／发货处理
2. DC和SP间的订购／发货处理
3. 价格更新
4. 库存管理
5. 销售统计数据收集
6. 产品发布
7. 信用卡活动表

让我们来仔细研究一下这些交互。

交互１：SM和DC之间的订购／发货处理

此交互测试SM和DC之间的持久性P2P消息传递。当SM的库存不多时，便会触发此交互，SM必须从DC处订货来填补库存。下面是具体步骤，如图2所示：

1. SM发送订单给DC。
2. DC给SM发送收到订单的确认信息，并向其发出所订购的货物。
3. 当货物从DC库存发出时，需通过RFID阅读程序进行登记。
4. DC发送交易信息（销售统计数据）给HQ；
5. SM收到货物后，要先将货物通过RFID阅读程序登记，然后存入SM库存；
6. SM向DC发送收到货物的确认信息。

图２：交互１——ＳＭ和ＤＣ之间的通信

交互2：DC和SP间的订货／发货处理

此交互测试DC和SP之间的持久性P2P和pub/sub消息传递。当DC的库存不多的时候，便会触发此交互，DC必须从SP处订货来填补库存。下面是具体步骤，如图3所示：

1. DC发送请求给所有可以提供其需要订购的货物种类的SP，要求他们报价。
2. 可以发货的SP发送报价信息给DC。
3. 基于这些报价，DC选择一个SP，向其发送订单。
4. SP发送收到订单的确认信息给DC ，并开发票给HQ，然后发货给DC。
5. DC收到货物之后，要先通过RFID 阅读机登记，然后进入其库存。
6. DC发送收到货物的确认信息给SP。
7. DC发送交易统计信息给HQ。

图3：交互1——SP和DC之间的通信

交互3：价格更新

此交互测试HQ和SM之间的持久性pub/sub消息传递。当公司管理部门的销售价格有变动时，便会触发此交互。为了实现这种通信，HQ需发送价格信息给SM。

交互4：SM库存管理

这个交互是指SM内部的持久性P2P消息传递。当SM的仓库出货或填充货物时，便会触发此交互。当货物通过RFID阅读程序登记后，当地库存的应用程序会通知以便货物的详细目录能够得到及时地更新。需要注意的是新进的货物是另一个交互（交互1）的一部分，这里不做考虑。

交互5：销售统计数据收集

此交互测试SM和HQ之间的非持久性P2P消息传递。当SM发送销售统计信息给HQ时，便会触发此交互。HQ可以使用此数据作为数据挖掘的基础，以便于研究消费者的行为并为市场提供有用的信息。例如，这些信息可用于制订特价优惠或商品折扣。

交互6：新产品发布

此交互测试SM和HQ之间的非持久性pub/sub消息传递。当公司管理部门发布新产品时，便会触发此交互。为了建立通信，HQ需要将产品信息发送给销售各种产品（如食品、计算机和mp3播放器）的SM。

交互7：信用卡活动表

此交互测试HQ和SM之间的非持久性pub/sub消息传递。当HQ发送信用卡活动表给SM（此表每隔一小时完成一次，并根据需要及时更新）时，便会触发此交互。此交互过去用于执行非持久性pub/sub消息传递。

基准测试实现

作为SPECjms2007基准测试工具的一部分，前面提到的工作负荷场景已经得以实现，现在我们将简要讨论一下具体的实现方法。

事件处理程序和代理

SPECjms2007是作为java应用程序实现的，它由横跨一组客户机节点的多个JVM和线程组成。每个接收方（队列或主题）都通过一个单独的Java类，即事件处理程序（Event Handler，EH），封装应用程序逻辑，执行逻辑将处理发送给接收方的消息。当新消息到来时，事件处理程序登记为队列/主题的监听程序并接收从消息传递基础架构反馈的信息。

为了实现最佳的性能和可伸缩性，在各线程中执行的每个事件处理程序都可存在多个实例，并且它们可以分布在多个物理节点上。事件处理程序可以根据它们在业务场景中的物理位置（如HQ、SM、DC和SP）来分组。

除事件处理程序之外，针对每个物理位置，还可以通过运行一组线程来驱动在该物理位置上逻辑启动的基准测试交互，这就是所谓的驱动线程。所有关于特定物理位置的事件处理程序和驱动线程的集合叫做代理。例如，每个DC代理机构由DC内发送往不同接收方的一组事件处理程序和用来驱动交互2的一组驱动线程组成，而交互2是DC作为逻辑起点来进行交互的唯一的交互。

工作负荷的可配置性

SPECjms2007的另一个重要目标就是为MOM服务器的性能分析提供一个灵活的框架，此框架允许用户根据自己的需求配置和自定义工作负荷。为了实现此目标，交互可以按照以下方式来实现，即用户可以根据所需的事务组合以不同的组合方式来运行交互。要实现可配置性需遵循以下几点：

• 接收方（队列和主题）的数目和类型；
• 某个接收方的通信量；
• 消息类型组合；
• 消息大小组合；
• 消息生产者和消费者的数目。

SPECjms2007提供了三种构造工作负荷的方式：水平方式、垂直方式和自由方式。后面两种方式表示工作负荷的拓扑结构，它们对应于三种不同的模式，即运行提供了不同程度的可配置性的基准测试工具的三种模式。

水平和垂直拓扑结构代表扩展超市供应链场景的两种策略，第一种策略是通过增加物理位置的数目来实现，第二种策略是通过增加每个物理位置的通信量来实现。水平拓扑结构的作用是测试系统在接收方数量不断增加的情况下的处理能力。因此，工作负荷因物理位置（SM、DC等）的数量增加而得以扩充，而每个位置的通信量却仍然保持不变。

另一方面，垂直拓扑结构的作用是测试系统在一组固定接收方的通信量不断增长的情况下的处理能力。因此，它使用一组固定的物理位置，并通过增加交互的运行频率来扩展工作负荷。最后，自由拓扑结构允许用户将SPECjms2007的七种交互作为构建块来设计自己的工作负荷场景，此场景可以通过增加物理位置的数目及/或增加交互运行的速度，以一种自由的方式来扩展工作负荷。表1显示了三种拓扑结构中可以配置的工作负荷参数，如下所示：

 

工作负荷参数	配置 自由方式 水平方式 垂直方式
模拟物理位置（HQ、 SM、DC和SP）	是 否 否
交互运行的频率	是 否 否
每个消息类型的消息规模分布	是 否 否
每个物理位置的代理	是 是 是
跨客户机节点的代理分布	是 是 是
每个客户节点上运行的JVM	是 是 是
JVM之间的代理机构分布	是 是 是
每个消息类型（消息消费者）的事件处理程序	是 是 是
每个交互（消息生产者）的驱动线程	是 是 是
每个事件处理程序或驱动线程使用的连接工厂	是 是 是
各事件处理程序在单个代理中共享的JMS连接	是 是 是
非事务会话的确认模式	是 否 否
多重会话的共享连接	是 否 否
传输后检验信息完整性的频率（CRC检验）	是 否 否

 

在水平和垂直的拓扑结构中，只可以对上面的个别参数进行设置，而在自由拓扑结构中，可以对所有的参数进行设置。更为重要的是，用户可以根据其需求选择性地关闭交互或改变它们的运行频率来形成工作负荷。同时，在使用水平或垂直的拓扑结构时，基准测试中的交互将根据它们在现实应用场景中的相互依赖关系而彼此关联。

工作负荷特征

在第4期European Performance Engineering Workshop（EPEW-2007）学报上发表的《Workload Characterization of the SPECjms2007 Benchmark》论文提供了SPECjms2007的全面的工作负荷特征。衡量基准测试工作负荷的指标包括接收方（队列和主题）的数量和类型、交互组合、消息类型、消息大小和消息交付模式。表2详细列出了在各种交互中使用的不同消息类型和接收方。

论文提供了详细消息吞吐量分析，主要目的有二：其一，通过使用提供的信息，用户可以组合工作负荷配置（根据位置的数目和交互率），这种配置强调消息在特定缩放条件下具体类型。这允许用户使用SPECjms2007交互作为构建块来创建自定义工作负荷。一个非常基础的例子：当订阅者数量不断增加时，用户可能对评估非持久性pub/sub消息传递的性能和可伸缩性感兴趣。在这种情况下，当SM数量不断增加时，交互6和交互7就需要组合起来使用。其二，在每个基础位置的通信量的特征可以帮助用户去发现处于不同位置的代理机构的最佳部署布局，这样，负荷将平均分布在各客户节点中，且不会使客户端成为瓶颈。这对于消息传递基准测试极为重要，因为服务器在交互过程中充当调停者的角色，并且需要在客户端上处理大量任务。

 

交互	消息	目的地	类型	属性	描述
1	order	队列（DC）	ObjectMsg	P, T	SM向DC发送订单
	orderConf	队列（SM）	ObjectMsg	P, T	DC向SM发送收到订单的确认信息
	shipDep	队列（DC）	TextMsg	P, T	在DC出货时，货物通过RFID阅读程序进行登记
	statInfoOrderDC	队列（HQ）	StreamMsg	NP, NT	DC向HQ发送销售统计信息
	shipInfo	队列（SM）	TextMsg	P, T	SM收到DC发出的货物时，将其通过RFID阅读程序进行登记
	shipConf	队列（DC）	ObjectMsg	P, T	SM向DC发送收到货物的确认信息
2	callForOffers	主题（HQ）	TextMsg	P, T, D	DC请求所有的SP发送报价单（XML）
	offer	队列（DC）	TextMsg	P, T	SP向DC发送报价单（XML）
	pOrder	队列（SP）	TextMsg	P, T	DC向SP发出订单（XML）
	pOrderConf	队列 （DC）	TextMsg	P, T	SP向DC发送收到订单的确认信息（XML）
	invoice	队列 （HQ）	TextMsg	P, T	SP向HQ发送订单发票（XML）
	pShipInfo	队列 （DC）	TextMsg	P, T	DC收到SP发出的货物时，将其通过RFID阅读程序进行登记
	pShipConf	队列 （SP）	TextMsg	P, T	DC向 SP发送收到货物的确认信息（XML）
	statInfoShipDC	队列 （HQ）	StreamMsg	NP, NT	DC向HQ发送购买统计清单
3	priceUpdate	主题 （HQ）	MapMsg	P, T, D	HQ向SM发送价格变更的信息
4	inventoryInfo	队列 （SM）	TextMsg	P, T	SM仓库的产品目录通过RFID阅读程序进行变更登记
5	statInfoSM	队列 （HQ）	ObjectMsg	NP, NT	SM向HQ发送销售的统计信息
6	productAnnouncement	主题（HQ）	StreamMsg	NP, NT, ND	HQ向SM传送发布新产品的信息
7	creditCardHL	主题（HQ）	StreamMsg	NP, NT, ND	HQ向SM发送信用卡活动表

 

水平拓扑结构

如前所述，水平拓扑结构的目标是测试系统在接收方数量不断增加的情况下的处理能力。为此，工作负荷将通过增加物理位置（SM、DC等）的数量而得以扩展，而每个位置的通信量却仍然保持不变。在运行基准测试之前，必须设置BASE扩展参数。当BASE增加时，全部消息的吞吐率将上升直至系统饱和。为了使运行有效（通过），所有的队列都必须是稳定的，且90％的传送时间不能超过5秒。

有效水平运行的基准度量指标称作SPECjms2007@Horizontal，它等于运行基准测试的BASE参数值。用户期望使用不断增加的BASE值运行多次测试，并且直到BASE值达到最大时，此运行仍然有效。后者将作为SPEC发布的正式结果被提交。

图4：水平拓扑结构的位置

图4显示了当BASE参数增加时，每种类型的位置数量是如何扩展的。由于参与者发起交互的频率是固定的，因此每个位置（接收方）的通信量保持不变。交互的相对重要性是根据详细的超市供应链的业务模型的来设置的，此模型捕捉了交互的相关性。该模型有若干个输入参数（如产品类型的总数、超市的规模和每周销售产品平均数量），在选择输入参数值时应尽可能实现全面的目标消息传递组合：

• 50%的P2P消息和50%的pub/sub消息；
• 50%的P2P持久性消息和50%的非持久性消息；
• 25%的持久性pub/sub消息和75%的非持久性消息。

目标是使P2P通信和pub/sub消息传递具有同样的重要性。在各组内，持久性通信和非持久性通信的目标相对重要性是根据在现实的应用中这些通信类型的相关应用来设置的。图5显示了在水平拓扑结构中的消息组合。当扩展工作负荷时，不同消息类型的比例保持不变。在不同交互中用到的消息大小的选定是为了能够反映在现实的MOM应用程序中典型的消息大小。由于传送机制的非耦合性，所以Pub/sub消息通常比P2P消息小。

图5：水平拓扑结构消息组合

垂直拓扑结构

垂直拓扑结构使用一组固定的物理位置，并通过增加执行交互的频率来扩展工作负荷。与水平拓扑结构一样，它使用参数BASE作为比例因子，用户将根据需要扩展工作负荷，直到BASE达到最高，且仍然能够满足一次有效运行。SPECjms2007@Vertical是垂直拓扑结构的基准度量指标。同样，交互的相对重要性是根据供应链场景的业务模型来设置的。然而，和水平拓扑结构不同，垂直拓扑结构强调P2P消息传递，该消息传递占80%的通信量。

其目的是测试系统在接收方通信量不断增加时并行处理消息的能力。对于MOM服务器在此方面的性能，P2P消息传递（队列）要比pub/sub消息传递具有更为密切的相关性。在pub/sub消息传递中，根据用户处理接收消息的速度来看，消息的吞吐量在本质上是有限的。图6显示了垂直拓扑结构实现的消息组合。同样，在扩展工作负荷时，消息组合仍然保持不变，这是预期的行为。

图6：垂直拓扑消息组合

结束语

SPECjms2007是一款灵活且稳健的工具，它能够对MOM服务器的性能进行深入评估。该基准测试工具允许用户根据自己的需要自定义工作负荷，通过配置工作负荷来强调MOM基础架构的特定特性，这在某种程度上类似于一个特定的目标用户的工作负荷。然而，为了利用这一点，用户需要了解工作负荷的构成方式和各组件所测试的性能方面。在本文中，我们首先介绍了SPECjms2007建立的业务场景和工作负荷模型，然后探究了基准测试的设计和内部架构。通过研究交互、消息组合和它们的扩展方式，我们呈现了工作负荷的特征。一方面，由于此特征帮助用户增强了对SPECjms2007工作负荷的深入理解，所以他们能正确地解释基准测试工具的输出结果。另一方面，根据这些信息，用户可以根据他们的需要来设计工作负荷。

SPECjms2007为测试MOM服务器的性能和可伸缩性提供了一个有代表性的工作负荷场景。它有以下用途：

• 比较各种不同的MOM平台（包括硬件和软件）在性能和可伸缩性方面的差异；
• 研究不同配置选择和调整MOM平台参数对系统总体性能的影响；
• 重点测试MOM平台并分析其潜在的瓶颈；
• 构建自定义工作负荷，强调MOM性能的特定方面。

　　 ISO（Internet Standard Organization，国际标准组织）对OSI（Open System Interconnect，开放系统互连）七层网络模型的定义。是目前网络协议设计和统一的参考模型。

　　 建立七层模型的主要目的是为解决异种网络互连时所遇到的兼容性问题。它的最大优点是将服务、接口和协议这三个概念明确地区分开来：服务说明某一层为上一层提供一些什么功能，接口说明上一层如何使用下层的服务，而协议涉及如何实现本层的服务；这样各层之间具有很强的独立性，互连网络中各实体采用什么样的协议是没有限制的，只要向上提供相同的服务并且不改变相邻层的接口就可以了。
　　网络分层体现了在许多工程设计中都具有的结构化思想。 在各层分别定义标准接口，使具备相同对等层的不同网络设备能实现互操作，各层之间则相对独立，一种高层协议可放在多种低层协议上运行；
　　网络七层的功能 
       

       OSI七层模型的协议堆栈分别为： 

　　第一层—物理层：物理层定义了通讯网络之间物理链路的电气或机械特性，以及激活、维护和关闭这条链路的各项操作。物理层特征参数包括：电压、数据传输率、最大传输距离、物理连接媒体等。

　　第二层—数据链路层：实际的物理链路是不可靠的，总会出现错误，数据链路层的作用就是通过一定的手段（将数据分成帧，以数据帧为单位进行传输）将有差错的物理链路转化成对上层来说没有错误的数据链路。它的特征参数包括：物理地址、网络拓朴结构、错误警告机制、所传数据帧的排序和流控等。其中物理地址是相对网络层地址而言的，它代表了数据链路层的节点标识技术；“拓朴”是网络中经常会碰到的术语，标记着各个设备以何种方式互连起来，如：总线型—所有设备都连在一条总线上，星型—所有设备都通过一个中央结点互连；错误警告是向上层协议报告数据传递中错误的发生；数据帧排序可将所传数据重新排列；流控则用于调整数据传输速率，使接收端不至于过载。
　
　　第三层—网络层：网络层将数据分成一定长度的分组，并在分组头中标识源和目的节点的逻辑地址，这些地址就象街区、门牌号一样，成为每个节点的标识；网络层的核心功能便是根据这些地址来获得从源到目的的路径，当有多条路径存在的情况下，还要负责进行路由选择。

　　第四层—传输层：提供对上层透明（不依赖于具体网络）的可靠的数据传输。如果说网络层关心的是“点到点”的逐点转递，那么可以说传输层关注的是“端到端”（源端到目的端）的最终效果。它的功能主要包括：流控、多路技术、虚电路管理和纠错及恢复等。其中多路技术使多个不同应用的数据可以通过单一的物理链路共同实现传递；虚电路是数据传递的逻辑通道，在传输层建立、维护和终止；纠错功能则可以检测错误的发生，并采取措施（如重传）解决问题。

　　第五层—会话层：在网络实体间建立、管理和终止通讯应用服务请求和响应等会话。

　　第六层—表示层：定义了一系列代码和代码转换功能以保证源端数据在目的端同样能被识别，比如大家所熟悉的文本数据的ASCII码，表示图象的GIF或表示动画的MPEG等。

　　第七层——应用层：应用层是面向用户的最高层，通过软件应用实现网络与用户的直接对话，如：找到通讯对方，识别可用资源和同步操作等。

　    网络七层的底三层（物理层、数据链路层和网络层）通常被称作媒体层，它们不为用户所见，对网络起到支撑作用，是网络工程师所研究的对象；
      上四层（传输层、会话层、表示层和应用层）则被称作主机层，是用户所面向和关心的内容，这些程序常常将各层的功能综合在一起，在用户面前形成一个整体。大家所熟悉的网上应用WWW、FTP、TELNET等，都是这多层功能的综合。

　 在数据的实际传输中，发送方将数据送到自己的应用层，加上该层的控制信息后传给表示层；表示层如法炮制，再将数据加上自己的标识传给会话层；以此类推，每一层都在收到的数据上加上本层的控制信息并传给下一层；最后到达物理层时，数据通过实际的物理媒体传到接收方。接收端则执行与发送端相反的操作，由下往上，将逐层标识去掉，重新还原成最初的数据。由此可见，数据通讯双方在对等层必须采用相同的协议，定义同一种数据标识格式，这样才可能保证数据的正确传输而不至走形。

　七层模型是一个理论模型，实际应用则千变万化，完全可能发生变异。对大多数应用，我们只是将它的协议族（即协议堆栈）与七层模型作大致的对应，看看实际用到的特定协议是属于七层中某个子层，还是包括了上下多层的功能。

　　 网络中实际用到的协议是否严格按照这七层来定义呢？并非如此，七层模型是一个理论模型，实际应用则千变万化，完全可能发生变异。何况有的应用由来已久，不可能在七层模型推出后又推翻重来。因此对大多数应用，我们只是将它的协议族（即协议堆栈）与七层模型作大致的对应，看看实际用到的特定协议是属于七层中某个子层，还是包括了上下多层的功能。我们在以前的篇幅中曾介绍过的TCP/IP协议，它与七层模型的对应关系如下：

　　OSL与TCP/IP模型的对应关系（简单图二）

　　应用层 *

　　表示层 应用层

　　会话层 *

　　传输层 传输层

　　网络层 网络层

　　数据链路层 网络接口层

　　物理层 *

　　 由图二可看出，TCP/IP的多数应用协议将OSI应用层、表示层、会话层的功能合在一起，构成其应用层，典型协议有：HTTP、FTP、TELNET等；TCP/UDP协议对应OSI的传输层，提供上层数据传输保障；IP协议对应OSI的网络层，它定义了众所周知的IP地址格式，做为网间网中查找路径的依据；TCP/IP的最底层功能由网络接口层实现，相当于OSI的物理层和数据链路层，实际上TCP/IP对该层并未作严格定义，而是应用已有的底层网络实现传输，这就是它得以广泛应用的原因。

在“WebSphere MQ程序设计初探”一文中，讨论了从MQ队列管理器的本地队列中放置和读出消息的程序，本文主要通过两台机器，搭建MQ消息传输的环境，并编写测试程序进行测试。 第一、准备工作 机器A：代码为00000000，IP地址为：10.1.1.1 机器B：代码为88888888，IP地址为：10.1.1.2 安装MQ 5.3 第二、创建MQ对象 A机器上： 1、打开“WebSphere MQ资源管理器”，新建队列管理器，名称为QM_00000000，其余采用默认设置; 2、在QM_00000000队列管理器中创建本地队列，名称为LQ_00000000; 3、创建传输队列，名称为XQ_88888888（新建时选择“本地队列”，将“用法”设置为“传输”）; 4、创建远程队列定义，名称为RQ_88888888，指定远程队列名称为LQ_88888888，远程队列管理器名称为QM_88888888，传输队列名称为XQ_88888888; 5、创建发送方通道，名称为00000000.88888888，传输协议为TCP/IP，连接名称为10.1.1.2(1414)，传输队列为XQ_88888888; 6、创建接受方通道，名称为88888888.00000000，采用默认设置； 7、创建服务器连接通道，名称为DC.SVRCONN，采用默认设置（该通道主要给后面的测试程序使用）。 B机器和A机器上的操作一样，只是命名不同，如下： 1、打开“WebSphere MQ资源管理器”，新建队列管理器，名称为QM_88888888，其余采用默认设置; 2、在QM_88888888队列管理器中创建本地队列，名称为LQ_88888888; 3、创建传输队列，名称为XQ_00000000（新建时选择“本地队列”，将“用法”设置为“传输”）; 4、创建远程队列定义，名称为RQ_00000000，指定远程队列名称为LQ_00000000，远程队列管理器名称为QM_00000000，传输队列名称为XQ_00000000; 5、创建发送方通道，名称为88888888.00000000，传输协议为TCP/IP，连接名称为10.1.1.1(1414)，传输队列为XQ_00000000; 6、创建接受方通道，名称为00000000.88888888，采用默认设置； 7、创建服务器连接通道，名称为DC.SVRCONN，采用默认设置。 第三、消息测试 在A、B机器上分别启动其发送方通道，正常情况通道状态应为“正在运行”。 通过如下测试程序进行测试，文件名为：MQTest.java，在机器A上进行运行（如在B上运行请读者自行适当修改）。 ------------------------------------------------------------------------------------------- import java.io.IOException; import java.util.Hashtable; import com.ibm.mq.MQException; import com.ibm.mq.MQMessage; import com.ibm.mq.MQPutMessageOptions; import com.ibm.mq.MQQueue; import com.ibm.mq.MQQueueManager; public class MQSample{      //定义队列管理器和队列的名称      private static String qmName = "QM_00000000";      private static String qName = "RQ_88888888";           private static MQQueueManager qMgr;      private static Hashtable properties = new Hashtable();      public static void main(String args[]) {          try {              properties.put("hostname", "10.1.1.1");              properties.put("port", new Integer(1414));              properties.put("channel", "DC.SVRCONN");              properties.put("CCSID", new Integer(1381));              properties.put("transport","MQSeries");                           // Create a connection to the queue manager              qMgr = new MQQueueManager(qmName,properties);              // Set up the options on the queue we wish to open...              int openOptions = 16;              // Now specify the queue that we wish to open,              // and the open options...              MQQueue remoteQ = qMgr.accessQueue(qName, openOptions);                           // Define a simple WebSphere MQ message, and write some text in UTF format..              MQMessage putMessage = new MQMessage();              putMessage.writeUTF("Test");              // specify the message options...              MQPutMessageOptions pmo = new MQPutMessageOptions();              // accept the defaults, same as MQPMO_DEFAULT              // put the message on the queue              remoteQ.put(putMessage,pmo);              System.out.println("Message has been input into the Remote Queue");              // Close the queue...              remoteQ.close();              // Disconnect from the queue manager              qMgr.disconnect();          }catch (MQException ex) {              // If an error has occurred in the above, try to identify what went wrong              // Was it a WebSphere MQ error?              System.out.println("A WebSphere MQ error occurred : Completion code " + ex.completionCode +           " Reason code " + ex.reasonCode);          }catch (IOException ex) {              // Was it a Java buffer space error?              System.out.println("An error occurred whilst writing to the message buffer: " + ex);          }catch(Exception ex){              ex.printStackTrace();          }      } } ------------------------------------------------------------------------------------------- 运行程序后，请在B机器的本地队列LQ_88888888中检查是否有消息存在，如果有说明测试成功。

ASP.NET 常见参考项目的 UI、BLL 、Model 、 DAL 分析。2008-03-12 10:32<转载>


个人感觉数据访问层应该实现以下几个主要目的：

1） 分离业务层与数据层

2）屏蔽具体数据库的差异（如SQLServer、Oracle、OLEDB、ODBC等）

3）简化数据访问层的代码，经常写一些 Parameter 的设定是很无聊的事情）

先下载并研究了一下Enterprise Library 2.0 ，发现其中的Data Access Application Block有点复杂了，有近 40 个类文件，还需要引用 Configuration、Common、ObjectBuilder 等项目，本身就是一个很大的项目了... 个人觉得还不如上一个版本中的 SQLHelper 对象那么简单方便（Pet Shop 4.0 中的 DabaAccess 项目里就是用 OracleHelper和SQLHelper来实现的）

再来研究Pet Shop 4.0 ，其中主要对象层次一般是（假设Model是业务对象）：

ModelInfo <- Model -> IDAL <- SQLServerDAL(或OracleDAL)

其中：

ModelInfo 是瘦的业务实体数据对象
Model 实现 ModelInfo 的管理（增、删、改、查询）等，调用 IDAL 来实现
IDAL 是数据访问层的接口定义
SQLServerDAL 是 IDAL 在 SQLServer 上的实现，如果是 Oracle，可以利用 OracleDAL 来实现
貌视还不错的结构，只是 DAL 层的里面的代码还是比较多，好多SQL、好多Parameter的操作

再看看 Visual Studio 2005 中带的"个人网站的初学者工具包"的数据访问代码，它只是简单在App_Code中有 Model(瘦的业务实体数据对象)、ModelManager(管理对象，数据层的访问也在其中实现)的两个对象，数据库也只是SQL Server，较为简单，但也不易扩展。

我的一点想法：

1）Enterprise Library 2.0 有些庞大和重量级，学习曲线太长，谨慎使用

2）Visual Studio 2005 中的数据集对象（DataSet）是个好东西，可以简化很多SQL语句的编写和参数的设定

3）Pet Shop 4.0 的总体架构还是不错的（Model <- ModelInfo -> IDAL <- SQLServerDAL），值得参考，但是在SQLServerDAL 和 OracleDAL 不用手动去编写代码，而是调用利用 DataSet 自动生成的代码来实现（SQLServer、Oracle、OLEDB或ODBC等），简单的业务对象管理动作应該是能直接利用DataSet提供的方法 直接实现，如果是复杂的数据层操作，可以自己编写代码来实现（如多个表之间的数据操作）

4）musicland 和 JGTM 2006 也提供了一种不错的实现方式，具体参考这篇Post

这样的话，开始提到的三个目的都能达到了。

.
应用/项目名称
UI层实现
Business Model & Logic Layer 实现
Data Access Layer 实现
Personal Web Site Starter Kit
在ASP.NET页面上直接利用 ObjectDataSource 来绑定 PhotoManager 中的方法来获取数据、更新数据
两个数据实体类（Album、Photo），一个管理类（PhotoManager）
自行解决数据库连接、使用 SqlCommand 来调用存储过程来完成

Club Web Site Starter Kit   
在ASP.NET页面上直接利用 SqlDataSource 来获取数据、更新数据
只有一些简单的 Helper/Utility类，业务逻辑大多在页面上实现
有一个DataSet，提取 Member表的数据，在自己的数据库中扩充了 SqlMembershipProvider的字段
Classifieds Site Starter Kit


在ASP.NET页面上，增/删/改主要是利用FormView调用BLL中的ModelDB来实现，数据列表主要利用ModelCache的List和ModelDB返回的ModelDataTable来绑定
1) BLL中实现了 ModelDB的类，调用DAL中的DataSet来进行数据更新，如果是查询数据（GetModelList），则得到 ModelDataComponent.ModelDataTable，这是数据集自动生成代码中的一个类

2) 在 App_Code 的Web目录中，主要实现了部分实体在 HTTP Context中的Cache功能，建立了 CachedModel（数据实体类）及其管理对象 ModelCache，后者主要是将BLL层的ModelDB的Retrive结果DataTable转成 List

全是ASP.NET 2.0 中的DataSet，实现了所有表数据的获取与更新，它是调用存储过程来实现的
Commerce Starter Kit



在ASP.NET页面上，有一些是直接调用 ModelManager对象来完成用户交互，有一些则是利用 ObjectDataSource 绑定 ModelManager 来达到同样功能对于某些操作，如果没有对应的 ModelManager 则直接使用 SqlDataSource

1) 在Objects目录下，定义了数据实体类，包含所有属性的Get/Set方法的定义，没有实例化方法，而是使用 void Load(IDataReader)来初始化，其中有一个对象（ShoppingCartItems），则继承至DataTable，利用 BuildDataTable（）来进行初始化2) 利用数个 ModelProvider 将与数据库的主要交互功能封装起来，提供了实体层次的CRUD

3) 在 BLL 目录下，有数个 ModelManager，提供从业务层面对 Model 的操作，其中主要是调用 ModelProvider来完成具体的操作 在 ModelProvider项目中中，先定义ModelProvider抽象类，再由 SqlModelProvider 来继承，后者中利用 SqlHelper 来完成数据访问，主要是调用存储过程
全是ASP.NET 2.0 中的DataSet，实现了所有表数据的获取与更新，它是调用存储过程来实现的
Commerce Starter Kit

在ASP.NET页面上，有一些是直接调用 ModelManager对象来完成用户交互，有一些则是利用 ObjectDataSource 绑定 ModelManager 来达到同样功能对于某些操作，如果没有对应

1) 在Objects目录下，定义了数据实体类，包含所有属性的Get/Set方法的定义，没有实例化方法，而是使用 void Load(IDataReader)来初始化，其中有一个对象（ShoppingCartItems），则继承至DataTable，利用 BuildDataTable（）来进行初始化
2) 利用数个 ModelProvider 将与数据库的主要交互功能封装起来，提供了实体层次的CRUD

3) 在 BLL 目录下，有数个 ModelManager，提供从业务层面对 Model 的操作，其中主要是调用 ModelProvider来完成具体的操作
在 ModelProvider项目中中，先定义ModelProvider抽象类，再由 SqlModelProvider 来继承，后者中利用 SqlHelper 来完成数据访问，主要是调用存储过程
Duwamish 7.1
(.NET 1.1）
调用BusinessFacade中的 OrderSystem 和 ProductSystem 中的方法完成用户交互，这主要是调用DAL层的相关对象来完成的
1) ModelData，继承自System.Data.DataSet，在构造函数里调用BuildDataTables()来初始化一个DataTable
2) 在用来存储Model数据
BusinessFacade和BusinessRule中，实现了与业务逻辑有关的内容，调用数据层的 Models 来完成数据访问
实现了数个 Models对象，提供了对于 ModelData的CRUD方法，它也是调用 SqlHelper 来完成与数据库的交互
Jobs Site Starter Kit   
利用 ObjectDataSource 绑定 Model 类，Command 主要是调用 Model 的 CRUD方法
在 Model 对象中定义了所有属性和CRUD方法，实现时调用了 DAL 的 DBAccess 对象，也使用了诸如 SqlParameter 等对象
只有一个类 DBAccess ，属于工具类，类似于 SqlHelper，它是利用 System.Data.SqlClient 来实现的，如果向其他数据库移植，代码量不大

大多数是调用 Model有直接调用 SqlDataProvider 来获取数据、更新
数据 在Dottext.Framework 的 Component 中定义了业务实体 Model 和 ModelCollection，在在Dottext.Framework定义了 Models 类，主要用提供 Model 的 CRUD 方法，其中的 R 返回 ModelCollection
Text 0.95
(.NET 1.1) 在Dottext.Framework 的 Data 中定义了 IDbProvider和 IDTOProvider 接口，然后提供了 DataDTOProvider 和 SqlDbProvider 的实现，其中调用了 SqlHelper 类
Community Server 2.1 SDK
(.NET 1.1 & 2.0)
直接调用 Models 的方法来获取数据、更新数据等
在 CommunityServerComponents 项目的 Components 中定义 Model 类，其中仅包含属性定义及构造 函数，另外定义了 Models 类，其中实现了 Model 的 CRUD 方法，它是调用 Provider 下的 CommonDataProvider 来完成数据访问的
在 CommunityServerComponents 项目的 Proivder 中，利用抽象CommonDataProvider 定义了所有 BLL & Model 层类需要的数据访问方法，然后在 SqlDataProvider 中项中使用 SqlDataProvider 继承此类，完成与 SQL Server 数据库的交互

在 ASP.NET 的页面上，大多是利用代码来调用 BLL 层的 Model 对象来获取数据、更新数据
Model 项目 中定义了所有的业务实体 ModelInfo
BLL 项目中定义业务实体 Model ，其中包含业务视角的 CRUD 方法，它们是调用 IDAL 中的 IModel 的 CRUD 方法来实现的 IDAL 项目中有多个接口定义 IModel，其中定义了需要实现的 Model 的 CRUD 方法

.Pet Shop 4.0
SqlServerDAL 和 OracleDAL 分别在两种数据库上实现了 IDAL
DALFactory 为工厂类，负责根据配置返回相应的 IDAL 的 IModel 实现类DBUtility 是 SQL Server 和 Oracle 数据库操作的工具类，主要是 SQLHelper 和 OracleHelper

 

例：
>tracert IP
通过最多30个跃点跟踪到XX.XX.XX.XX路由

    为路由指定所需跃点数的整数值（范围是 1 ~ 9999），它用来在路由表里的多个路由中选择与转发包中的目标地址最为匹配的路由。
    所选的路由具有最少的跃点数。
    跃点数能够反映跃点的数量、路径的速度、路径可靠性、路径吞吐量以及管理属性
    跃点数是为用于特殊网络接口的 IP 路由分配的值，用来标识与使用该路由有关的成本。
    例如，可以根据链接速度、跃点计数或时间延迟来计算跃点数。

   “自动跃点计数”是 Windows XP 中的一个新增功能，它可以自动为基于链接速度的本地路由配置跃点数。
     默认情况下，将启用“自动跃点计数”功能，也可以进行手动配置，为其赋予一个具体的跃点数。
     当路由表中包含用于同一目的地的多个路由时，“自动跃点计数”功能便非常有用。
     例如，如果您的计算机具有一个 10 兆位 (Mb) 的网络接口和一个 100 Mb 的网络接口，并且该计算机具有一个在两个网络接口上均已配置的默认网关，那么“自动跃点计数”功能就会为较慢的网络接口分配较高的跃点数。
     该功能会强制流向 Internet 的所有流量，例如，使用可用的最快网络接口。
    
    注意：通常情况下，Microsoft 不建议您跨越不相连的网络来添加默认网关。
    例如，诸如网络地址转换 (NAT) 服务器和代理服务器等边缘服务器，通常都被配置为连接两个或多个不相连的网络：公共 Internet 和一个或多个专用 Intranet。
    在这种情况下，不应在专用接口上分配默认网关，因为这样做有可能导致网络上的路由不正确。

select b.constraint_name, b.table_name, b.column_name  from user_cons_columns b


完整性约束是一种规则，不占用任何数据库空间，存在数据字典中。

Oracle提供了5种完整性约束： 
Check 　　　 NOT NULL 　　　 Unique 　　　 Primary 　　　 Foreign key

禁用约束:
ALTER TABLE table_name DISABLE CONSTRAINT constraint_name;
 或
ALTER TABLE policies DISABLE CONSTRAINT chk_gender
 

重新启用约束：
ALTER TABLE policies ENABLE CONSTRAINT chk_gender
 

删除约束:
ALTER TABLE table_name DROP CONSTRAINT constraint_name
或
ALTER TABLE policies DROP CONSTRAINT chk_gender;

更改表的约束 
CONSTRAINT [constraint_name] CHECK (condition);

http://www.knowsky.com/389195.html

如
 nested throwable: (java.sql.SQLException: ORA-00001: unique constraint (username.SYS_C000001) violated
--

select owner,CONSTRAINT_NAME,table_name from user_CONSTRAINTS where CONSTRAINT_NAME='SYS_C000001'