With ServiceLayer, adding SOAP and REST web service to your Java applications is as easy as point-and-click... and it can all be done at runtime. By using the graphical user interface, you explore an application, select classes and methods to deploy as services, and your done. Coding is no longer required. Additionally, web services can be added to standalone applications, container-based systems, third-party programs, and class libraries.
Compared with traditional methods for introducing web service enablement, ServiceLayer:
- Dramatically lowers project costs and shortens implementation times
- Eliminates expensive custom programming
- Shortens the learning curve
- Removed the need to master the complexities of JAX-WS, JAXB, SOAP, XML Schema, REST, JSON, or other web services technologies
Recently InfoQ spoke with Mark Hansen, founder and President of AgileIT.
We started off the interview with "how did you come up with the idea for service layer?"
The basic idea came grew out of my strong belief that "there must be an easier way" to create and deploy web services for Java applications. In the 1990s, I founded and grew an eBusiness consulting firm named Kinderhook Systems. Kinderhook handled end-to-end development - from front-end web page design to back-end integration. The hardest part was always integrating the browser functionality with the back-end. We called this the "service layer" - essentially a set of services built on top of the enterprise systems, that provided a standard API for the front-end integration.
After selling the company I began writing a book titled "SOA using Java Web Services" (http://www.amazon.com/SOA-Using-Java-Web-Services/dp/0130449687). My goal for the book was to teach readers how to design and build a "service layer" using Java Web Services technology. Unfortunately, I found that it was very difficult to build such a middleware layer using JAX-WS, JAXB, and the other Java APIs for web services. These technologies proved to be very low level tools not well suited to the task.
This was a frustrating experience. But, the deep experience that I gained with the Java APIs led to the realization that I could use them, under the covers - via bytecode manipulation - to create a framework that does, in fact, make it easy to publish the "service layer" web services necessary for front-end integration with back-end Java applications and class libraries. As a result, I founded AgileIT in 1997 to create the ServiceLayer product. The goal which ServiceLayer achieves is to make SOAP and REST web services development and deployment very simple. Rather than a complex programming task requiring mastery of difficult APIs like JAX-WS, with ServiceLayer, creating and deploying web services becomes a simple point-and-click exercise.
Some companies prefer different internal and external APIs, as well as keeping the data structures different, how does ServiceLayer handle this?
With ServiceLayer, you select the classes and methods that you want to deploy as web services (via the administration GUI), and then the product automatically generates and publishes endpoints that enable invocation via SOAP or REST. WSDL (or WADL in the REST case) is also automatically generated and reflects the standard JAX-WS or JAX-RS mapping of the selected classes. Some people refer to this as a declarative approach. It is also called a "code-first" approach, because the web services interfaces (e.g., WSDL) reflect the underlying structure of the Java classes.
Some people insist that web services should be written in a "contract-first" manner. That means writing the WSDL first, generating proxies for the desired WSDL, and then mapping those proxies to the underlying business implementation. One reason that some people like "contract-first" is that the proxies and mapping code form a separation layer between the web services endpoints and the underlying implementation.
ServiceLayer is very compatible with the "contract-first" approach. In addition, it offer the advantage that you don't need to master XML Schema or WSDL in order to implement "contract-first". With ServiceLayer, you can define a web services interface using Java - and map this Java API to your existing business implementation. Then, you simply deploy your Java API using the ServiceLayer point-and-click interface.
In practice, however, we have found that most Java applications already have APIs that are suitable for deployment as web services with ServiceLayer. Why create a new layer when you don't have to? In addition, AgileIT continues to add new functionality to ServiceLayer that makes it intelligent about how to deploy web services against particular frameworks. For example, ServiceLayer is very smart about dealing with Struts applications. It is aware of how Struts manages sessions and workflow, and can create web services from Struts applications that maintain sessions and other forms of application state as necessary to deploy services that let users log in, add items to a shopping cart, check out, etc.
The other drawback of the traditional "contract-first" approach is that you need to author your own WSDL. That can be a big stumbling block for many development teams, as most Java programmers are not very fluent in WSDL or XML Schema. We've found that the ServiceLayer approach of using Java to define a "separation layer" is more practical than a WSDL-first approach. In addition, as we did for Struts, we plan to continue adding framework intelligence to ServiceLayer, so that a level of separation can be achieved out-of-the-box for additional platforms (e.g., Spring).
Are the endpoints securable?
Yes, you can secure endpoints using HTTP Basic Authentication and/or cookies along with SSL for encryption. Support for Web Services Security (WSS; formerly WS-Security) on SOAP endpoints is planned for the near future.
How can the web service definition be promoted across environments or integrated into integration testing environments?
ServiceLayer can be configured and tested in a testing environment, and then migrated to production by simply exporting and importing the configuration file - named sl-config.xml. For example, if you are testing on a server named qa.host.com, and you have tested and deployed an endpoint at http://qa.host.com/myapp/some-soap-endpoint, then you can simply load the sl-config.xml into your production installation of ServiceLayer at host.com, and the same endpoint will be deployed at the production address: http://host.com/myapp/some-soap-endpoint.
Does SL need to be installed on every deployed JVM? What is the process for scale up/out?
Each JVM requires only the "SL-Provider" component of ServiceLayer. SL-Provider is the servlet component of ServiceLayer that sends/receives the SOAP or REST messages and delegates invocation of the underlying business implementation to the Java application or class library that is being web service enabled. The entire serialization/deserialization process (i.e., converting from a SOAP or REST request to a set of Java method parameters; and, in reverse, converting from the Java return value to a SOAP or REST response) is handled be a separate component named "SL-Serializer". A single SL-Serializer can be shared across multiple JVMs. This architecture has multiple benefits.
- ServiceLayer can used with Java 1.4.2 (which does not support JAX-WS or JAXB, or even annotations which are traditionally required for Java web services) since the SL-Provider component runs under Java 1.4.2. This is configured by having the SL-Serializer component running under a separate JVM verion 1.5 or higher).
- The CPU and memory intensive serialization/deserialization operations can be off-loaded from the JVM that is running the application being web service enabled. As a result, there is very little impact of performance and resource utilization of the Java application that is being web service enabled.;
- ServiceLayer is highly scalable. The installation of SL-Provider in a JVM has minimal impact on resources. You can share a single instance of SL-Serializer across multiple SL-Provider instances, and add additional SL-Serializer instances only as needed (or add memory/CPU to a single instance of SL-Serializer if preferred).
What's the industry response been like so far?
The response so far has been very enthusiastic. Lots of the Java applications developers and architects we have spoken with are very interested in finding a simpler way of providing web services access to existing Java programs and class libraries. The "no coding" approach seems particularly popular - particularly with users who are responsible for applications where source code is not available, or the original development team has disbanded. In situations like these, it is very expensive and time consuming to bring a new team up to speed just so that they can write code to add web services to the application. The other area where we are seeing a lot of interest is among companies that need to expose internal applications (e.g., Customer Support) to customers or business partners for web access or integration over the Internet.
More information on ServiceLayer can be found on the AgileIT website, or to test run ServiceLayer go to http://agileitinc.com/download. There's also a video showing how to enable an existing Java application.
