Flex与J2EE集成开发指南

需积分: 0 15 浏览量更新于2024-07-27 收藏 488KB PDF 举报

"Flex使用手册提供了关于如何使用Flex与J2EE进行集成的详细指南，主要探讨了在服务导向架构（SOA）环境下，Flex如何与Java和J2EE技术结合，实现富互联网应用（RIA）的开发。通过Flex的Web服务代理，RIA可以远程调用松散耦合的Web服务，或者更紧密地绑定到通过Web服务API暴露的中间件，以创建丰富的客户端界面。此外，手册也涵盖了与.NET架构的集成方法，提供了一种简单的.NET集成方式。" 在《Flex使用手册》中，重点介绍了以下几个关键知识点： 1. **Java和Flex概念**：Flex是Adobe开发的用于构建富互联网应用的框架，而Java则是一种广泛应用于服务器端开发的编程语言。两者结合可以创建交互性强、用户体验丰富的Web应用。 2. **J2EE技术架构**：J2EE（Java 2 Platform, Enterprise Edition）是一个企业级应用开发平台，包括一系列服务、API和可部署组件，如Servlet、JSP、EJB等，用于构建分布式、多层的企业系统。 3. **Flex技术架构**：Flex框架允许开发者使用MXML和ActionScript创建用户界面，并通过AMF（Action Message Format）或SOAP等协议与后端服务通信。它支持数据绑定和组件化，便于构建复杂的交互式UI。 4. **Flex与J2EE的集成**：在上一章中，讨论了Flex如何与通过Web服务暴露的业务逻辑集成。使用Flex的Web服务代理，可以跨机器调用Web服务，实现松散耦合。此外，也可以通过更深入的集成，将富客户端界面直接与通过Web服务API暴露的中间件绑定。 5. **迭代二在线银行应用程序示例**：书中可能提供了一个名为“iteration::twoOnlineBankingApplication”的例子，展示了如何在实际的银行应用中，使用Flex与J2EE进行集成，例如获取客户账户详情的Web服务。 6. **状态感知的J2EE集成**：在企业级应用中，有时需要保持会话状态。Flex能够与J2EE中的会话管理机制协作，实现状态感知的交互，这在处理用户登录状态、购物车等场景中非常重要。 7. **Flex与.NET的集成**：虽然Flex主要与Java环境集成，但手册也提到了与.NET架构的集成。通过示例代码，可以看到使用C#和ASP.NET创建的Web服务可以被Flex客户端调用，实现了.NET环境下的集成。 8. **WebMethod和WebService属性**：在.NET示例代码中，`WebMethod`和`WebService`是两个关键的特性。`WebMethod`定义了一个可以被远程调用的方法，而`WebService`则标记了一个类作为Web服务。这些知识点对于理解如何在实际项目中使用Flex与J2EE或.NET进行协同开发，以及如何构建跨平台的RIA至关重要。开发者可以借此提升应用的性能、用户体验和可维护性。

8 Chapter 20 Flex Integration with J2EE

A number of recognized design patterns, such as the Value Object or Data Transfer Object, are used

to represent business objects that are typically transferred between different tiers of a software

application. A typical business method on a J2EE middleware might look like this:

public AccountVO getShareDealingAccount( CustomerVO customer ) { ... }

In the preceding code line, AccountVO and CustomerVO are both value objects that can contain a

number of attributes, some of which can be native types such as String or Number; others can be

other custom objects (a

CustomerVO can contain an AddressVO, for instance, or an AccountVO can

contain an array of

TransactionVO objects).

The good news is that the Flex gateway assumes responsibility for passing these custom objects

back and forth across the wire as well—if we deﬁne these objects on the server and also deﬁne the

objects on the client, Flex can map between these objects.

In the online banking application example later in this chapter, we’ll discuss the design patterns and

techniques that enable us to maintain a consistent object model across the client and server,

abstracting the developer entirely from the details of mapping objects between the client and server.

J2EE Technical Architecture

Before we embark on the development of a sample online banking application, let’s consider some

of the design patterns and techniques that are useful in RIA development.

At iteration::two, we embraced and advocated the “Core J2EE Design Patterns” in our server-side

architecture, and have extended this experience onto client-side development in ActionScript 2.0.

In this section, we offer a brief discussion of the J2EE architectures that are most suited to immedi-

ate RIA development, before introducing a number of design patterns that can be implemented in

the client-tier to enable the building of robust, scalable, and maintainable RIAs using techniques

and patterns that will be familiar to seasoned J2EE developers.

Considerations for J2EE Architecture

The Service Oriented Architecture (SOA) describes a software architecture in which middleware is

exposed as business services that can be invoked in some manner by an external client. These busi-

ness services are typically loosely coupled services that can be aggregated to solve a particular busi-

ness problem.

SOA has gained widespread popularity due to its suitability as an architecture from which web ser-

vices can be exposed. Similarly, adopting a SOA facilitates the provision of a rich-client user inter-

face and speciﬁcally aids in the provision of an RIA user experience on existing or custom

middleware deployed in a J2EE application server.

The technologies that can be employed in a middleware solution are numerous, requiring their own

speciﬁc domain experience. If we consider the problem of persistence alone, in a J2EE environment

we can choose a number of technology offerings.

5666 CH20 4/14/04 10:30 PM Page 8

