BEA Web Services Architecture
Built on the market-leading, extensible, standards-based application infrastructure, BEA makes it easy to rapidly build, deploy, manage and integrate enterprise-class Web Services. Developing a Web Service on the BEA E-business platform means using standard J2EE components, such as stateless session EJBs, message-driven beans, and JMS destinations. And, because these services are built on our J2EE platform, they automatically inherit all the standard J2EE benefits, such as a simple and familiar component-based development model, easy scalability, support for transactions, automatic life-cycle management, easy access to existing enterprise systems through the use of J2EE APIs (such as JDBC and JTA), and a simple and unified security model. Additionally, BEA's Web Services architecture fully interoperates with other leading vendor's production Web Service implementations.
BEA Web Services Programming Model
The programming model describes how to implement, assemble, deploy, and invoke Web Services that are hosted by the BEA E-business platform.
The BEA E-Business Platform supports two types of services:
- Remote procedure call (RPC)-style for supporting simple Web Service, like the stock quote example often given by vendors.
- Message-style Web Services for supporting loosely coupled asynchronous model and a key requirement for Enterprise-class Web Services.
RPC-Style Web Services
A remote procedure call (RPC)-style Web Service is implemented using a stateless session EJB. It appears as a remote object to the client application.
The interaction between a client and an RPC-style Web Service centers around a service-specific interface. When clients invoke the Web Service, they send parameter values to the Web Service, which executes the required methods, and then sends back the return values. Because of this back and forth conversation between the client and the Web Service, RPC-style Web Services are tightly coupled and resemble traditional distributed object paradigms, such as RMI or DCOM.
RPC-style Web Services are synchronous, meaning that when a client sends a request, it waits for a response before doing anything else.
Message-Style Web Services
Loosely Coupled
Message-style Web Services are loosely coupled and document-driven rather than being associated with a service-specific interface. When a client invokes a message-style Web Service, the client typically sends it an entire document, such as a purchase order, rather than a discrete set of parameters. The Web Service accepts the entire document, processes it, and may or may not return a result message. Because no tightly-coupled request-response between the client and Web Service occurs, message-style Web Services promote a looser coupling between client and server.
Asynchronous
Message-style Web Services are asynchronous meaning that a client that invokes the Web Service does not wait for a response before it can do something else. The response from the Web Service, if any, can appear hours or days later making interactions more efficient. Asynchronous Web Services are a requirement for Enterprise-class Web Services.
Get the details here
Coarse Grained
Message-style Web Services also allow for coarse-grained communication. In the world of distributed objects, the idea was that you talked to an object through its methods, and objects are supposed to have encapsulation so that everything you can talk to about an object has a method. For example, if you were looking up a record and wanted to get a first name, last name, social security number, date of birth, and so on you would needed three or four different calls. If you need several records to make a decision you would have to make that many more calls against that object remotely from one application to the other. This is very expensive, and even within the organization can be a real challenge.
Running two applications built by different people that coordinate in this way doesn't scale very even when you have a very limited number of user. As soon as you try and do this across big corporate networks, or across the Internet, that model completely breaks down. Instead, what is needed is a coarse-grained communication model where you can request a record and say, here's all the information I need. Send back a single agreed-upon data message with all the information at once. The XML messages are very small and have a reasonable amount of information-enough for you to get the job done. We call that coarse-grained communication.
It's equally fundamental to any kind of Web-services architecture or really any services architecture, because the amount of communication is not as great. Further, the communications can be more reliable because you're not depending on many round-trips that all have to work in concert. One single successful round trip will give you what you need.
This programming model allows BEA customers to implement Web Services in a real business environment. Support for Message style Web Services provides the asynchronous, loose coupling and granularity necessary for real business interactions which is largely ignored by other vendors.
|
