javase与javaee的区别

javase与javaee的区别在于领域不同和作用不同：

1、领域不同：

javase为平台标准版，可供任何领域使用。

javaee为平台企业版，主要供应企业的使用。

2、作用不同：

javase提供了开发与运行Java软件的编译器等开发工具、软件库及Java虚拟机。它也是Java2平台、企业版本和Java网页服务的基础。

JavaEE不仅巩固了标准版中的许多优点，例如“编写一次、随处运行”的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等。

同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。

Java SE的简介：

Java se是由Sun Microsystems公司于1995年5月推出的Java程序设计语言和Java平台的总称。

用Java实现的HotJava浏览器（支持Java applet）显示了Java的魅力：跨平台、动态的Web、Internet计算，从此Java被广泛接受并推动了Web的迅速发展，常用的浏览器现在均支持Java applet。

Java语言恐怕是稳居网路应用程序语言的首选了，这都要归功于它高度的安全性以及跨平台的特性，几乎在目前所有的电脑平台上您都可以见得到Java的芳踪。

Java se用于开发和部署桌面、服务器以及嵌入设备和实时环境中的Java应用程序，Java SE包括用于开发Java Web服务的类库，同时，Java SE为Java EE提供了基础。

Java Se的特点：

Java是一门面向对象的编程语言；

面向对象(Object Oriented) 是一种软件开发思想。它是对现实世界的一种抽象，面向对象会把相关的数据和方法组织为一个整体来看待。

Java摒弃了C++中难以理解的多继承、指针、内存管理等概念不用手动管理对象的生命周期

Java语言具有功能强大和简单易用两个特征，现在企业级开发，快速敏捷开发，尤其是各种框架的出现，使Java成为越来越火的一门语言。

Java是门静态语言，静态语言指的就是在编译期间就能够知道数据类型的语言，在运行前就能够检查类型的正确性，一旦类型确定后就不能再更改。

Java具有平台独立性和可移植性；

Java有一句非常著名的口号：Write once，run anywhere，也就是一次编写，到处运行。

Java能够容易实现多线程；

Java具有高性能；

Java具有健壮性；

Java很容易开发分布式项目。

JavaEE的简介：

JavaEE应用程序是由组件构成的，也就是说它是基于组件开发的。组件是具有独立功能的单元，它们通过相关的类和文件组装成JavaEE应用程序，并与其它组件相交互。一个组件的更改不会影响其它组件，代码重复减少，重用率高。有利于良好的分工与协作，实现并行开发。如果是用三层结构开发，那么表示层与数据访问层相互独立，因此美工可以更方便的扩充表示层，使系统具有良好的可扩展性。

JavaEE技术内容：

JDBC：

java数据连接，是一种用于执行SQL语句的java API.，可以为多种关系数据库提供统一访问。有了JDBC就不用因为不同的数据库而要写个不同的应用程序，开发人员只需要使用JDBC API写一个程序就够了。

JNDI：

java命名和目录接口，提供了一种统一的方式可以在网络上查找和访问服务，通过指定一个资源名称，该名称对应于数据库或命名服务中的一个记录，同时返回数据库链接简历所必须的信息。

在DataSource中事先简历多个数据库链接，保存在数据库连接池中，当程序访问数据库时，只用从连接池中取空闲状态的数据库链接即可，访问结束，撤销资源，数据库链接重新回到连接池。

EJB：

EJB是sun的javaEE服务器端组建模型，设计目标与核心应用是部署分布式应用程序，简单来说就是把已经编写好的程序（即类）打包放到服务器上执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。包括四种对象类型：无状态回话bean（提供独立服务），有状态回话bean（提供回话交互），实体bean（持久性数据在内存中的体现，服务器崩溃后可恢复），消息驱动bean。

RMI：

远程方法调用，能够让某个java虚拟机上的对象像调用本地对象一样的调用另外一个java虚拟机中的对象上的方法。

JSP：

Java服务器页面，是一个动态内容模板，实现了html语法中的java扩展。

Servlet：

Servlet是一种小型的java程序，它扩展了web服务器的功能，作为一种服务器端的应用，当被请求时同时开始执行，这和CGI Perl脚本很相似。Servlet提供的功能大多与jsp类似，不过实现的方式不同，jsp通常是大多数html代码中嵌入少量的java代码，而servlets全部由java写成并且合并成html

XML:

是一种可扩展的标记语言，被用来在不同的商务过程中共享数据，其目标是平台独立性，记得在学习xml的时候，可以自己写标签，只要有结束标签就可以识别，还是相当强大的。

JMS:

是一个java平台中关于面向消息中间件（MOM）的API,用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持，消息通信可以是点对点的，也可以是发布订阅型的。