9J2EE Technical Architecture

The JDBC speciﬁcation allows us to develop code that interrogates a database directly, taking

responsibility for sending of SQL queries to a database and parsing of the RecordSets that are

returned.

Alternatively, we might elect to use a technology such as Entity EJB, which offers a form of object-to-

relational mapping while managing additional features such as security and transactions on our behalf.

More recently, lightweight persistence frameworks such as the Hibernate tool are becoming common-

place, which again require speciﬁc domain knowledge as to how to build a hibernate solution.

Business Delegates

The Core J2EE Pattern catalog from Sun describes the Business Delegate design pattern as a

means of providing a business interface that hides the developer from the implementation details of

underlying technologies.

The Business Delegate pattern offers the “point of contact” with the business tier in an applica-

tion. Whether the underlying technologies comprise JDBC database integration, stateless session

bean facades on a tier of entity beans, or a persistence framework such as Hibernate, the end devel-

oper doesn’t care. Similarly, if middleware is integrating with a CICS mainframe, an MQ Series

message queue using a JMS provider, or web service integration, presenting a Business Delegate

class offers a technology-independent means of using these services.

More importantly, the Business Delegate pattern forms a point of integration where all necessary

business logic is pulled up, exposing a well-deﬁned API that can be used to employ the underlying

services.

At iteration::two, we recommend pulling all related business logic in our middleware into a Busi-

ness Delegate class, and conﬁguring the Flex whitelist so that the Delegate class or classes are the

only classes exposed to the Flex client.

Flex Whitelist

The Flex whitelist is the means by which you can define which Java classes and web

services that Flex applications are allowed to execute through the server-side proxy. The

whitelist is covered in more detail in the next chapter.

Though Flex is capable of invoking methods directly on EJBs, we still suggest that an EJB—even if

a stateless session façade that aggregates EJB access into a business objects—be exposed to an RIA

through a plain old Business Delegate Java object.

Although this requirement is by no means strict, we advocate that this architecture allows simple

unit testing of our service interface, provides a simple interface to the RIA client that is completely

agnostic of server-side implementation, and encourages the “stubbing” of business services during

development of new business logic.

5666 CH20 4/14/04 10:30 PM Page 9

10 Chapter 20 Flex Integration with J2EE

Flex Technical Architecture

The discussion that follows is not necessarily particular to J2EE integration, but can apply equally

well to the integration of an RIA client using other services such as web services or HTTP services.

However, we introduce these concepts now because the decision to integrate with J2EE middleware

is typical for the development of an enterprise RIA, in which the number of use cases or tasks is typ-

ically high—tens or hundreds, rather than ones or twos.

As the number of tasks scales, so too does the number of methods we want to invoke, as well as the

number of different contexts in which we want to invoke these methods. We must consider how

best to manage these different services, and how to partition our application architecture so that the

invocations of these services are not scattered around our application, but are catalogued in well-

deﬁned places in our architecture.

These problems that we want to address are not unique to RIA development, and have been docu-

mented and solved by the software community using a collection of different design patterns.

What we describe here are the best-practices advocated at iteration::two. They are not the best prac-

tices, but simply practices that ﬁt with our understanding of building enterprise RIAs in a pre-

dictable and repeatable fashion. You might ﬁnd best practices that ﬁt within your own development

practices—consider the patterns and practices that follow as a starting point for your own develop-

ment only.

Many of the patterns presented here were already presented by the authors in “ActionScript 2.0

Design Patterns for Rich Internet Applications,” which can be found in the ActionScript 2.0 Dic-

tionary from Macromedia Press. However, Macromedia Flex encourages us to consider alternative

implementations of the patterns by using a combination of MXML and ActionScript 2.0.

RIA Service Locator

The problem of looking up remote services and establishing connections to these services is typi-

cally solved by the service locator class. Prior to Flex, we recommended a strategy whereby a single-

ton class provided the capability to look up services by name, returning an instance of a class that

could be used as a proxy to the remote service. With Flex, much of the effort required in imple-

menting the Service Locator pattern has been done for us:

■

Named Services—The <mx:RemoteObject> tag allows us to specify not only the location

of a class that should be available for integration, but to specify these classes within the

flex-config.xml deployment descriptor. By using a deployment descriptor, we can name

services from conﬁguration ﬁles, and look up these services in MXML using these

canonical names. This feature will be explained further in the next chapter.

■

Return of a Service Object—Prior to Flex, our ActionScript 2.0 implementation of the

Service Locator was responsible for looking up the Remote object, creating a connection

to that object, and returning an instance of a proxy class that could be used to invoke

methods on the service. The

<mx:RemoteObject> tag is an MXML construct that achieves

all this without the requirement for ActionScript 2.0 coding.

5666 CH20 4/14/04 10:30 PM Page 10

剩余45页未读，继续阅读

轨迹行

粉丝: 2
资源: 25

Flex与J2EE集成开发指南

flex 使用手册,官网下载

flex使用手册(The Fast Lexical Analyzer)

细细品味Flex——新Flex学习手册.pdf

flex使用帮助手册

flex自学手册

FlexCss手册

Flex开发手册 环境搭建手册

mapgis igserver flex入门手册

twaver for flex 开发手册

twaver flex 中文用户使用手册

最新资源

Flex开发手册环境搭建手册