web应用，javaEE企业级应用，如何严格区分？
一、为什么要区分？（提这个问题的目的）
区分的目的是了解web应用和企业级应用各自的边界在哪，从而总结一套思路在未来构建项目时如何选择，从中获取到，“当遇到何种场景是，适合构建企业级应用而何种场景web应用足矣”。
二、观察
在观察自己做过的，别人做过的项目中，web应用和企业级应用各自带有一定的特征。
web应用运行在web服务器上，比如tomcat，只需要简单的servlet容器就可运行，部署的时候发布整个目录或者打成war包发布。
企业级应用运行在application server上，app server通常比webserver多EJB容器，所以企业级应用多支持EJB，通常打包成EAR包发布，其中EAR中有多个WAR和EJBJAR。
三、思考
乍一看上去，好像EJB就是web应用和企业级应用的分水岭，所以我起初认为：
（观点一）web应用和企业级应用的区分点在于web应用适合那些只需要简单的MVC就满足需要的场景，企业级应用适合那些有核心业务模式的场景。通常这两种场景抓不到明显边界，但是我感觉，那些大家一看就能熟知（比如借书系统，几乎谁都知道怎么借书），虽然也有其核心的业务模式（借书还书流程），但是大家一看就能掌握的，不需要把核心业务单独抽取出出来这么麻烦，构建web应用即可；而企业级应用适合那些领域性很深的，业务错综的场景，需要把业务单独抽取到领域层进行维护。
根据观点一区分：是否为企业级应用就看应用中是否仅仅包含简单MVC和数据库访问，如果是就是web应用。
可是逐渐，观点有所变化，原因在于例如Spring这样的不依赖于服务器的轻量级框架也适合构建具有复杂领域性的项目，然而由Spring构建的项目发布在web服务器上能够良好的运行，它不需要服务器首先承诺什么，所以我觉得web应用和企业级应用区分不仅仅是是否涉及深入的领域这么简单。
（观点二）web应用面向单一的发布，所发布的应用程序模块集成在一起。而企业级应用通常包含多个组件WAR,EJB等等，为了统一发布的方面，企业级应用服务器带来了集成发布的便利。
根据观点二区分：是否为企业级应用就看是打包成EAR还是WAR。
觉得这种想法也不妥
（观点三）企业级应用通常伴随着比web应用更大的并发量，对事务、安全等等因素要求更严格，所以通常把对并发、事务、安全等等因素要求高的项目构建在企业级应用服务器上，利用服务器对事务、安全等等规范的支持来使其得到保证。
根据观点三区分：是否为企业级应用就看是发布在web server上还是发布在app server上，如果应用仅仅包含mvc但是发布在app server也是企业级应用。
四、总结
很难想出一种明确的明确思路来区分一个项目是web应用还是企业级应用，也很难找出一条线索来针对采集到的需求判断是构建企业级应用还是web应用足以，我不知道有过多少项目构建成企业级应用更合理却被构建成了web应用。。反之亦然，我觉得关于这个问题的思考还是值得的 1 楼 key232323 2009-04-14 web应用是 软件开发 update to today 的一种主要展现形式，谁让大家都用互联网，都用web呢，web不止是http/browser，手机***不也都是web应用吗？
企业应用概念太多，不如简单理解为“企业”的“应用”，不同企业需求不同。企业应用对应的应该是ngo和个人等“应用”吧
总之企业应用 和 web应用时交叉关系，交集越来越多，因为企业越来越“开放”。
另外别bs做网站的，做网站的有时候技术含量更高些，哈哈，个人愚见，欢迎拍砖 2 楼 朗拿颠老 2009-04-14 查了一下资料，跑在web服务器上基于http的应用，不夹杂业务逻辑的应用是web应用。在应用服务器(包括web服务器)端包含商业逻辑处理程序的应用，为企业级应用。例子：web服务器向客户端返回内容写死的HMTL，为web应用；应用服务器根据用户提交查询表单返回HTML，企业级应用。企业级应用包含web应用，企业级应用 可以 = web应用+业务逻辑处理程序。个人感觉严格区分无意义。个人愚见... 3 楼 unsid 2009-04-14 就简单说一个借书系统，有很简单的业务，大家一看就会，好像没听谁用企业级应用这么庞大的字眼来形容，那么说web应用完全没有业务是不是太绝对了？ 4 楼 clasp 2009-04-19 按LZ的说法才明白俺做了几年都是在做web应用。个人支持 朗拿颠老 的说法 5 楼 unsid 2009-04-19 在刚开始解除servlet的时候，书上都说web应用是分为MVC三层，其中带有业务部分的内容很多都写在了C里面，或者在C的基础上提出一层handler，并且handler与controller一一对应，这只不过比业务写在servlet里仅仅好了一点点而已。乍一看上去MVC代表了web应用，并非说这个完全不存在业务逻辑，是否存在业务逻辑完全看个人的实现方式。
但是按照经验论，如果业务逻辑复杂，或者领域性极其，那么最佳实践的分层方式是表现层-领域层-持久层，其中mvc全部集中在了表现层并完全不负责任何业务，这是人们在长期实践中总结的最佳实践方式，只有把业务抽离在单独的领域层才容易维护，这是标准企业级应用的结构。
当然同样复杂的业务你也可以 mvc-handler这样处理，当然你的程序越来越难以维护，这也是为什么会有应当被构建成企业级应用的场景却被错误构建成简单web应用这种错误的存在。当然相反一个很简单的需求，正如Evans所说的Smart UI反模式，如果构建复杂的领域层只会为了不必要的灵活性而付出很多代价，也是不可取的。
Rails宣扬的全栈式mvc貌似是要摒弃领域层，Rails加强了构建项目速度，强调开发效率，强调简洁，但是对于复杂的可伸缩性的需求变更可能不如领域模型应对自如，也是属于面向相对简单需求下的快速建站，web应用。
这是我的理解