java IDL:

JavaIDL支持的是一个瞬间的CORBA对象，即在对象服务器处理过程中有效。实际上，java IDL的ORB是一个类库而已，并不是一个完整的平台软件，但它对java IDL应用系统和其他CORBA应用系统之间提供了很好的底层通信支持，实现了OMG定义的ORB基本功能。

JTS:

组件事物监听器，TPM是一个程序，它代表应用程序协调分布式事物的执行。TPM与数据库出现的时间长短差不多；在60年代后期，IBM首先开发了CICS,至今人们仍在使用。经典的（或者说程序化）TPM管理被程序化定义为针对事务性资源（比如数据库）的操作序列的事物。随着分布式对象协议，如CORBA、DCOM和RMI的出现，人们希望看到事务更面向对象的前景，将事务性语义告知面向对象的组件要求对TPM模型进行扩展-在这个模型中事务是按照事务性对象的调用方法定义的，JTS只是一个组件事物监听器（有时也称为对象事务监听器（object transaction monitor））或称为CTM。

JTA:

JTA允许应用程序执行分布式事务处理—在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序的JTA支持极大的增强了数据访问能力。

JavaMail:

提供给开发者处理电子邮件相关的编程接口。

JAF:

JAF是一个专用的数据处理框架，它用于封装数据，并为应用程序提供访问和操作数据的接口。

引言

有人说，Java确实过于臃肿，经常“小题大做”。但PHP、Node.js扩展方面短板太明显，做小应用可以，大型应用就玩不转了。另外，JavaEE领域有太多优秀框架可以解决开发效率的问题，事实上借用Spring等框架，开发的效率丝毫不亚于PHP。

互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。

那么，微服务能完全弥补JavaEE的短板吗?对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色?

在Java问世之初，包括IBM、BEA、Oracle在内的一些巨头公司，看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢?答案就是，使用这门语言构建复杂无比的服务器，让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了JavaEE规范、JSR规范，以及WebLogic、WebSphere等服务器中间件。

在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。

因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。

RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。

在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。

2009年，RyanDahl启动了Node.js项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Node.js可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Node.js是一个很好的作品，但它也有自己的局限性。Node.js难以扩展，也难以与遗留的系统集成。

2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。

基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。

JavaEE厂商多年前，JavaEE厂商，比如Oracle和IBM，他们花费数亿美元开发应用服务器(WebLogic和WebSphere)，这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了，因为JBoss迅速抢占了市场份额，Oracle对JavaEE的支持正在走下坡路：

#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。

JavaEE客户

从客户角度来看，耗费巨资购买这些服务器是不值得的，因为JavaEE所承诺的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上，所以你需要花更多的钱去升级服务器，因为厂商可能不再支持旧版的服务器，而这样的更新会花费你数百万美元。

于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上?为什么我们要把应用打包成一个ear包或war包，而不是jar包?为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展?

微服务

微服务是这些问题的解药。Wikipedia把微服务定义为“??一种软件架构风格，复杂的应用由一些独立的进程组成，这些进程使用与语言无关的API进行交互。这些进程服务规模很小，高度离散，聚焦在一个很小的任务上，使用模块化方式来构建系统”。

微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。

微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。

如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。

不过从最近几年的发展情况来看，之前的方式有些落伍。操作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个操作系统一样。Docker运行在云端的操作系统上，而云端的操作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办?很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。

微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其他服务(开源或闭源的)集成，只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。EC2、S3及其他来自Amazon(或其他公司)的服务就是最好的例子。基础设施会成为应用程序的一部分，而且它们是可编程的。

使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。

随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：

#/dangers-microservices-washing-get-value-strip-away-hype

微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。

微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。

虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。

容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!

结论

应用开发的风格这几年一直在变化，而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用，这些小型应用被部署在云端的容器里。开源微服务框架LightJava为这些运行在容器里的微服务提供了很多特性，它支持设计驱动，开发者只需要把注意力专注在业务逻辑上，剩下的事情可以由框架和DevOps流程来处理。

那么问题来了，你怎么看?

Sun公司的Java

EE

5标准是一种行业标准，而作为这种标准的实现，开源的Java

EE

5应用服务器应该与其尽量的保持一致，因此Java

EE

5的一致性是一个很重要的指标。在这三种开源的实现中，Geronimo是实现得最好，与Java

EE

5标准最贴近的应用服务器。JBoss

4.2支持绝大部分Java

EE

5的特性，当然，不久即将发布的JBoss

5将完全支持Java

EE

5的所有特性。而Tomcat一般看成是JSP/servlet的容器，仅仅支持Java应用服务器的基本特性。

---