java邮件是什么模式 Java收发邮件过程中具体的功能是怎么实现的
大家好，今天来为大家分享java邮件是什么模式的一些知识点，和Java收发邮件过程中具体的功能是怎么实现的的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
java中什么是类爆炸
可能是由于设计者对面向对象设计经验的缺少，也可能设计者是一个刻板的教条主义者，结果出品了一个很不理想的设计，其中可能就体现在类的数量爆炸的问题。
类爆炸的现象已经发生在我们的软件系统中了。比如我们某期的系统中各种模块文件的数量已经达到一千多个了，虽然比起操作系统这样的系统来说，由一千多个模
块组成的系统不算什么，但是我们目前的软件团队维护这么多的模块真的是有些吃力。由于我们使用的是VB，这还导致另一个问题，VB能装载的文件总数是有限
制的，最后用户提出了新的需求需要新的模块来完成实现，系统却已经不允许加入新的模块了，最后不得不对系统进行拆分或者对某些模块进行合并。
类爆炸的直接原因是设计者对类的抽象粒度没能把握好，只要两个事务有所差别就用不同的类来设计。粒度能多小就做多小，以为这样可以减少耦合。事实是如此
吗？最近组长让我写一份设计问题，他已经规定了设计文档的规范和大纲，规范中说“本系统编码使用了三种类：界面类、实体类、记录集类，并调用了公用模块中
相应函数”，这可能是他从别的设计规范中继承抄袭过来的。但是我最后提交的设计文档没有实体类和记录集类，组长问我为什么没有这两种类，我说我不需要这两
种类，我这个功能一个界面就可完成了。但是他觉得，如果我没有那两个类就应该在设计文档中说明没有那两个类，我说我的设计文档中没有描述那两个类就表明我
没有那两个类，而不需要在文档中说明“实体类，无；记录集类，无”。
如果每一个功能的完成都必须设计成“界面类、实体类、记录集类”这三种类来联合完成，我们就陷入了教条主义的深渊中。曾经和某个项目经理探讨过，“a=c
与a=b=c”的取舍问题，我的观点是根据具体情况来决定是使用“a=c”的结构还是使用“a=b=c”的结构，他的观点是每个功能都一律使用
“a=b=c”的结构，这导致我很郁闷。为什么要在很简单的情况下，本来可以直接就让“a=c”，何必非要加一个中间件“b”，通过“b”来让
“a=c”？不是我不知道“a=b=c”的结构的用意，而是我觉要根据具体情况来应用。我们的系统的类爆炸就是因为不分优劣一律使用“a=b=c”的结构
而爆炸的。对于面向对象的初期使用者来说，总会津津乐道他在系统中实现了面向对象的设计，尽管那个设计比较糟糕。其实这位项目经理只是给了一个系统的规范
文档而已，至于说是他设计了系统的架构，那还远远谈不到。系统中有什么类，类如何创建，类如何组织，类之间如何通信，他都没有做。只是在文档里说了“本系
统编码使用了三种类：界面类、实体类、记录集类，并调用了公用模块中相应函数”，一句话了事。系统中到底有多少类，他不知道。
我在阅读设计专家关于面向对象设计和设计模式的文章时，这些专家一再强调要谨慎使用面向对象和设计模式，否则后果就是苦果。我在应用面向对象时一向比较小心，一步一步的学习使用，而不是一步到位，毕竟我是个初学者。
再举一个例子。我们的系统中有一个连接类，大家都知道这个类是用来连接数据库的。不过我想很少有人知道为什么设计者要设计出这样一个类来。是因为他刚刚读
过设计模式中有一个“单例模式”。对于我们现在的这个系统来说，使用一个数据库连接对象就可以了，设计者为了避免每个程序员都去创建新的数据库连接，就使
用“单例模式”设计出一个连接类来。“单例模式”的用意就是某个类的实例在整个系统中只能有一个实例存在。比如我们用的windows剪贴板，在整个系统
中只能有一个剪贴板，大家都不会去new一个新的剪贴板出来。
我感到非常的郁闷，在一个公用模块里申明一个系统变量connection就可以了，告诉大家这个对象是我们的数据库连接对象，大家都用这个对象，为什么
再来一个clsConnection类对connection重新包装一下？，这反而就有问题了，我可以new出无数个clsConnection的实
例，没有达到“单例模式”的用意，因为在clsConnection类里没有提供静态方法来总是返回系统中已经存在的连接对象，这成了“多例模式”了。也
许设计者的另一个用意是要使用设计模式中的“简单工厂模式”。不过，不管是想练习什么模式，对于一个connection根本没有必要再包装了。这好比我
们有一个系统级变量，为了避免大家都去申明这个变量就用一个类来包装这个变量。那么系统中已经存在这样一个类，为了避免大家乱用这个类，就再来一个类来包
装这个类？层层包裹下去，怎么才算安全？（这里的例子是应用VB做的系统，JAVA使用者请勿随意理解。这里有语言差异。）
使用面向对象设计技术会产生良好的系统，但是，类是面向对象中的东西，那么类爆炸也必然是使用面向对象的产物，这是不良设计导致的。
我们有的程序员有些过于遵守规范而显得有些刻板了。举个例子。某个程序员做了一个类A和一个类B，实体B是实体A的载体（规范中要求每个实体都要对应一个
类），类A提供了一个修改自身的方法，当实体B的某个属性改变时必须要改变实体A的某个属性。我看了源代码，发现一条SQL语句就可以解决这个问题，但是
这个程序员为了用类A的修改方法，在类B中写了一个循环，先找出所有属于实体B的实体A，并创建类A的实例，然后调用类A的修改方法。代码不但冗长还效率
低下。这个程序员有自已的理由去那样做，理由1是上面领导制定的规范要求这样做，理由2是这是一种面向对象的应用，因为类A已经提供了修改实体A的方法，
别人就应该重用这个方法。一切讲究重用。
我想提出的是，如果重用这个方法即不使代码简洁又不能提高效率而且还造成强烈的耦合，为什么还要重用它？在面向对象中，大家知道类的构造函数是用来做什么
的吗？重载方法又是为什么吗？为什么一个类可以有多个不同的构造函数？不同的构造函数是为了达到不同的目的，而不仅仅是为了实例化一个类。方法的重载也是
为了实现不同的目的。当类A提供的方法不能很好的完成任务时，我们就应该舍弃它或者重载它。如果规范要求必须类B调用类A的方法（这个“必须”很值得疑
问）时，那么应该在类A中提供不同的修改方法以使设计合理。类A可以有这样的两个方法：方法1（以实体A自身的引用为参数）,方法2（以实体B的引用为参
数）。
关于重用。
我们现在设计系统一直想达到重用的目的。但是考虑我们所做软件的性质，我们对系统组件应该达到什么样的重用程度。我们的组件是不是要发布出去供第三方二次
开发？我们的组件是不是每年能达到2次重用？业务组件和与业务无关的组件重用的能力是不是有很大区别？我们不同的客户的业务规范是不是相差比较大？
由于我们现在对业务抽象的不到位，设计出来的类的粒度控制的不够好。业务相关和业务无关的对象的分离做的不够好，因此，实现组件甚至一个子系统的重用是很难的，只能为不同的客户去修改现有的代码，这显然不是重用，而是维护。我们的代码一年连一次重用的机会都没有。
关于创新。
如果没有创新的设计，后果是可想而知的，不管我们了解的业务再多，我们总是用最原始或者最笨拙的设计去实现业务。这样我们对业务了解的越多，系统做的越
大，代码就越混乱越不稳定。能达到将就凑乎的使用已经是不错的了。当硬件技术飞速发展的时候，软件技术却落后，结果是什么？那么，在我们公司，业务和技
术，哪个是硬件哪个是软件？当所有程序员都意识到争当项目经理和项目组长可以不去编写程序而待遇却提高了时，结果是什么？设计需要创新，了解业务却是一种
带有明显的“被动”特征。用户不告诉你他的业务规则你就不知道，告诉你，你就知道。当用户停止提供需求时，这段时间内，需求调研人员应该做什么工作？是不
是留下了大量的需求文档，是不是去抽象业务规则了？需求调研人员是不是能发现不同客户的不同业务之间的相似性为设计人员提供指导？
我们无法为客户去创新业务，但我们应该去创新我们的设计。一个软件的设计很难保持三年不变，如果三年后还不能有所创新而发生变换，那就落后了。为了适应新
的形式，微软敢于修改自己的操作系统的内核使系统升级。不升级意味着失去财富，而升级时难免要修改部分内核。那么，应用创新技术付出的代价大还是保持原有
系统不变的受益大？我们要考虑新系统生产时的阵痛和它以后带来的长远利益。
公司的人员流动的特征我们是否加以分析了，流走的是什么的样人，进来的又是什么样的人。这些人的技术能力、性格、悟性又是如何？我们拥有了许多安于现状不
具创新的老员工，我们该怎么对待他们？如果一个员工的性格激烈但悟性良好能有创新，我们是不是排击他了？兢兢业业、按部就班、任由指挥是不是就是一个优秀
的员工？
一个公司，各种性格的员工的存在应该有一个比例。全部都是不安分的创新者是不好的，充斥大量的安分守己、明哲保身、上面怎么说下面就怎么做的员工也是不好的现象。公司员工的性格和悟性的分布应该象一个波浪一样，有浪头有浪波，这样才能形成巨浪。
关于沟通。
公司越大，我发现员工之间的沟通越差。当我们还是一家小公司的时候，我可以认识所有的人，现在仅能认识个别几个人。沟通，不是由领导来强调下面的人去做
的，而是由领导来启动和带动的。所谓“领导”两个字，就是“领”和“导”，什么意思？大家自然知道。如何才能称得上一个领导，他必须具有领头和导向的作
用。各个部门的领导肩负着不同的“领导”。技术领导，他的技术是不是一定要强？若不强，是不是他能通过沟通的艺术来让下面的人服从？
沟通是一个大的问题。比如我早已经应用过一个比较好的数据库设计模型，但是新项目的设计者从来也没有咨询过我是怎么做的，结果他自己搞出一个很糟糕的数据
模型。沟通是一个双向过程。被动的沟通与主动的沟通的效果自然是不同的。我们现在缺乏主动沟通，就是被动沟通都不能好好的参与。所以，沟通出现了“推模
式”和“拉模式”。举个例子，我有些编程技巧放到公司网站了，很少有人去用主动的看，如果他主动去看了，这种行为模式称作“拉模式”。为了让更多的人知道
我的技巧，我只能主动把技术文章发到每个人的邮箱里，我的这种行为模式是一种“推模式”。我把技术文章推到每个人的邮箱里了，那么接收邮件的人是不是“拉
过来”看一眼？我发现，有一部分人是从来不看的，技术人员也不看。到底为什么不看？看不起我的文章还是太了解我而觉得没有必要看？他的心态我没有办法了
解，总之，沟通是有障碍的。
“聚集”沟通需要大家坐在一起去探讨某些问题，但这可能会浪费参与人的时间。因此我一直以为“推模式”的沟通还是可取的。使用邮件来沟通，想看则看不想看
就不看，尊重接收邮件的人的参与意识。但是发邮件会引来一些误会。一部分人会把你的邮件当作垃圾，心里不喜欢你给他发邮件但又不能说出来。一部分人会认为
发邮件的人脑子有毛病或者出风头，我觉得应该让每一个人都摆正心态：尊重发邮件的人。历来都有“枪打出头鸟”的现象，人在浪头上，难免遭遇不恰当的言语。
因此，永远低调和保持沉默便成为一种人生哲学。激进主义是用来推动社会前进的，保守主义是用来维持社会稳定的。我们允许这些同时存在。
由对事演化到对人。
当我们探讨问题时一般都是本着“对事不对人”的态度的。对于言者也许是这样的心里，但听者可能认为言者就是“对人不对事”。我们没有办法使他消除那种心里，因为那是他的性格使然。但是我们希望每个人都心胸开阔一些。
在探讨关于类爆炸的问题时，我说了一些题外话。
当我和一些同事在探讨设计中的缺陷时，发现大家的眼睛都还是明亮的，知道问题所在。不幸的是，几乎所有的人保都持沉默而不将问题暴露出来。当我暴露问题时，会得到个别人的善意的奉劝：“不要去做”。
Java收发邮件过程中具体的功能是怎么实现的
1.SMTP协议
用户连上邮件服务器后，要想给它发送一封电子邮件，需要遵循一定的通迅规则，SMTP协议就是用于定义这种通讯规则的。
因而，通常我们也把处理用户smtp请求（邮件发送请求）的邮件服务器称之为SMTP服务器。(25)
2.POP3协议
同样，用户若想从邮件服务器管理的电子邮箱中接收一封电子邮件的话，他连上邮件服务器后，也需要遵循一定的通迅格式，POP3协议用于定义这种通讯格式。
因而，通常我们也把处理用户pop3请求（邮件接收请求）的邮件服务器称之为POP3服务器。(110)
下图用于演示两帐户相互发送邮件的过程
3.1JavaMail API按其功能划分通常可分为如下三大类：
创建和解析邮件内容的API：Message类是创建和解析邮件的核心API，它的实例对象代表一封电子邮件。
3.2发送邮件的API：Transport类是发送邮件的核心API类，它的实例对象代表实现了某个邮件发送协议的邮件发送对象，例如SMTP协议。
接收邮件的API：Store类是接收邮件的核心API类，它的实例对象代表实现了某个邮件接收协议的邮件接收对象，例如POP3协议。
3.3Session类
Session类用于定义整个应用程序所需的环境信息，以及收集客户端与邮件服务器建立网络连接的会话信息，如邮件服务器的主机名、端口号、采用的邮件发送和接收协议等。Session对象根据这些信息构建用于邮件收发的Transport和Store对象，以及为客户端创建Message对象时提供信息支持。
4.邮件组织结构相关的API
MimeMessage类表示整封邮件。
MimeBodyPart类表示邮件的一个MIME消息。
MimeMultipart类表示一个由多个MIME消息组合成的组合MIME消息。
5.具体的例子程序
packagecn.edu.dlmu.send;
importjava.util.Properties;
importjavax.activation.DataHandler;
importjavax.activation.FileDataSource;
importjavax.mail.Message;
importjavax.mail.Session;
importjavax.mail.Transport;
importjavax.mail.internet.InternetAddress;
importjavax.mail.internet.MimeBodyPart;
importjavax.mail.internet.MimeMessage;
importjavax.mail.internet.MimeMultipart;
importjavax.mail.internet.MimeUtility;
publicclassSendMail{
publicstaticvoidmain(String[]args)throwsException{
Propertiesprop=newProperties();
//连接的邮件服务器的主机名
prop.setProperty("mail.smtp.host","smtp.sina.com.cn");
//发送邮件的协议
prop.setProperty("mail.transport.protocol","smtp");
//是否向邮件服务器提交认证
prop.setProperty("mail.smtp.auth","true");
//创建session
Sessionsession=Session.getInstance(prop);
session.setDebug(true);
//得到transport
Transportts=session.getTransport();
//连接邮件服务器
ts.connect("smtp.sina.com.cn","xxxx@sina.com","xxxxx");
//发送邮件
MimeMessagemessage=createMessage(session);
ts.sendMessage(message,message.getAllRecipients());
ts.close();
}
publicstaticMimeMessagecreateMessage(Sessionsession)throwsException{
MimeMessagemessage=newMimeMessage(session);
//设置邮件的基本信息
message.setFrom(newInternetAddress("xxxx@sina.com"));
message.setRecipient(Message.RecipientType.TO,newInternetAddress("1219070362@qq.com"));
message.setSubject("test");
//正文
MimeBodyParttext=newMimeBodyPart();
//设置charaset可以解决中文正文的乱码问题，内嵌可下载的图片
text.setContent("你好xxx，<imgsrc='c:/dog.jpg'/>测试成功！<br/><imgsrc='cid:aaa.jpg'/>","text/html;charset=gbk");
//图片1
MimeBodyPartimage=newMimeBodyPart();
image.setDataHandler(newDataHandler(newFileDataSource("src/88.jpg")));
image.setContentID("aaa.jpg");
//附件
MimeBodyPartattach=newMimeBodyPart();
DataHandlerdh=newDataHandler(newFileDataSource("src/javamail架包.jar"));
attach.setDataHandler(dh);
//解决文件中文乱码问题
attach.setFileName(MimeUtility.encodeText(dh.getName()));
//描述正文和图片的关系
MimeMultipartmp=newMimeMultipart();
mp.addBodyPart(text);
mp.addBodyPart(image);
mp.setSubType("related");
//描述正文和附件
MimeMultipartmp2=newMimeMultipart();
mp2.addBodyPart(attach);
//将正文封装为一个body
MimeBodyPartcontent=newMimeBodyPart();
content.setContent(mp);
mp2.addBodyPart(content);
mp2.setSubType("mixed");
message.setContent(mp2);
message.saveChanges();
returnmessage;
}
}
.jap是什么文件
总的来讲，JavaSever PagesTM（JSP）和微软的Active Sever Pages（ASP）在技术方面有许多相似之处。两者都是为基于WEB应用实现动态交互网页制作提供的技术环境支持。同等程度上来讲，两者都能够为程序开发人员提供实现应用程序的编制与自带组件设计网页从逻辑上分离的技术。而且两者都能够替代CGI使网站建设与发展变的较为简单与快捷。
尽管JavaSever Pages技术和微软的Active Sever Pages在许多方面都有相似的，但仍然存在很多不同之处，其中最本质上的区别在于：两者是来源于不同的技术规范组织，其实现的基础：WEB服务器平台要求不相同。
一、 JSP技术：开放的技术
JSP和ASP技术明显的不同点：开发人员在对两者各自软件体系设计的深入了解的方式不同。JSP技术基于平台和服务器的互相独立，输入支持来自广泛的，专门的，各种工具包，服务器的组件和数据库产品开发商所提供。相比之下，ASP技术主要依赖微软的技术支持。
1、平台和服务器的独立性
JSP技术依附于一次写入，之后，可以运行在任何具有符合JavaTM语法结构的环境。取而代之过去依附于单一平台或开发商，JSP技术能够运行在任何WEB服务器上并且支持来自多家开发商提供的各种各样工具包。
由于ASP是基于Activex控件技术提供客户端和服务器端的开发组件，因此ASP技术基本上是局限于微软的操作系统平台之上。ASP主要工作环境是微软的IIS应用程序结构，又因Activex对象具有平台特性，所以ASP技术不能很容易地实现在跨平台的WEB服务器的工作。尽管ASP技术通过第三方提供的产品能够得到组件和服务实现跨平台的应用程序，但是Activex对象必须事先放置于所选择的平台中。
2、开放的开发过程，开放的原代码
SUN应用JAVA社团性过程开发JSP技术。自从1995年，SUN已经用这种开放过程方法同国际JAVA组织合作开发和修改了JAVA技术与规范。针对JSP的产品，SUN授权了工具提供商（如Macromedia）,结盟公司（如Apache,Netscape）,最终用户，协作商及其他。最近，SUN将最新版本的JSP和JavaTM Servlet（JSP 1.1,JAVA SERVLET 2.2）的原代码发放给Apache，以求JSP与Apache紧密的相互发展。Apache，SUN和许多其他的公司及个人公开成立一个健壮的咨询机构以便任何公司和个人都能免费取得信息。（详见：http://jakarta.apache.org）
JSP应用程序界面（API）毫无疑问已经取得成功，并将随JAVA组织不断开放扩大继续完善。相反，ASP技术仅依靠微软本身的推动，其发展是建立在独占的，封闭的开发过程基础之上。
ASP技术 JSP技术
WEB服务器微软的IIS或个人WEB服务器任何WEB服务器包括Apache，Netscape，和IIS
操作系统平台微软的视窗系统绝大多数的流行平台，包括solaris操作系统，微软的视窗系统，MAC OS，Linux，及其他UNIX系列平台产品
跨平台访问需要第三方ASP的引入产品支持WEB信息机构环境中不同系列的计算机群即保证用户在当前软硬件及人力资源上的投资完全兼容，JSP技术提供灵活，开放选择：可以使用各种各样的工具提供商提供的工具，高度体现工业化标准输入与配置
3、从开发人员的角度来看：ASP和JSP技术都能使开发者实现通过点击网页中的组件制作交互式的，动态的内容和应用程序的WEB站点。ASP仅支持组件对象模型COM，而JSP技术提供的组件都是基于JavabeansTM技术或JSP标签库。由此可以看出两者虽有相同之处，但其区别是很明显的。
1） JSP标签可扩充性
尽管ASP和JSP都使用标签与脚本技术来制作动态WEB网页，JSP技术能够使开发者扩展JSP标签得以应用，JSP开发者能定制标签库，所以网页制作者充分利用与XML兼容的标签技术强大的功能，大大减少对脚本语言的依赖。由于定制标签技术，使网页制作者降低了制作网页和向多个网页扩充关键功能的复杂程度。
2） JSP跨平台的可重用性
JSP的开发人员在开发过程中一直关注可重用性。JSP组件（企业JavabeansTM，Javabeans，或定制的JSP标签）都是跨平台可重用的。企业Javabeans组件可以访问传统的数据库，并能以分布式系统模式工作于UNIX和WINDOWS平台。JSP技术的标签可扩充功能为开发人员提供简便的，与XML兼容的接口即共享网页的打包功能使其完全的工业标准化。
这种基于组件的模式很有效提高应用程序的开发效率，因为这种模式能够使开发人员利用快捷的子组件快速创建模板应用程序，然后再整合一些附加功能以后便可使用。象这样有效的方法在JSP中无处不在，并可将其打包成一个Javabean或一个工业标准化的Javabean组件。
二、 JAVA的优越性
JSP技术是用JAVA语言作为脚本语言的，而ASP网页使用微软的VBScrip或Jscrip。JAVA是成熟的，强大的，易扩充的编程语言，远优于基于BASIC的脚本语言。如：JAVA的可执行性优于VBScript或Jscript语言。因为它们利用JAVA技术并且都被编译为JAVA Servlets，JSP网页为整个服务器端的JAVA库单元提供了一个接口来服务于HTTP的应用程序。
JAVA使开发人员的工作在其他方面也变的一样容易，简单。例如，当ASP应用程序在WINDOWS NT系统被怀疑可能会崩溃时，JAVA能有效的防止系统的崩溃。JAVA语言通过提供防止内存的泄漏的方法，在内存管理方面也能大显身手。加之，JSP为应用提供了健壮的意外事件处理机制。
1、易于维护性
基于JSP技术的应用程序比基于ASP的应用程序易于维护和管理。
脚本语言都能很好服务于小的应用程序，但不能适应大型的，复杂的应用程序。因为，JAVA是结构化的，它比较容易创建和维护庞大的，组件化的应用程序。
JSP突出的组件技术使修改内容而不影响逻辑或修改逻辑而不影响内容变得很容易实现。
企业级的Javabeans结构整合了企业逻辑，例如数据库的访问，安全，事务完整性，及独立性即独立于应用程序。
因为JSP技术是一种开放的，跨平台的结构，因此，WEB服务器，平台，及其他的组件能很容易升级或切换，且不会影响JSP基本的应用程序。这一特点使JSP能够适用现实世界的各种WEB应用程序不断的变化和发展。
ASP技术 JSP技术
可重用,跨平台组件没有JAVABEANS企业级JAVABEANS，定制JSP标签
安全:防范系统崩溃没有有
内存泄露保护没有有
脚本语言 VBSCRIPT,JSCRIPT JAVA
定制标签没有有
2、企业产品的多样性
JAVA2平台即企业版(J2EE)是适用于多企业应用程序的JAVA结构，作为J2EE的部分，JSP网页可访问所有J2EE的组件，包括Javabeans，企业级Javabeans及JAVA Servlets。JSP网页都能完全编译成为Servlets，所以它们都享有灵活性的特点和为服务器端JAVA应用程序。J2EE平台内容不仅包括管理复杂的企业应用程序而且包括事务管理技术和Pooling资源管理技术。
JSP网页可以访问标准的J2EE服务，包括：
? JAVA名称和目录界面API
? JDBCTM API(与关联的数据库通讯)
? JavaMailTM（支持基于JAVA邮件和消息应用程序的类）
? JAVATM消息服务
通过J2EE，JSP网页能够用许多方式同企业系统交互访问。J2EE支持两种CORBA规范的技术：JAVA IDL和RMI-IIOP。在企业级JAVABEANS技术支持下，JSP网页通过运用高级的，对象映射的方式访问数据库。
最终，因为JSP技术是基于JAVA的开放性过程的产品，因此它能够广泛支持不同提供商提供的工具，WEB服务器和应用程序的服务，这样能够使用户选择最佳的开发方法，选择最适应他们的应用程序开发的工具包，同时，有效地保护用户在代码和人员培训上的投资。
ASP技术 JSP技术
兼容传统的数据库可以（COM）可以（用JDBC API）
集成数据源的能力能工作在任何符合ODBC规范的数据库能工作在任何符合ODBC规范的数据库，而且能访问符合JDBC技术规范数据库
组件 COM组件 JAVABEANS，企业级JAVABEANS或扩展的JSP标签
扩展工具支持有有
OK，本文到此结束，希望对大家有所帮助。