Java Tutorial - Java Scipt : Where Web Services Fit into an Enterprise Architecture

Java Tutorial - Java Scipt :

Where Web Services Fit into an Enterprise Architecture

New enterprise applications will likely be both providers and consumers of Web services. The network effects, in which the degree of interconnectedness increases the value to all parties involved, are just beginning to be realized.
Web services give flexibility to the enterprise architecture to meet changing collaborative needs. Because many of these systems are outside of your control, Web services must not only be simple and easy to access, but must conform to shared standards.

The basic standard for Web services is SOAP, which is used by JAX-RPC as well as other platforms, such as Microsoft’s .Net architecture. SOAP provides the basic protocol for the Web services conversation, and it can be used with a number of underlying transport protocols such as HTTP, SMTP, or HTTPS. Nevertheless, SOAP/HTTP is used in the majority of cases.

The SOAP/HTTP connection leads us to another problem: firewalls. Traditionally,RPC solutions, such as DCOM and IIOP, communicated over special ports. By using HTTP, SOAP is able to cross most firewalls, which allow port 80 traffic. This is a double-edged sword. Gone are the issues of configuring firewalls to open up special ports or adding tunneling to support RPC traffic. On the other hand, now it becomes much more complicated to lock down and manage services. Firewalls are beginning to analyze HTTP traffic to allow filtering of SOAP and other tunneled traffic. The whole endeavor bogs down into one of those messy, real-world situations of point and counterpoint. The best solution is to have good network administrators on staff to keep on top of things.

With Apache Axis, Web services are hosted in the servlet container. This is a quite sensible, given that we are talking about Web services. It is reasonably accurate to treat the Web-services layer the same as Web-application layer. Developing a Web service can be done with no more effort than developing a JSP. In a real application, however, Web services would likely follow more of the servlet pattern. That is to say, the Web service would call upon other elements of the J2EE architecture, such as EJBs, to achieve its function.

On the client side of the Web services architecture, things are a bit less standardized. As testament to the open and interoperable nature of Web services, the variety of different clients range from standalone programs written in other languages to Java servlets.

 Web services are often long, synchronous calls. Some clients can benefit by placing a JMS layer between the client application and the Web services stubs. This way, the client can benefit from JMS queuing without any changes on the server side.

Recently, Amazon and Google introduced Web services interfaces to their businesses. Being able to integrate with their services brings value to both parties involved, even when they cannot foresee how and by whom those services are used. Those services that should be openly accessible are prime candidates for Web services. In other cases, the benefits of a building on the Web services standard must be weighed against such services inefficiency and immaturity. Often RMI or IIOP are better choices within your own tightly coupled systems.

 As usual, the architecture for securing systems is lagging behind our ability to open up systems. There are existing security standards that cover various pieces of the security picture, but there’s no standard for putting everything
together to secure Web services. Web services need to be able to guarantee the following:

Authentication .  The identity of the provider and client must be verified.

Authorization.  There must be permissions for controlling access and Web service usage.

Confidentiality.  The contents of the conversation must be protected.

Integrity.  It must ensure that a conversation isn’t changed or altered.

Broad outlines and prototypes for a standard security layer are underway. The WS-Security standard is one to keep an eye on. WS-Security supercedes the SOAP-Security proposal and specifies a set of standard SOAP extensions
to use. XML Encryption and XML Digital Signatures are both a part of the WSSecurity standard. The encryption of message contents is covered by XML Encryption, while XML Digital Signatures are used to sign the contents and
guarantee their integrity. SSL is often used to secure the Web service call on the wire. For now, WS-Security looks to be the front-runner for a Java standard. Nevertheless, it remains an early adopter technology because a Sun standard does not exist for it yet.

       Be aware that many existing Web services are not conformant with WSSecurity. In fact, most Web services are either unsecured or secured in an ad hoc manner.

Enterprise applications should definitely be designed with an eye on Web services. The Web services security question is being addressed, and a standard should emerge shortly. This is simply too critical a piece of the enterprise architecture for that not to happen. Within a J2EE enterprise application, JAX-RPC represents the best path to Web services and receives our recommendation.