RMI-IIOP/Java IDL
这两种技术支持J2EE组件和CORBA组件的相互通信。CORBA即Common Object Request Broker Architecture的缩写，是OMG（对象管理组织）定义的一种著名的分布式应用框架，已经有多年历史。
Java IDL是从J2EE环境访问现有CORBA对象的推荐方法，但RMI-IIOP也能够将J2EE组件提供给CORBA客户程序。
JAX
JAX即Java API for XML，是一种简化J2EE领域内XML文档使用的Java XML API。JAX API提供的服务包括XML解析（包括SAX和DOM）、XML与Java对象的绑定、XML消息和XSLT转换。JAX API是以Web服务的形式提供J2EE业务逻辑组件的基础，也是调用其他各种不同环境提供的Web服务的基础。
JCA
JCA即Java Connector Architecture（Java连接器体系），支持J2EE中间件与现有企业信息系统的无缝集成，例如ERP、主机系统、事务处理系统、数据库以及其他传统应用系统等。就像其他服务API一样，JCA为各个厂商提供了开发资源适配器的空间，由资源适配器与J2EE应用服务器建立系统级连接协议，与访问EIS资源的应用组件建立应用级连接协议。
对于J2EE环境，客户访问的类型可总结如下：
访问EJB中的业务逻辑服务：这也许是所有J2EE环境中最常见的客户访问形式。如果核心的业务逻辑规则能够封装成宽松结合的EJB或其他Java组件，它们就可以在多个应用之内重用。有的企业甚至专门制定了构造J2EE组件和服务的长远规划（例如发展出全局性的业务逻辑知识库或公用的EIS访问网关），由富有经验的分析师负责精心设计和监管业务逻辑模块，确保最佳的可重用性和表现。例如，银行的资金转移服务把资金从一个帐户划转到另一个帐户，如果这个服务以EJB的形式实现，就可以供不同类型的客户端重用——例如银行的内勤服务系统、Web银行、移动银行，等等。
访问表现逻辑服务：表现逻辑服务与客户终端的类型关系密切，要在不同的应用之间重用一般比较困难。但是，利用某些技术和设计方法，可以把“表现的内容”与“表现的方式”分离开来。典型的方案是使用XML和XSLT，完全分离表现逻辑（XSLT）和内容（XML）。例如，考虑前述资金转移服务，假设现在要在成功执行该服务之后，发送一个回执和帐户余额信息。不论客户端是什么类型，要显示的数据都是一样的（即资金划拨是否成功，帐户余额），但具体的显示方式则因客户端的不同而不同，例如在Web页面上，可能要显示几幅装饰图形，但在移动设备上肯定要用另一种简化的显示方式。在这种场合，如果表现方式（图形、字体等的定义信息）在分开的XSLT页面中定义，例如web.xsl、mobile.xsl等，然后让表现方式和表现内容在服务器端或客户端以某一种方式结合，就可以成功实现两者分离的目标。
访问企业服务：有的时候，J2EE领域之外的组件可能需要访问J2EE平台的企业服务。如果在设计企业J2EE体系时考虑到了让外部应用和组件访问，这种需求必然会更加明确。例如，我们可以在J2EE企业email服务之上构造一个公共的网关，使得email服务不仅可被J2EE平台内部的组件调用，还可以被所有其他需要发送和接收email的企业应用调用。类似地，所有的数据库访问调用可以集中到J2EE环境之内。这种设计方案有助于改进对企业内各种基础服务的控制和协调、利用。
通过J2EE访问EIS服务：J2EE除了能够把它自身的应用组件提供给不同类型的客户之外，还能够作为一个中央控制器，支持对后端EIS资源的访问。如果后端的EIS系统庞大且复杂，或者有许多应用不能直接访问EIS资源，通过J2EE访问EIS服务更具有实用意义。例如，假设后端运行着Siebel CRM系统，客户通过消息系统和Siebel适配器访问该系统提供的资源。这时，就可以在J2EE内利用JMS、EJB等技术，构造一个访问网关，使得各种Java客户程序和其他应用能够以一种一致的方式访问Siebel资源。
能够调用J2EE服务的客户类型非常广泛。当然，实际可支持的客户类型依赖于企业应用系统的总体设计和构造。下面列出了其中一部分：
Web（HTML）客户端：通过HTTP协议访问J2EE服务的客户端。这是最常见的客户端类型，许多J2EE工程的最初阶段就是从Web门户的形式开始，所以J2EE应用服务器常常带有内建的HTTP Web服务器。通过HTTP协议将J2EE环境连接到Web/Internet的组件包括Servlet和JSP。Servlet最适合于接收客户的请求并调用适当的业务逻辑，JSP最适合于呈现处理结果。
· 设备客户端：利用J2ME、WAP等技术，通过手持设备和移动电话访问J2EE服务。
· Applet客户端：浏览器或Applet容器之内的Java Applet，能够直接访问J2EE业务逻辑环境。与普通HTML页面相比，Java Applet要强大得多，能够调用描述业务逻辑的Bean（直接调用EJB）。然而，把View和Controller的逻辑嵌入到Applet将使得Applet规模过大，除非有特别的原因，这种做法在实践中通常不可取。嵌入Applet的代码越多，偏离Model-View-Controller体系就越远，同时，客户端下载Applet并在浏览器JVM内运行它的时间开销也越大。在Applet内部，最好只执行一些客户端的验证工作，把其他所有处理工作转移到服务器端组件。
· 独立的Java应用客户端：和Applet一样，独立的Java应用客户端也能够直接访问业务逻辑组件。独立的Java应用客户端能够通过Java RMI调用访问所有的业务逻辑组件。EJB之间的相互通信通过RMI实现，所以独立的Java应用客户端可以直接执行基于RMI的远程过程调用。需要访问EJB时，Java客户端首先通过JNDI查询分布式目录服务，获得一个指定EJB的句柄；获得句柄之后，客户端就可以开始调用业务逻辑代码了。由于EJB是分布式组件，即使对于分布到不同J2EE服务器环境的不同EJB，访问形式也是一致的。
· 其他服务器上的EJB客户端：运行在其他J2EE服务器或容器上的业务逻辑组件（普通Java类或EJB）能够直接访问J2EE环境内的EJB。例如，如果一家企业和它的合作伙伴决定启用统一的J2EE中间件平台，它们就可以互相许可对方跨平台访问自己的业务逻辑组件。EJB有着优秀的验证和授权机制——包括方法级的安全机制，因而，在不同的平台之间相互交换EJB服务的同时，可以建立完善的访问控制体系。在这种场合，应当密切注意只有那些经过授权的EJB才能够访问指定的业务逻辑或服务。
· CORBA客户端：驻留在CORBA ORB环境内的CORBA应用客户端通过远程IIOP调用访问EJB。J2EE促进了与驻留在CORBA ORB之内的CORBA组件的全面交互。Java接口定义语言（Java IDL）能够把EJB描述成CORBA客户程序眼中的CORBA对象；与此对应，如果需要从EJB访问CORBA组件，则可以使用RMI-IIOP调用。
· 传统系统作为客户端（ERP/CRM/大型主机系统）：诸如ERP/CRM和大型主机系统之类的传统系统也能够访问J2EE环境内的资源和服务。当传统系统作为客户端访问J2EE环境时，最常见的途径是通过消息系统。从这个意义上说，对于J2EE环境，作为客户端的传统系统可以看成是JMS客户端。如果传统系统提供了相应的连接器，Java连接器体系（JCA）可能很有用。
· JMS客户端：JMS客户端是通过一种或多种支持JMS的消息系统（如IBM MQ Series）访问J2EE的应用或组件。由于J2EE领域内与消息系统密切交互的需求很大，所以J2EE引入了一种新的EJB类型，即“消息驱动的Bean”（Message Driven Bean）。消息驱动的Bean支持与基于JMS的消息系统进行同步或异步的交互；对于其他消息应用访问EJB容器内的业务逻辑组件，也能够提供有效的支持。
· Windows客户端：用VB/VC ++等构造的Windows应用。在.NET框架出现之前，为了把EJB直接显露给Windows应用的本机调用，人们已经对Java客户服务（CAS）进行了一定的努力。但是，随着.NET的出现，重心已经稍微偏离了CAS。现在，人们把寻找这两种环境最佳交互途径的焦点转移到了厂商中立的标准和Web服务技术上。
· Web服务客户端：通过非厂商私有的技术，例如SOAP/WSDL和UDDI等，访问J2EE资源。最近，各种与Web服务有关的技术，诸如SOAP、UDDI以及WSDL等，在企业计算领域受到了广泛的认可和欢迎。任何组件或应用，只要它理解SOAP调用并把它的服务发布到UDDI之类的目录，就能够以Web服务的形式提供其服务。Java的XML API，例如JAXP（Java API for XML Processing）、JAXR（(Java API for XML Registries)、JAXB（Java API for XML Binding）、JAXM（Java API for XML Messaging）以及JAX-RPC（Java API for XML-based Remote Procedural Call）等，推动了J2EE和Web服务这两个环境的全面交互。
综上所述，不同类型的客户都可以访问J2EE环境提供的各种服务。Java客户能够直接访问J2EE业务逻辑组件，而非Java的客户则必须通过企业消息服务或其他途径才能访问J2EE环境下的业务逻辑。然后，随着.NET的出现和Web服务的发展，Windows客户访问J2EE业务逻辑服务不再困难。