大学生java学习心得精选多篇.docx
《大学生java学习心得精选多篇.docx》由会员分享，可在线阅读，更多相关《大学生java学习心得精选多篇.docx（40页珍藏版）》请在冰点文库上搜索。
大学生java学习心得精选多篇
大学生java学习心得（精选多篇）.netpermission,,,以便加强先前所列出的编程限制。
许多ejb容器没有加强这些限制，他们希望ejb组件开发者能遵守这些编程限制或者是带有冒险想法违背了这些限制。
违背这些限制的ejb组件，比标准方法依赖过多或过少的安全许可，都将很少能在多个ejb容器间移植。
另外，代码中都将隐藏着一些不确定的、难以预测的问题。
所有这些都足以使ejb组件开发者应该知道这些编程限制，同时也应该认真地遵守它们。
任何违背了这些编程限制的ejb组件的实现代码在编译时都不能检查出来，因为这些特点都是java语言和j2se中不可缺少的部分。
对于ejb组件的这些限制同样适用于ejb组件所使用的帮助/访问（helper/access）类，j2ee应用程序使用java文档（jar）文件格式打包到一个带.ear（代表enterprisearchive）扩展名的文件中，这个ear文件对于发送给文件部署器来说是标准的格式。
ear文件中包括在一个或多个ejb－jar文件中的ejb组件，还可能有ejb－jar所依赖的库文件。
所有ear文件中的代码都是经过深思熟虑开发的应用程序并且都遵守编程限制和访问许可集。
未来版本的规范可能会指定通过部署工具来定制安全许可的能力，通过这种方法指定了一个合法的组件应授予的许可权限，也指定了一个标准方法的需求：
如从文件系统中读文件应有哪些要求。
一些ejb容器/服务器目前在它们的部署工具中都提供了比标准权限或多或少的许可权限，这些并不是ejb1.1规范中所需要的。
理解这些约束
ejb容器是ejb组件生存和执行的运行期环境，ejb容器为ejb组件实例提供了一些服务如：
事务管理、安全持久化、资源访问、客户端连接。
ejb容器也负责ejb组件实例整个生命期的管理、扩展问题以及并发处理。
所以，ejb组件就这样寄居在一个被管理的执行环境中－－即ejb容器。
因为ejb容器完全负责ejb组件的生命期、并发处理、资源访问、安全等等，所以与容器本身的锁定和并发管理相冲突的可能性就需要消除，许多限制都需要使用来填上潜在的安全漏洞。
除了与ejb容器责任与安全冲突的问题，ejb组件还意味着仅仅聚焦于商务逻辑，它依赖于ejb容器所提供的服务而不是自己来直接解决底层的系统层的问题。
可能的问题
通常，ejb组件在容器之间的移植不可避免地与如下问题相关：
1.它需要依靠的受限制的特点在特定ejb容器中没有得到加强。
2.它需要依靠的非标准的服务从容器中可获得。
为了保证ejb组件的可移植性和一致的行为，你应该使用一个具有与java2平台安全
策略集相一致的策略集的容器来测试ejb组件，并且其加强了前述的编程限制。
总结
ejb组件开发者应该知道这些推荐的关于ejb组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。
因为这些编程限制能阻止你使用标准的java语言的特点，违背了这些编程限制在编译时不会知道，并且加强这些限制也不是ejb容器的责任。
所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。
2.优化ejb
entitybean为在应用程序和设计中描述持久化商业对象（persistentbusinessobjects）提供了一个清晰的模型。
在java对象模型中，简单对象通常都是以一种简单的方式进行处理但是，很多商业对象所需要的事务化的持久性管理没有得到实现。
entitybean将持久化机制封装在容器提供的服务里，并且隐藏了所有的复杂性。
entitybean允许应用程序操纵他们就像处理一个一般的java对象应用。
除了从调用代码中隐藏持久化的形式和机制外，entitybean还允许ejb容器对对象的持久化进行优化，保证数据存储具有开放性，灵活性，以及可部署性。
在一些基于ejb技术的项目中，广泛的使用oo技术导致了对entitybean的大量使用，sun的工程师们已经积累了很多使用entitybean的经验，这篇文章就详细阐述的这些卡发经验：
*探索各种优化方法
*提供性能优化和提高适用性的法则和建议
*讨论如何避免一些教训。
法则1：
只要可以，尽量使用cmp
cmp方式不仅减少了编码的工作量，而且在container中以及container产生的数据库访问代码中包括了许多优化的可能。
container可以访问内存缓冲中的bean,这就允许它可以监视缓冲中的任何变化。
这样的话就在事物没有提交之前，如果缓存的数据没有变化就不用写到数据库中。
就可以避免许多不必要的数据库写操作。
另外一个优化是在调用find方法的时候。
通常情况下find方法需要进行以下数据库操作：
查找数据库中的纪录并且获得主键
将纪录数据装入缓存
cmp允许将这两步操作优化为一步就可以搞定。
[具体怎么做我也没弄明白，原文没有具体阐述]
法则2：
写代码时尽量保证对bmp和cmp都支持
许多情况下，ejb的开发者可能无法控制他们写的bean怎么样被部署，以及使用的container是不是支持cmp.
一个有效的解决方案是，将商业逻辑的编码完全和持久化机制分离。
再cmp类中实现商业逻辑，然后再编写一个bmp类，用该类继承cmp类。
这样的话，所有的商业逻辑都在cmp类中，而持久化机制在bmp中实现。
[我觉得这种情况在实际工作中很少遇到，但是作者解决问题的思路值得学习]
法则3：
把ejbstore中的数据库访问减小到最少。
如果使用bmp,设置一个缓存数据改变标志dirty非常有用。
所有改变数据库中底层数据的操作，都要设置dirty,而在ejbstore（）中，首先检测dirty的值，如果dirty的值没有改变，表明目前数据库中的数据与缓存的一致，就不必进行数据库操作了，反之，就要把缓存数据写入数据库。
法则4：
总是将从lookup和find中获得的引用进行缓存。
（cache）
引用缓存对sessionbean和entitybean都是适用的。
通过jndilookup获得ejb资源。
比如datasource,bean的引用等等都要付出相当大的代价。
因此应该避免多余的lookup.可以这样做：
将这些引用定义为实例变量。
从setentitycontext（sessionbean使用setsessioncontext）方法查找他们。
setentitycontext方法对于一个bean实例只执行一次，所有的相关引用都在这一次中进行查找，这样查找的代价就不是那么昂贵了。
应该避免在其他方法中查找引用。
尤其是访问数据库的方法：
ejbload（）和ejbstore（）,如果在这些频繁调用的方法中进行datasource的查找，势必造成时间的浪费。
调用其他entitybean的finder方法也是一种重量级的调用。
多次调用finder（）方法的代价非常高。
如果这种引用不适合放在setentitycontext这样的初始化时执行的方法中执行，就应该在适当的时候缓存finder的执行结果。
只是要注意的是，如果这个引用只对当前的entity有效，你就需要在bean从缓冲池中取出来代表另外一个实体时清除掉这些引用。
，这些操作应该在ejbactivate（）中进行。
法则5:
总是使用preparestatements
这条优化法则适用于所有访问关系数据库的操作。
数据库在处理每一个sqlstatement的时候，执行前都要对statement进行编译。
一些数据库具有缓存statement和statement的编译后形式的功能。
数据库可以把新的statement和缓存中的进行匹配。
然而，如果要使用这一优化特性，新的statement要必须和缓存中的statement完全匹配。
对于non-preparedstatement,数据和statement本身作为一个字符串传递，这样由于前后调用的数据不同而不能匹配，就导致无法使用这种优化。
而对于preparedstatement,数据和statement是分开传递给数据库的，这样statement就可以和cache中已编译的statement进行匹配。
statement就不必每次都进行编译操作。
从而使用该优化属性。
这项技术在一些小型的数据库访问中能够减少statement将近90%的执行时间。
法则6：
完全关闭所有的statement
在编写bmp的数据库访问代码时，记住一定要在数据库访问调用之后关闭statement,因为每个打开的statement对应于数据库中的一个打开的游标。
security
1．加密
对称加密
（1）分组密码
（2）流密码
常用的对称加密算法：
des和tripledes
blowfish
rc4
aes
非对称加密
常用的非对称加密算法
rsa
elgamal
会话密钥加密（对称加密和非对称加密一起使用）
常用的会话密钥加密协议
s/mime
pgp
ssl和tlsssl是在applicationlevelprotocal和transportprotocal之间的。
比如：
http和tcp/ip之间
ssl提供了服务器端认证和可选的客户端认证，保密性和数据完整性。
提供基于ssl方式的传输加密和认证，确保以下三种安全防护：
数据的机密性和准确性、
服务器端认证
客户端认证。
客户端认证比服务器端认证不很普遍的原因是每一个要被认证的客户都必须有一张verisign这样的ca签发的证书。
通常，在进行身份认证的时候，应当只接受一个ca，这个ca的名字包含在客户证书中。
由于不可能随意创建一个由指定ca签发的证书，所以这可以有效的防御通过伪造证书来进行的攻击尝试。
2．认证（authentication）
认证就是确定一条消息或一个用户的可靠性的过程。
1.消息摘要
md5
sha和sha-1
2.消息认证码（messageauthienticationcodes,mac）
3.数字签名
用户可以用自己的密钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名
数字签名可以
1）保证数据的完整性
2）验证用户的身份
数字签名采用一个人的私钥计算出来，然后用公钥去检验。
hash算法私钥加密
原报文――――――>;报文摘要（messagedigest）―――――>;数字签名
原报文和数字签名一起被发送到接受者那里，接受者用同样的hash算法得到报文摘要，然后用发送者的公钥解开数字签名。
比较是否相同，则可以确定报文确定来自发送者。
验证数字签名必须使用公钥，但是，除非你是通过安全的方式直接得到，否则不能保证公钥的正确性。
（数字证书可以解决这个问题）
一个接受者在使用公钥（publickey）检查数字签名（digitalsignature）的可信度时，通常先要检查收到的公钥（publickey）是否可信的。
因此发送方不是单单地发送公钥（publickey），而是发送一个包含公钥（publickey）的数字证书（cetificate）。
4.数字证书
数字证书是一个经证书授权中心数字签名的包含公开密钥所有者信息以及公开密钥的文件。
数字证书cetificate中包括：
i.用户的公钥（publickey）
ii.用户的一些信息，如姓名，email
iii.发行机构的数字签名（digitalsignature），用于保证证书的可信度
iv.发行机构的一些信息
数字证书的格式遵循x.509国际标准。
注意：
一个数字证书certificate并不适用于多种browser,甚至一种browser的多个版本。
数字标识由公用密钥、私人密钥和数字签名三部分组成。
当在邮件中添加数字签名时，您就把数字签名和公用密钥加入到邮件中。
数字签名和公用密钥统称为证书。
您可以使用outlookexpress来指定他人向您发送加密邮件时所需使用的证书。
这个证书可以不同于您的签名证书。
收件人可以使用您的数字签名来验证您的身份，并可使用公用密钥给您发送加密邮件，这些邮件必须用您的私人密钥才能阅读。
要发送加密邮件，您的通讯簿必须包含收件人的数字标识。
这样，您就可以使用他们的公用密钥来加密邮件了。
当收件人收到加密邮件后，用他们的私人密钥来对邮件进行解密才能阅读。
在能够发送带有数字签名的邮件之前，您必须获得数字标识。
如果您正在发送加密邮件，您的通讯簿中必须包含每位收件人的数字标识。
数字证书，可以是个人证书或web站点证书，用于将身份与"公开密钥"关联。
只有证书的所有者才知道允许所有者"解密"或进行"数字签名"的相应"私人密钥"。
当您将自己的证书发送给其他人时，实际上发给他们的是您的公开密钥，这样他们就可以向您发送只能由您使用私人密钥解密和读取的加密信息。
通过浏览器使用数字证书，必须先要设置浏览器软件internetexplorer或netscape使用此证书，才能开始发送加密或需要数字签名的信息。
访问安全的web站点（以"https"打头的站点）时，该站点将自动向您发送他们的web站点证书。
3．ca（证书授证中心）
ca机构，又称为证书授证（certificateauthority）中心，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。
ca中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。
ca机构的数字签名使得攻击者不能伪造和篡改证书。
在set交易中，ca不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。
它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。
对证书的信任基于对根证书的信任.例如在申请sheca的个人数字证书前，需要先下载根证书，然后再进行各类证书的申请。
下载根证书的目的：
网络服务器验证（s）；安全电子邮件（e）
申请个人数字证书可以为internet用户提供发送电子邮件的安全和访问需要安全连接（需要客户证书）的站点。
1）个人数字证书
a.个人身份证书
个人身份证书是用来表明和验证个人在网络上的身份的证书，它确保了网上交易和作业的安全性和可靠性。
可应用于：
网上炒股、网上理财、网上保险、网上缴费、网上购物、网上办公等等。
个人身份证书可以存储在软盘或ic卡中。
b.个人安全电子邮件证书
个人安全电子邮件证书可以确保邮件的真实性和保密性。
申请后一般是安装在用户的浏览器里。
用户可以利用它来发送签名或加密的电子邮件。
用户在申请安装完安全安全电子邮件数字证书后，就可以对要发送的邮件进行数字签名。
收信人收到该邮件后，就可以看到数字签名的标记，这样就可以证明邮件肯定来自发信者本人，而不是别人盗用该帐号伪造信件，同时也保证该邮件在传送过程中没被他人篡改过任何数据。
安全电子邮件中使用的数字证书可以实现：
保密性通过使用收件人的数字证书对电子邮件加密。
如此以来，只有收件人才能阅读加密的邮件，在internet上传递的电子邮件信息不会被人窃取，即使发错邮件，收件人也无法看到邮件内容。
认证身份在internet上传递电子邮件的双方互相不能见面，所以必须有方法确定对方的身份。
利用发件人数字证书在传送前对电子邮件进行数字签名即可确定发件人身份，而不是他人冒充的。
完整性利用发件人数字证书在传送前对电子邮件进行数字签名不仅可确定发件人身份，而且传递的电子邮件信息也不能被人在传输过程中修改。
不可否认性由于发件人的数字证书只有发件人唯一拥有，故发件人利用其数字证书在传送前对电子邮件进行数字签名，发件人就无法否认发过这个电子邮件。
outlookexpress中的个人安全电子邮件证书
签名邮件带有签名邮件图标。
签名邮件可能出现的任何问题都将在本信息之后可能出现的“安全警告”中得到描述。
如果存在问题，您应该认为邮件已被篡改，或并非来自所谓的发件人。
当收到一封加密邮件时，您应该可以自信地认为邮件未被任何第三者读过。
outlookexpress会自动对电子邮件解密，如果在您的计算机上装有正确的数字标识。
2）企业数字证书
a．企业身份证书
企业身份证书是用来表明和验证企业用户在网络上身份的证书，它确保了企业网上交易和作业的安全性和可靠性。
可应用于：
网上证券、网上办公、网上交税、网上采购、网上资金转帐、网上银行等。
企业身份证书可以存储在软盘和ic卡中。
b．企业安全电子邮件证书
企业安全电子邮件证书可以确保邮件的真实性和保密性。
申请后一般是安装在用户的浏览器里。
企业可以利用它来发送签名或加密的电子邮件。
可使用windowsxx中的证书服务来创建证书颁发机构（ca），它负责接收证书申请、验证申请中的信息（更多内容请访问：
（crl）。
通常，当用户发出证书申请时，在其计算机上的加密服务提供程序（csp）为用户生成公钥和私钥对。
用户的公钥随同必要的识别信息发送至ca。
如果用户的识别信息符合批准申请的ca标准，那么ca将生成证书，该证书由客户应用程序检索并就地存储。
4．set
安全接口层协议——ssl（securesocketslayer），并且已经几乎成为了目前www世界的事实标准。
这一标准使用公共密钥编码方案来对传输数据进行加密，在双方之间建立一个internet上的加密通道，从而使第三方无法获得其中的信息，其思路与目前流行的vpn方案大致相同，目的都是要保护数据不被XX的第三方所窃听，或即使窃听到也不知所云。
但就象vpn一样，ssl在认证方面没有任何作为，它们都需要通过另外的手段来确认身份和建立双方彼此间的信任，然后再通过ssl进行交易。
正是由于ssl标准在认证方面的缺憾，所以set才有存在的必要。
set（secureelectronictransactions）规范由mastercard和visa公司于1996年发布，专家们认为set是保证用户与商家在电子商务与在线交易中免受欺骗的重要手段。
传统的信用卡交易者总在担心不诚实的店员会将自己的信用卡号码透露给他人，而在线交易也是如此，持卡者总在担心服务器端的管理员会将信用卡号码泄露出去，或者担心黑客会在管理员不知情的情况下盗取信用卡号码。
事实上这些担心都是必要的，而set标准则可以保证用户的信用卡号码只传送给信用卡公司进行认证，不会被系统管理员看到，也不会留在交易服务器的硬盘上给黑客以可乘之机。
5．pki
pki是一种易于管理的、集中化的网络安全方案。
它可支持多种形式的数字认证:
数据加密、数字签字、不可否认、身份鉴别、密钥管理以及交叉认证等。
pki可通过一个基于认证的框架处理所有的数据加密和数字签字工作。
pki标准与协议的开发迄今已有15年的历史,目前的pki已完全可以向企业网络提供有效的安全保障。
pki是一种遵循标准的密钥管理平台,它能够为所有网络应用透明地提供采用加密和数字签名等密码服务所必需的密钥和证书管理。
pki必须具有
1）ca、
2）证书库、
3）密钥备份及恢复系统、
4）证书作废处理系统、
5）客户端证书处理系统
等基本成分,构建pki也将围绕着这五大系统来构建
一个pki由众多部件组成,这些部件共同完成两个主要功能:
1）为数据加密
2）创建数字认证。
服务器（即后端）产品是这一系统的核心,这些数据库管理着数字认证、公共密钥及专用密钥（分别用于数据的加密和解密）。
ca数据库负责发布、废除和修改x.509数字认证信息,它装有用户的公共密钥、证书有效期以及认证功能（例如对数据的加密或对数字签字的验证）。
为了防止对数据签字的篡改,ca在把每一数字签字发送给发出请求的客户机之前,需对每一个数字签字进行认证。
一旦数字认证得以创建,它将会被自动存储于x.500目录中,x.500目录为树形结构。
ldap（lightweightdirectoryaccessprotocol）协议将响应那些要求提交所存储的公共密钥认证的请求。
ca为每一用户或服务器生成两对独立的公共和专用密钥。
其中一对用于信息的加密和解密,另一对由客户机应用程序使用,用于文档或信息传输中数字签字的创建。
大多数pki均支持证书分布,这是一个把已发布过的或续延生命期的证书加以存储的过程。
这一过程使用了一个公共查询机制,x.500目录可自动完成这一存储过程。
影响企业普遍接受pki的一大障碍是不同ca之间的交叉认证。
假设有两家公司,每一家企业分别使用来自不同供应商的ca,现在它们希望相互托管一段时间。
如果其后援数据库支持交叉认证,则这两家企业显然可以互相托管它们的ca,因而它们所托管的所有用户均可由两家企业的ca所托管。
＊认证机关
ca是证书的签发机构,它是pki的核心。
众所周知,构建密码服务系统的核心内容是如何实现密钥管理,公钥体制涉及到一对密钥,即私钥和公钥,私钥只由持有者秘密掌握,无须在网上传送,而公钥是公开的,需要在网上传送,故公钥体制的密钥管理主要是公钥的管理问题,目前较好的解决方案是引进证书（certificate）机制。
证书是公开密钥体制的一种密钥管理媒介。
它是一种权威性的电子文档，形同网络计算环境中的一种身份证，用于证明某一主体（如人、服务器等）的身份以及其公开密钥的合法性。
在使用公钥体制的网络环境中,必须向公钥的使用者证明公钥的真实合法性。
因此,在公钥体制环境中,必须有一个可信的机构来对任何一个主体的公钥进行公证,证明主体的身份以及他与公钥的匹配关系。
ca正是这样的机构,它的职责归纳起来有:
1、验证并标识证书申请者的身份；
2、确保ca用于签名证书的非对称密钥的质量；
3、确保整个签证过程的安全性,确保签名私钥的安全性；
4、证书材料信息（包括公钥证书序列号、ca标识等）的管理；
5、确定并检查证书的有效期限；
6、确保证书主体标识的唯一性,防止重名；
7、发布并维护作废证书表；
8、对整个证书签发过程做日志记录；
9、向申请人发通知。
其中最为重要的是ca自己的一对密钥的管理，它必须确保其高度的机密性,防止他方伪造证书。
ca的公钥在网上公开,整个网络系统必须保证完整性。
＊证书库
证书库是证书的集中存放地,它与网上"白页”类似,是网上的一种公共信息库,用户可以从此处获得其他用户的证书和公钥。
构造证书库的最佳方法是采用支持ldap协议的目录系统,用户或相关的应用通过ldap来访问证书库。
系统必须确保证书库的完整性,防止伪造、篡改证书。
＊密钥备份及恢复系统
＊证书作废处理系统
＊pki应用接口系统
pki的价值在于使用户能够方便地使用加密、数字签名等安全服务，因此一个完整的pki必须提供良好的应用接口系统，使得各种各样的应用能够以安全、一致、可信的方式与pki交互，确保所建立起来的网络环境的可信性，同时降低管理维护成本。
最后，pki应用接口系统应该是跨平台的。
许多权威的认证方案供应商（例如verisign、thawte以及gte）目前都在提供外包的pki。
外包pki最大的问题是,用户必须把企业托管给某一服务提供商,即让出对网络安全的控制权。
如果不愿这样做,则可建造一个专用的pki。
专用方案通常需把来自entrust、baltimoretechnologies以及xce
升级会员 