接下来介绍几个Java常用的关键技术难点:
1. 基于J2EE的跨平台技术
J2EE架构是当前主流的架构之一，目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足高可用性、高可靠性以及可扩展性的应用需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。本系统的初步设计中推荐采用J2EE架构，它具备以下特性：
Ø 高效的开发：J2EE允许开发商把一些通用的、很繁琐的服务端任务交给中间件去完成。这样开发人员可以集中精力在如何创建业务逻辑上，相应地缩短了开发时间。
Ø 状态管理服务：开发人员只需要写很少的代码，而不用关心如何管理状态，这样能够更快地完成程序开发。
Ø 持续性服务：开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。
2. 基于SOA架构的技术
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点：一点是它的灵活性；另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
SOA新技术的提出为松耦合提供了另外一种可选的更好的解决方案。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其它与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
从架构层面来看，SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构。在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。因此，基于SOA的架构也一定是从企业级应用的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。
一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务(services)。
3. 基于全程建模的技术
大型信息系统经常借助模型来设计分析，模型是现实世界中的某些事物的一种抽象表示。抽象的含义是抽取事物的本质特性，忽略事物的其他次要因素。因此，模型既反映事物的原型，又不等于该原型。模型是理解、分析、开发或改造事物原型的一种常用手段。
在信息系统中，模型是开发过程中的一个不可缺少的工具。信息系统包括数据处理、事务管理和决策支持。实质上，信息系统可以看成是由一系列有序的模型构成的，这些有序模型通常为：功能模型、信息模型、数据模型、控制模型和决策模型，所谓有序是指这些模型上分别在系统的不同开发阶段、不同开发层次上建立的。
业务模型是软件设计的核心。任何底层的问题都会反馈到业务模型上来，而业务模型和需求非常的接近，因此测试用例的设计难度比较低。我们知道，测试工作最难的就是如何权衡测试工作量和软件质量的关系，把测试的力量集中在业务模型上，能够有不错的效果（这并不是说其它的部分不需要测试，单元测试的主要思路是测试一切可以测试的东西）。但是这种测试也需要付出额外的代价，最典型的是测试环境的建立，由于是业务模型测试，不可能像单元测试那样容易，所以需要有周全的测试数据和测试计划。这项工作应该放到业务模型的类设计中，成为进度的一部分。如果是业务模型的关联性很大，还要从整体上考虑。
