J2EE经典学习笔记.doc

J2EE经典学习笔记
J2EE模式
Value Object(值对象) 用于把数据从某个对象/层传递到其他对象层的任意Java对象。
通常不包含任何业务方法。
也许设计有公共属性，或者提供可以获取属性值的get方法。
JSP
1．JSP的基础知识

__
_____ | directive (指令)
| |-- scripting （脚本）
JSP -------| |__ action （动作）
|
|_____Template data ：除JSP语法外，JSP引擎不能解读的东西

1）在JSP中使用的directive(指令)主要有三个：
a) page指令
b) include指令
c) taglib指令

在JSP的任何地方，以任何顺序，一个页面可以包含任意数量的page指令

2)Scripting（脚本）包括三种类型
a) <%！declaraction %>
b) <% scriptlet %>
c) <%= expression %>

3)action（动作）
标准的动作类型有：
a) <jsp:useBean>
b) <jsp:setProperty>
d) <jsp:getProperty>
e) <jsp:param>
f) <jsp:include>
g) <jsp:forward>
h) <jsp:plugin>

1. 注释： <% -----jsp comment-------%>
<! -----html comment-------%>

2. <%@ page session = “true” import =”java.util.*” %>
session可以不赋值，默认为true,如果session=”false”,则在JSP页面中，隐含的变量session就不能使用。

3. 请求控制器结构（Request Controller）
也被称之为JSP Model 2 Architecture
这种途径涉及到使用一个Servlet或一个JSP作为一个应用程序或一组页面的入口点。

为创建可维护的JSP系统，Request Controller是最有用的方式之一。

不是JSP，而是Java类才是放置控制逻辑的正确的地方。

请求控制器的命名模式为: xxxController.jsp
请求控制器类的命名模式为: xxxRequestController

2．JSP中的JavaBean
JSP三种bean的类型
1) 页面bean
2) 会话bean
3) 应用bean

大多数的系统会使用一个会话bean来保持状态，而对每一个页面使用一个页面bean 来对复杂的数据进行表示。

页面bean是一个模型，而JSP是一个视图。

3．Custom tag

bean是信息的携带者，
而tag更适用于处理信息。

标记库包含一个标记库描述符（TLD）和用于实现Custom tag的Java类
在翻译阶段，JSP容器将使用TLD来验证页面中的所有的tag是否都被正确的使用。

标记处理程序只是一个简单的适配器，而真正的逻辑是在另一个类中实现的，标记处理程序只是提供了一个供其他的可复用的类的JSP接口

Servlet
1．ServletConfig
? 一个ServletConfig对象是servlet container在servlet initialization的时候传递给servlet的。

ServletConfig包涵 ServletContext 和 一些 Name/Value pair (来自于deployment descriptor)

? ServletContext接口封装了Web应用程序的上下文概念。

2．会话跟踪
1) Session
? 当一个Client请求多个Servlets时，一个session可以被多个servlet共享。

? 通常情况下，如果server detect到browser支持cookie，那么URL就不会重写。

2) cookie
? 在Java Servlet中，如果你光 Cookie cookie = new Cookie(name,value)
那么当用户退出Browser时，cookie会被删除掉，而不会被存储在客户端的硬盘上。

如果要存储 cookie，需加一句 cookie.setMaxAge(200)

? cookie是跟某一个server相关的，运行在同一个server上的servlet共享一个cookie.

3) URL Rewriting
在使用URL Rewriting来维护Session ID的时候，每一次HTTP请求都需要EncodeURL()
典型的用在两个地方
1） out.print(“form action=\” ”);
out.print(response.encodeURL(“sessionExample”));
out.print(“form action=\” ”);
out.print(“method = GET>”);
2） out.print(“<p><a href=\” ”);
out.print(response.encodeURL(“SessionExample?database=foo&datavalue=bar”));
out.println(“\” >URL encoded </a>”);

3．SingleThreadModel
默认的，每一个servlet definition in a container只有一个servlet class的实例。
只有实现了SingleThreadModel，container才会让servlet有多个实例。

