270

For example, the adventure builder enterprise wants to use Web services to

integrate its existing CRM system, which provides services to manage customer

relations, to process orders. The department that owns the CRM module not only

wants to maintain control of the software, it wants to use a generic interface that

can handle user requests from multiple sources (Web site, telephone, OEM chan 

nels, and so forth). Web services are the best way to create such a generic inter 

face, for these reasons:

  Web services establish clear, defined boundaries. Since Web services can pro 

vide an interface with clear, defined boundaries of responsibilities, the CRM 

department has the responsibility to only maintain the endpoint and publish a 

WSDL describing the endpoint.

  Web services provide controlled access. Outside requests to the CRM must 

come in through the service interface, and the CRM department can apply its 

access control parameters to limit access, plus it can log each access. 

  Web services support multiple platforms. Because it does not control the hard 

ware and software platforms other departments use, the CRM department can 

accommodate any platform by using Web services.

  The current generation of Web services is best suited for applications with a 

limited need for transactions and security. The main purpose of the CRM sys 

tem is to allow status queries on existing orders. As such, it has little need for 

transactions. It also has limited need for security, since all access to the module 

happens within the corporate firewall. 

Developers have a choice of endpoint types for implementing the Web service

representing the EIS: either an EJB service endpoint or a Web based JAX RPC

service endpoint. Solely from an integration point of view, either type of endpoint

works well since Web and EJB components can both directly use JDBC and J2EE

connectors. For example, the adventure builder enterprise receives invoices using

an EJB service endpoint, as well as JAX RPC service endpoints for other func 

tions. 

Returning to the CRM problem, the adventure builder enterprise could use a

small J2EE application that uses a J2EE connector to connect to the CRM system.

Such an application needs to have a JAX RPC endpoint to expose the required

Web service functionality.

Today, since many EIS vendors are providing built in Web services support,

developers can use connectors and leverage this support directly to avoid writing a