|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）数据信息的有效性。电子商务以电子形式取代了纸张，如何保证电子形式的贸易信息的有效性是开展电子商务的前提。因此要对网络故障、操作错误、应用程序错误、硬件故障、系统软件错误及计算机病毒所产生的潜在威胁加以控制和预防，以保证贸易数据在确定的时刻、确定的地点是有效的。
|
|
|
|
（2）数据信息机密性。电子商务作为贸易的一种手段，其信息代表着个人、企业甚至是国家的商业机密。传统的纸面贸易都是通过邮寄封装的信件或通过可靠的通信渠道发送商业报文来达到保守机密的目的。而通过电子商务系统进行电子商务活动是建立在一个开放的因特网环境之上的，维护商业机密是电子商务应用的重要保障。因此，要预防非法的信息存取和信息在传输过程中被非法窃取。
|
|
|
|
（3）数据信息完整性。电子商务简化了贸易过程，减少了人为的干预，但同时也带来维护贸易各方商业信息的完整、统一的问题。由于数据输入时的意外差错或欺诈行为，可能导致贸易各方信息的差异。此外，数据传输过程中信息的丢失、信息重复或信息传送的次序差异也会导致贸易各方信息的不同。贸易各方信息的完整性将影响到贸易各方的交易和经营策略，保持贸易各方信息的完整性是电子商务应用的基础。因此，要预防对信息的随意生成、修改和删除，同时要防止数据传送过程中信息的丢失和重复，并保证信息传送次序的统一。
|
|
|
|
（4）可靠性／不可抵赖性／鉴别。如何确定要进行交易的贸易方正是所期望的贸易方是保证电子商务顺利进行的关键。在传统的纸面贸易中，贸易双方通过在交易合同、契约或贸易单据等书面文件上手写签名或印章来鉴别贸易伙伴，确定合同、契约、单据的可靠性并预防抵赖行为的发生，这也就是人们常说的“白纸黑字”。在无纸化的电子商务方式下，通过手写签名和印章进行贸易鉴别是不可能的。因此，要在交易信息的传输过程中为参与交易的个人、企业或国家提供可靠的标识。
|
|
|
|
（5）数据信息的审查能力。根据机密性和完整性的要求，应对数据信息进行审查，并将审查结果进行记录。
|
|
|
|
|
|
电子商务系统的性能指标就是业务量。执行效率差的电子商务系统会引起客户不满，失去赚钱的机会。因为这些原因的存在，使监视电子商务系统的性能，识别性能故障，快速找到起因并解决问题成为所有电子商务系统操作中关键的部分。以WebSphere Application Server为例，电子商务系统运营监控的主要内容包括：
|
|
|
|
|
|
成功的性能监视可以帮助检测和纠正性能问题。在仔细分析性能监视之前，不妨简单了解一下三种监视尺度——最终用户视图、系统和应用程序健康、应用程序视图。
|
|
|
|
（1）最终用户视图。对于最终用户来说，你的电子商务系统是一个黑盒子。他们不知道（或不关心）有多少服务器、服务器在哪儿、服务器的硬件如何或者服务器使用哪种应用程序。用户只关心Web页面的显示速度。监视最终用户视图可以让你知道是否存在公共可视方面的性能问题。如果电子商务系统太慢，客户将放弃并离开。不应该等待客户抱怨才发现站点有问题。
|
|
|
|
（2）系统和应用程序健康。第二个监视尺度是查看电子商务系统的内部子系统并检查每个子系统的问题。典型的WAS Web站点有很多子系统，包括Web服务器、应用程序服务器、数据库、目录服务器和防火墙。任何一处都可能成为瓶颈！
|
|
|
|
在这个阶段，要试图找到有问题的组件并识别受限制的资源。可能发现网络带宽、后端连接、数据库的CPU或其他组件，它们中的任何一个都可能是资源的瓶颈。因此，必须监视所有的组件，包括应用程序服务器、数据库、网络和路由器。查看关键的因素并与正常的（预期状态）比较。如果找到了偏差，就更精确地调查这些部分。
|
|
|
|
系统健康视图经常提供了对受约束资源的认识，但是对于识别问题的根本起因不一定是充分的。对于运行在Java虚拟机（JVM）上的Java 2企业版（J2EE）应用程序代码来说这种情况很明显。例如，如果系统健康监视发现运行应用程序的服务器的CPU利用率很高并且某几个小服务程序的响应时间很长，实际根本的起因可能是应用程序中的某个不好的循环、同步问题或者数据库索引丢失。为了解决这个问题，你必须获取更多的信息来找出问题。
|
|
|
|
（3）应用程序视图。第三个监视的尺度是查看应用程序内部来帮助查找困难的应用程序问题。在某个快照提供给定实例的所有Java线程活动信息时，应用程序视图可以给你精确显示某个缓慢的小服务程序正在做什么的信息。深入查看应用程序的内部执行对于查找困难的性能问题是很重要的。
|
|
|
|
|
|
在最终用户视图尺度上，监视站点的“用户负载”、服务的事务和用户经历的响应时间。这些都是相同的基本监视数据点，你能在预生产性能和压力测试中捕捉到这些信息。
|
|
|
|
监视最终用户视图使你能追踪电子商务系统的响应时间是否在增加，请求是否在增加以及增加的速度，增加是否是正常的、预期的状态。监视的三个主要因素是：
|
|
|
|
|
|
|
|
|
|
通过检测用户请求的数量、输出和响应时间，能够知道站点显示的正常响应时间是否根据请求的容量而增加，或者必须仔细研究响应时间问题。例如，大量的并行客户端载入的测试结果显示当并行用户翻倍（从10个增加到20个）时，平均响应时间也翻倍（从150ms到301ms）。如果你监视到响应时间和用户请求都翻倍了，应该是站点的正常状态。监视器显示你有更多的负载，因此响应时间相应长一些。在实际运行前有效的性能测试和能力计划能帮助确定站点的饱和点。
|
|
|
|
如果站点接收到的增长的负载超过了计划估计的容量，考虑使用缩放技术处理过多的负载，同时维持响应时间不变。但是，如果监视显示响应时间翻倍了而请求没有成比例增加，你就必须使用到第二种监视尺度——系统健康，以找到系统中是否有未预计到的约束，以及在哪儿找到问题所在。
|
|
|
|
|
|
系统健康监视对于检测组件层的响应时间问题是很关键的。有很多监视器可以用于检测环境的全面健康状况、趋势并帮助解决问题。每个生产站点必须开发一个监视测量并决定对电子商务系统的每个组件使用哪种关键的监视器。监视系统健康使你可以了解电子商务系统上所有组件的关键信息，帮助定位受约束的资源。一旦找到了这些资源，需要进一步发现和解决约束的起因。对于WebSphere应用程序，需检查应用程序统计表和Web应用程序监视器、中间件运行时监视器和服务器监视器。
|
|
|
|
Web应用程序监视器。在最终用户视图中，并行请求、响应时间和输出是用户角度的标准。这三个主要的因素对于Web应用程序组件（例如Web页面、小服务程序、企业JavaBean）的每个服务器层来说也适用。查看每一层的响应时间和请求数量能帮助识别可以在哪儿找到问题。例如，如果应用程序服务器上的响应时间和请求数量显示正常，就知道将研究焦点集中于Web服务器、网络和客户请求与应用程序服务器之间的其他组件。
|
|
|
|
对于典型的WAS开发，用户的请求通过HTTP服务器传递，接着调用在应用程序服务器上配置的一个小服务程序。可以监视HTTP服务器和应用程序服务器上的应用程序性能。根据特定的监视工具和使用的HTTP服务器，你可以监视HTTP服务器的任何一个或所有三个主要因素。
|
|
|
|
50个客户端负载的状态快照运行并显示，在这种特别的刷新间隔中，处理了50个请求。不幸的是，这个特定的Apache监视工具没有提供把计数器复位为0的简单方法，因此总共的访问（请求）和每秒钟的请求覆盖了6个小时的服务器周期，并且没有与WebSphere监视器相应的时间间隔。
|
|
|
|
中间件运行时监视器。可能需要通过监视缓冲池的利用请求，监视电子商务系统上流动的请求的健康。对于查询网络中的每个缓冲池或容器，查看利用情况。对于IBM HTTP服务器，可监视当前正在处理的请求和空闲服务器。
|
|
|
|
也可监视Web容器的线程池——对象请求代理程序（Object Request Broker，ORB）和数据库连接池。如果任何一个缓冲池达到了最大的容量，它就可能阻塞了业务流。通常，较大对于性能不一定更好，因为额外的容量浪费了资源。因此，队列和缓冲池的适当协调对于最佳性能是很重要的。
|
|
|
|
对于所有的WebSphere线程和连接池，高百分比的最大值显示特定缓冲池可能引起瓶颈。你能使用另外的监视器（例如缓冲池尺寸）和活动线程来帮助协调缓冲池。
|
|
|
|
服务器监视器。中间件和Web应用程序在下层服务器上执行。你必须查看所有服务器（包括Web服务器、应用程序服务器和数据库服务器）的系统监视器——CPU利用率、I/O和分页。
|
|
|
|
|
|
当引起性能问题的原因在Java应用程序中的时候，必须能够监视在JVM中执行的应用程序内部发生了什么事情以识别有问题的源。典型的应用程序视图层次的监视需要大量的J2EE编码和具体应用程序的相关知识。解决表面上是负载问题的Java应用程序问题可能需要这个层次的监视。你可以从两个角度分析运行在WebSphere上的应用程序：①应用程序调用流和响应时间情况；②线程状态执行情况。
|
|
|
|
从应用程序调用流角度看，需要查找消耗最大响应时间的应用程序部分。调用流可能显示某个小服务程序作了多重EJB调用，而每一个EJB调用作了多重JDBC调用。分析调用流可以识别应用程序消耗最多时间的部分。
|
|
|
|
作为分析应用程序调用流的补充，可以检查JVM中的每个线程的状态。线程状态执行情况监视某个时间应用程序内的每个线程的行动。通过查看线程栈中的结构，可以识别并行瓶颈。例如，修改了HitCount小服务程序来调用缓慢的同步日志程序（通常的问题）。在运行修改过的HitCount时，执行了线程转储。运行50个线程时，39个是栈顶部结构，9个在等待来自Web服务器的工作。线程栈信息使你能与Web应用程序开发人员一起排除可伸缩性瓶颈。
|
|
|
|
|
|
大多数操作系统和应用程序包含了接口以获得关键的性能指示并为监视性能提供基础的工具。此外某些行业方案有具体产品的性能接口以提供端对端性能监视方案或者专业的监视方案。
|
|
|
|
WAS运行是允许轻量级的、关键的运行时和Web应用程序性能因素的服务器端性能数据集合。WAS的一部分——性能监视基础结构（PMI），支持多种客户端检索选择，包括Java和HTTP/XML接口。
|
|
|
|
|
|
性能监视对于电子商务系统的成功是很关键的。了解每个监视尺度的角色将帮助你在性能问题影响Web站点前识别、定位和解决它们。有了Web Sphere API和支持工具，你能监视每个尺度来确保电子商务系统的最佳性能。
|
|
|
|
|
|
电子商务系统要能安全运行，除了有一定的软硬件安全保证之外，还要有一定的规章制度来规范电子商务管理人员。以下是电子商务系统安全运行的规章制度范例：
|
|
|
|
|
|
第一条为加强××电子商务系统的管理、使用、维护，保证网络和系统的安全运行，规范网络管理人员的行为，促进系统健康发展，根据国家有关法律法规，制定本管理规定。
|
|
|
|
|
|
|
|
（二）负责系统业务管理的×××具有相应的计算机信息网络、装备以及相应的技术人员和管理人员；
|
|
|
|
|
|
|
|
第三条电子商务系统建立相应的网络管理机构，依照国家法律和有关规定负责对本网站及其网管维护人员进行管理，做好网络信息安全工作。
|
|
|
|
|
|
第四条网管人员负责收集、整理因特网用户及电子商务系统用户提出的有关问题，及时答复客户问题；负责网站电子信箱及其他相关业务的管理。
|
|
|
|
第五条网管人员必须始终监控系统的安全运营，发现系统内容有异常情况，应立即向有关领导汇报，并根据领导指示及时做出相应处理。
|
|
|
|
第六条电子商务系统应当遵守国家有关法律、行政法规，严格执行国家安全保密制度，网站内容不得含有且网管人员不得制作、复制、查阅和传播下列信息：
|
|
|
|
|
|
|
|
|
|
|
|
（五）捏造或者歪曲事实，散布谣言，扰乱社会秩序的；
|
|
|
|
（六）宣扬封建迷信、淫秽、色情、赌博、暴力、凶杀、恐怖，教唆犯罪的；
|
|
|
|
|
|
|
|
|
|
（十）发现有害信息应当及时向有关主管部门报告，并采取有效措施，不得使其扩散。
|
|
|
|
|
|
第七条网管人员对发布的信息和个人进行登记，并对所提供的信息内容按照本规定进行审核。
|
|
|
|
第八条建立信息发布日志，系统管理员负责记录每次信息发布时间，做好发布信息审批表及原始资料的归档工作。
|
|
|
|
第九条网管人员负责建立计算机信息网络电子公告系统的用户登记和信息网络管理制度。
|
|
|
|
|
|
|
|
（一）负责本网络的安全保护管理工作，建立健全安全保护管理制度；
|
|
|
|
（二）落实安全保护技术措施，保障本网络的运行安全和信息安全；
|
|
|
|
|
|
|
|
（五）按照国家有关规定，删除本网络中含有有害信息内容的地址、目录或者关闭服务器。
|
|
|
|
第十一条网管人员不得从事下列危害计算机信息网络安全的活动：
|
|
|
|
（一）未经允许，进入计算机信息网络或者使用计算机信息网络资源的；
|
|
|
|
（二）未经允许，对计算机信息网络功能进行删除、修改或者增加的；
|
|
|
|
（三）未经允许，对计算机信息网络中存储、处理或者传输的数据和应用程序进行删除、修改或者增加的；
|
|
|
|
|
|
|