Servlet specification上建议，不要使用synchronized，而使用SingleThreadModel。

SingleThreadModel（没有方法）
保证servlet在同一时刻只处理一个客户的请求。
SingleThreadModel是耗费资源的，特别是当有大量的请求发送给Servlet时，SingleThreadModel的作用是使包容器以同步时钟的方式调用service方法。
这等同于在servlet的service()方法种使用synchronized.

Single Thread Model一般使用在需要响应一个heavy request的时候，比如是一个需要和数据库打交道的连接。

2. 在重载Servlet地init( )方法后，一定要记得调用super.init( );

3. the client通过发送一个blank line表示它已经结束request
而the server通过关闭the socket来表示response已结束了。

4. 一个Http Servlet可以送三种东西给Client
1) a single status code
2) any number of http headers
3) a response body

5. Servlet之间信息共享的一个最简单的方法就是
System.getProperties().put(“key”,”value”);

6. Post和Get
Post：将form内各字段名称和内容放置在html header内传送给server
Get: ?之后的查询字符串要使用URLEncode，经过URLEncode后，这个字符串不再带有空格，以后将在server上恢复所带有的空格。

Get是Web上最经常使用的一种请求方法，每个超链接都使用这种方法。

7. Web.xml就是Web Applicatin 的deployment descriptor
作用有：组织各类元素
设置init param
设置安全性

8. Request Dispatcher用来把接收到的request forward processing到另一个servlet
要在一个response里包含另一个servlet的output时，也要用到Request Dispatcher.

9. Servlet和Jsp在同一个JVM中，可以通过ServeltContext的
setAttribute( )
getAttribute( )
removeAttribute( )
来共享对象
10. 利用request.getParameter( )得到的String存在字符集问题。
可以用 strTitle = request.getParameter(“title”);
strTitle = new String(strTitle.getBytes(“8859-1”),”gb2312”);

如果你希望得到更大得兼容性
String encoding = response.getCharacterEncoding();
//确定Application server用什么编码来读取输入的。
strTitle = new String(strTitle.getBytes(encoding),”gb2312”);
XML
1．XML基础知识
1. 一个xml文档可以分成两个基本部分：
首部( header )
内容( content )

2. xml名字空间规范中指定：
xml文档中的每一个元素都处在一个名字空间中；如果没有指定的名字空间，缺省的名字空间就是和该元素相关联的名字空间。

3. A document that is well-formed obeys all of the rules of XML documents (nested tags, etc.)

" If a well-formed document uses a Document Type Definition (more on these in a minute), and it follows all the rules of the DTD, then it is also a valid document

4. A tag is the text between the <angle brackets>
" An element is the start tag, the end tag,and everything (including other elements) in between

5. 标签( tags ) 实际上包含了“元素”( elements ) 和 “属性”( attributes )两部分。
用元素( elements )来描述有规律的数据。
用属性( attributes ) 来描述系统数据。

如果你有一些数据要提供给某个应用程序，该数据就可能要用到一个元素。

如果该数据用于分类，或者用于告知应用程序如何处理某部分数据，或者该数据从来没有直接对客户程序公开，那么它就可能成为一种属性。

6. CDATA (读作：C data ) C是character的缩写。

7. org.xml.sax.Reader
/|\
org.xm.l.sax.XMLReader
/|\
org.apche.xerces.parsers.SAXParser

2．WebService
2．1 WebService的基本概念
WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。
这种技术允许网络上的所有系统进行交互。随着技术的发展，一个Web服务可以包含额外的指定功能并且可以在多个B2B应用中协作通讯。
Web服务可以理解请求中上下文的关系，并且在每一个特定的情况下产生动态的结果。这些服务会根据用户的身份，地点以及产生请求的原因来改变不同的处理，用以产生一个唯一的，定制的方案。这种协作机制对那些只对最终结果有兴趣的用户来说，是完全透明的。

