Web Services and J2EE - Benefits of Using Web Services with J2EE
(Page 4 of 4 )
J2EE is a high-quality, reliable, secure infrastructure for building complex Web and business applications. Web services started more simply with no inherent security, reliability, or transactions, but these are now being added using the open and flexible model that SOAP and Web services offer.
Many businesses are using Web services with J2EE to provide simple interoperable access to existing J2EE applications—for example, creating a C/C++/C# or VB.NET client to an EJB application. Before SOAP and Web services, this was possible but very complex. J2EE uses a distributed object model called RMI-IIOP, which bridges the Java object model and the CORBA (IIOP) protocol. Accessing J2EE components from outside Java used to require either bridge technology or complicated logic to access the components using IIOP from C or C++. This was typically a painful process. SOAP and Web services make this scenario much more appealing, and a number of companies are using the SOAP approach in their systems today.
Why use J2EE with Web services? In other words, why would you write a J2EE application and EJBs if you could simply deploy Java classes into an Axis server to create Web services? The answer, as usual, depends on the individual circumstances. Many small applications will work fine with the Java Axis approach. As the complexity and requirements on the application scale up, having a managed J2EE environment in which to run components becomes more appropriate. In particular, the benefits increase as you start to connect to databases, messaging systems, and other enterprise systems.
Security The first benefit that a J2EE application server brings is security. Because the individual methods (operations) of an EJB can be secured, and because J2EE has end-to-end security, you can use either HTTPS or WS-Security to authenticate users and then offer them services and/or operations with fine-grained access control. For example, a single service may have bid and cancel operations, and a J2EE application server can be configured with one group of ordinary users who can bid, and then another group of superusers who can cancel. Because security in J2EE is tightly integrated into the Java runtime, these security models extend to the Web services space, and so the access controls are applied to incoming SOAP requests as well, based on the configuration and administration of the EJBs. (For more details, see Chapter 9, "Securing Web Services.")
Transaction Control Across Distributed ResourcesThe second benefit a J2EE application server offers is transaction control across distributed resources. Even if you aren't using WS-AtomicTransaction and WS-Coordination (see Chapter 11, "Web Services Transactions"), you may wish to ensure that the backend resources you're communicating with are kept in sync with each other and are transactional. For example, you may wish to have a database log of Web service transactions held in an Oracle or DB2 RDB and then use a JMS system to send messages internally to a legacy system. The J2EE server can make the database log entry and send the message in the same unit of work. That way, even if the HTTP connection fails and the SOAP response message sent to the client fails, your server has a log of what happened. Although it doesn't offer full end-to-end transactionality, this type of architecture has been used extensively in Web-based systems to provide a higher level of robustness at the application level.
Container Managed PersistenceJ2EE offers both a programming model for building business applications—including the tools and technology to map your objects into databases (entity beans)—and a reliable, scalable infrastructure for running those applications. As soon as the application moves beyond the simplicity of a sample or first proof of concept, users find that the learning curve and extra complexity of a J2EE solution is repaid in the savings in time and effort that the model offers.
For example, in our sample application, the J2EE application server will automatically save the state of the objects we create using a feature called Container Managed Persistence (CMP). This means that instead of having to write database logic and SQL statements, we can write fairly straightforward Java objects and have the container generate the SQL and take care of all the database reads, writes, and updates. This approach makes it quick and easy to build a Web service application with a database at its heart. And, this support is independent of which database server is used.
Please check back next week for the continuation of this article.