UDDI
在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件。所以，我们需要一种方法来发布我们的Web服务。
UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。UDDI 项目中的成员可以通过UDDI Business Registry (UBR) 来操作Web服务的调用，UBR是一个全球性的服务。
Web服务供应商可以在UBR中描述并且注册他们的服务。
用户可以在UBR中查找并定位那些他们需要的服务。
UDDI是一种根据描述文档来引导系统查找相应服务的机制。
UDDI包含标准的“白皮书”类型的商业查询方式，
“黄皮书”类型的局部查找，以及
“绿皮书”类型的服务类型查找。
UDDI利用SOAP消息机制（标准的XML/HTTP）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

WSDL
对于商业用户来说，要找到一个自己需要使用的服务，他必须知道如何来调用。
WSDL (Web Services Description Language) 规范是一个描述接口，语义以及Web服务为了响应请求需要经常处理的工作的XML文档。这将使简单地服务方便，快速地被描述和记录。
以下是一个WSDL的样例：
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="
xmlns:tns="
xmlns:xsd1="
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace=
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="
</port>
</service>
</definitions>
它包含了以下的关键信息：
消息的描述和格式定义可以通过XML文档中的<types>和<message> 标记来传送。
<portType> 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。
<binding> 标记指定了编码的规范 。
<service> 标记中表示服务所处的位置 (URL)。
WSDL在UDDI中总是作为一个接口描述文档。因为UDDI是一个通用的用来注册WSDL规范的地方，UDDI的规范并不限制任何类型或者格式描述文档。这些文档可能是一个WSDL文档，或者是一个正规的包含导向文档的Web页面，也可能只是一个包含联系信息的电子邮件地址。
现在Java提供了一个 Java API for WSDL (JWSDL)规范。它提供了一套能快速处理WSDL文档的方法，并且不用直接对XML文档进行操作，它会比JAXP更方便，更快速。

SOAP
当商业用户通过UDDI找到你的WSDL描述文档后，他通过可以Simple Object Access Protocol (SOAP) 调用你建立的Web服务中的一个或多个操作。
SOAP是XML文档形式的调用商业方法的规范，它可以支持不同的底层接口，象HTTP(S)或者SMTP。
之所以使用XML是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用HTTP是因为几乎所有的网络系统都可以用这种协议来通信，由于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。
SOAP的强大是因为它简单。SOAP是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。
从技术角度来看，SOAP详细指明了如何响应不同的请求以及如何对参数编码。一个SOAP封装了可选的头信息和正文，并且通常使用HTTP POST方法来传送到一个HTTP 服务器，当然其他方法也是可以的，例如SMTP。SOAP同时支持消息传送和远程过程调用。以下是一个SOAP请求。
POST /StockQuote HTTP/1.1
Host:
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>SUNW</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
JAXR
为了支持UDDI在Java平台上的功能，Java APIs for XML Registries (JAXR)允许开发者来访问注册中心。
值得注意的是，JAXR并不是建立Web服务必需的，你可以利用其他常用的XML APIs来直接集成这些协议。
JAXR是一个方便的API，它提供了Java API来发布，查找以及编辑那些注册信息。它的重点在于基于XML的B2B应用，复杂的地址本查找以及对XML消息订阅的支持等Web服务。
它也可以用来访问其他类型的注册中心，象ebXML注册中心。
这些对Web服务的注册信息进行的操作，可以使用当前的一些Web服务工具来完成（例如第三方的SOAP和ebXML消息工具）。另外，当JAXP提供了一致并具有针对性的API来完成这些操作，这将使开发变得更加容易。
JAX/RPC
为了使开发人员专注于建立象SOAP那样的基于XML的请求，JCP正在开发基于RPC (JAX/RPC) 的Java API。JAX/RPC是用来发送和接收方法调用请求的，它基于XML协议，象SOAP，或者其他的象XMLP (XML Protocol，要了解更多可以参考http://www.w3.org/2000/xp/)。JAX/RPC使你不用再关注这些协议的规范，使应用的开发更快速。不久，开发人员就不用直接以XML表示方法调用了。
目前有很多第三方实现了SOAP，开发人员可以在不同的层次上调用SOAP，并选择使用哪一种。将来，JAX/RPC会取代这些APIs并提供一个统一的接口来构造以及处理SOAP RPC请求。
在接收一个从商业伙伴那里过来的SOAP请求的时候，一个Java servlet用JAX/RPC来接收这个基于XML的请求。一旦接收到请求后，servlet会调用商务方法，并且把结果回复给商业伙伴。
JAXM
当从商业合作伙伴那里接收一个Web服务的请求时，我们需要Java API实现一个Servlet来处理ebXML消息，就象我们用JAX/RPC来处理SOAP请求一样。
Java API for XML Messaging (JAXM) 是集成XML消息标准（象ebXML消息或者SOAP消息）的规范。
这个API是用来推动XML消息处理的，它检测那些预定单的消息格式以及约束。它控制了所有的消息封装机制，用一种直观的方式分割了消息中的信息，象路由信息，发货单。这样，开发人员只要关注消息的有效负载，而不用去担心那些消息的重复处理。
目前的开发人员用JAXP来实现JAXM将要提供的功能，JAXM将会提供一套非常具有针对性的API来处理基于XML的消息传送。这将大大简化开发人员的代码，并使它们具有统一的接口。
JAXM和JAX/RPC的差别在于处理消息导向的中间件以及远程过程调用的不同。JAXM注重于消息导向，而JAX/RPC是用来完成远程过程调用的。以下是图解。

请注意，在JAXM 和 JAX/RPC技术成熟之前，开发人员还是依赖于第三方的SOAP APIs，象Apache SOAP, IdooXOAP, 以及 GLUE。当JAXM 和 JAX/RPC正式发布后，它将为当前不同的SOAP和ebXML消息提供统一的接口。就象JDBC位多种不同的数据库提供统一的接口。

JAXB
XML绑定技术可以把XML文档和Java对象进行自由转换。
用JAXB，你可以在后台的EJB层，把XML文档转换成Java对象。同样你也可以把从EJB中取出的Java对象转换成XML文档返回给用户。
JAXB接口提供了比SAX和DOM更高级的方法来处理XML文档。它提供的特性可以在XML数据和Java类之间互相映射，提供了一个简单的方法来转换XML数据。它比逐个解析标记更简单。
2．2 建立WeService的步骤
在建立WeService的时候，有三个主要步骤：
1．建立客户端联接
为了允许Applets，Applications，商业合作伙伴，浏览器和PDAs 使用Web服务。
2．实现Web服务
包括工作流，数据传送，商业逻辑以及数据访问。这些功能是隐藏在Web服务后，并且为客户端工作的。
3．联接后台系统
这个系统可能包括一个或多个数据库，现存的企业信息系统，商业合作伙伴自己的系统或者Web服务，以及在多个系统中共享的数据。

基于J2EE的Web服务的核心构架：

RMI
1. RMI-IIOP
2. RMI 是在java中使用remote method invocation的最初的方法，RMI使用java.rmi包
RMI－IIOP 是RMI的一个特殊版本，RMI－IIOP可以和CORBA兼容，RMI-IIOP使用java.rmi包和javax.rmi

JAF(Java活动构架)
开发者可以使用JAF来决定任意一块数据的类型、封装对数据的访问、寻找合适的操作、实例化相关的bean来执行这些操作等。
例如，JavaMail就是使用JAF根据MIME类型来决定实例化那一个对象。
EJB
1. EJB组件实现代码的限制
EJB组件的约束
EJB的开发者并不需要在EJB的组件实现代码中编写系统级的服务，EJB提供商/开发
者需知道并且严格地遵守一些限制，这些限制与开发稳定的和可移植的EJB组件的利益有
关。
以下是你应该回避使用的一些Java特色，并且在你的EJB组件的实现代码中要严格限
制它们的使用：
1.使用static，非final 字段。建议你在EJB组件中把所有的static字段都声明为final型的。这样可以保证前后一致的运行期语义，使得EJB容器有可以在多个Java虚拟机之间分发组件实例的灵活性。
2.使用线程同步原语来同步多个组件实例的运行。避免这个问题，你就可以使EJB容器灵活的在多个Java虚拟机之间分发组件实例。
3.使用AWT函数完成键盘的输入和显示输出。约束它的原因是服务器方的商业组件意味着提供商业功能而不包括用户界面和键盘的I/O功能。
4.使用文件访问/java.io 操作。EJB商业组件意味着使用资源管理器如JDBC来存储和检索数据而不是使用文件系统API。同时，部署工具提供了在部署描述器（descriptor）中存储环境实体，以至于EJB组件可以通过环境命名上下文用一种标准的方法进行环境实体查询。所以，使用文件系统的需求基本上是被排除了。
5.监听和接收socket连接，或者用socket进行多路发送。EJB组件并不意味着提供网络socket服务器功能，但是，这个体系结构使得EJB组件可以作为socket客户或是RMI客户并且可以和容器所管理的环境外面的代码进行通讯。
6.使用映象API查询EJB组件由于安全规则所不能访问的类。这个约束加强了Java平台的安全性。
7.欲创建或获得一个类的加载器，设置或创建一个新的安全管理器，停止Java虚拟机，改变输入、输出和出错流。这个约束加强了安全性同时保留了EJB容器管理运行环境的能力。
8.设置socket工厂被URL's ServerSocket,Socket和Stream handler使用。避免这个特点，可以加强安全性同时保留了EJB容器管理运行环境的能力。
9.使用任何方法启动、停止和管理线程。这个约束消除了与EJB容器管理死锁、线程
和并发问题的责任相冲突的可能性。
通过限制使用10－16几个特点，你的目标是堵上一个潜在的安全漏洞：
10.直接读写文件描述符。
11.为一段特定的代码获得安全策略信息。
12.加载原始的类库。
13.访问Java一般角色所不能访问的包和类。
14.在包中定义一个类。
15.访问或修改安全配置对象（策略、安全、提供者、签名者和实体）。
16.使用Java序列化特点中的细分类和对象替代。
17.传递this引用指针作为一个参数或者作为返回值返回this引用指针。你必须使用
SessionContext或EntityContext中的getEJBObject()的结果。
Java2平台的安全策略
以上所列的特点事实上正是Java编程语言和Java2标准版中的标准的、强有力的特色。EJB容器允许从J2SE中使用一些或全部的受限制的特色，尽管对于EJB组件是不可用的，但需通过J2SE的安全机制来使用而不是通过直接使用J2SE的API。
Java2平台为EJB1.1规范中的EJB容器所制定的安全策略定义了安全许可集，这些许可在EJB组件的编程限制中出现。通过这个策略，定义了一些许可诸如：java.io.FilePermission,.NetPermission,java.io.reflect.ReflectPermission,java.lang.security.SecurityPermission,以便加强先前所列出的编程限制。
许多EJB容器没有加强这些限制，他们希望EJB组件开发者能遵守这些编程限制或者是带有冒险想法违背了这些限制。违背这些限制的EJB组件，比标准方法依赖过多或过少的安全许可，都将很少能在多个EJB容器间移植。另外，代码中都将隐藏着一些不确定的、难以预测的问题。所有这些都足以使EJB组件开发者应该知道这些编程限制，同时也应该认真地遵守它们。
任何违背了这些编程限制的EJB组件的实现代码在编译时都不能检查出来，因为这些特点都是Java语言和J2SE中不可缺少的部分。
对于EJB组件的这些限制同样适用于EJB组件所使用的帮助/访问（helper/access）类，J2EE应用程序使用Java文档（jar）文件格式打包到一个带.ear（代表Enterprise Archive）扩展名的文件中，这个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组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植