No one involved in Web development needs to be reminded of the continued rapid changes in the industry. Even with the current financial downturn, driven by the burst of the Internet bubble, innovation is still happening on many fronts. Nowhere is this truer than in the evolving area of Web services.

Feeling overwhelmed by yet more change, I recently decided to do something I usually never do and subscribed to several Web services-related mailing groups. In this case, some SOAP-related lists would do the trick, especially since SOAP (Simple Object Access Protocol) is one of the key elements of Web service-related architecture. Not long after I signed up, the mail started to trickle in. Actually, it was a flood.

Browsing through several dozen e-mails, I got the sense that implementing the SOAP protocol was not for the faint of heart. Contributors to the list span all levels of expertise from beginners looking for assistance in configuring their SOAP demo environment to open-source code developers making revision announcements. You would also get the occasional frantic message from someone who has had enough but doesn't have a clue how to unsubscribe from the mailing list.

The reason I bring this up is that familiarity with all of the standards that comprise Web service architecture is one thing (SOAP, WSDL, UDDI, etc.); implementing a working Web service is an entirely different subject. In response, a new breed of application servers and IDE-like development tools is hitting the market to address the complexities of e-business integration and drive Web services into the mainstream. One such Web service integration platform is Shinka Integration Server (IS), from Shinka Technologies.

Overview
The Integration Server suite is available in three editions: Integration Server Java Edition, Integration Server Business Edition, and Integration Server Enterprise Edition. Each edition provides an HTTP-based application server, command center, and designer tool containing one or more adapters. The platform provides you with all you need to add one or more SOAP-based interfaces to your enterprise application. The designer tool helps develop the service interface and automatically generates an XML schema, WSDL service definition, and a test copy of a SOAP request message. The Tomcat-based application server handles secure and non-secure HTTP SOAP requests using dedicated servlets that are specific to your service. The command center runs as a separate HTTP server and provides various administration capabilities including configuration and transaction monitoring.

IS provides you with an XDK library and code generation tools for translating SOAP request (and reply) messages to and from your enterprise application. IS 1.2 not only provides all of the necessary libraries for handling marshalling and dispatching of SOAP requests, it will do a lot of the hard work for you by generating the initial "stubbed out" version of the integration code as well as test SOAP messages.

Installation
I installed a CD copy of the Business Edition on a Windows-2000 server running on a 1 GHz Athlon machine with 512M of memory without any major difficulties. During installation, you will be asked several questions that are typical of most Java-based product installations, including the JVM directory location, the installation directory, etc. The installation requires JDK 1.3 to be preinstalled, and conveniently provides a copy of the installation on the CD. If you're running an evaluation copy, you must request a temporary license key from Shinka. It arrives via e-mail and requires you to detach an XML formatted file to the configuration directory in the install area.

There were slight glitches during the installation. First, I needed to edit the XDK_ROOT and JAVA_HOME values in the SETENV.BAT file to point to the D: drive and not the C: drive that it appeared to default to. Second, the installation doesn't provide an Oracle JDBC driver, so I needed to place a copy of the CLASSES11.ZIP file in the lib directory and modify the SETCLASSES.BAT file. I had to hunt for a missing PDF file containing the installation instructions (later found on the CD). Then, the user and password I received from Shinka didn't work when I logged into the command center. My hacking skills saved the day as I tried the easy-to-guess admin/admin combination.

You will need to start up two programs through the command menu, the Integration Service and the Command Center. The latter is responsible for serving up the browser-based, administration facility. At this point, we're ready to start designing a Web service.

Developing a Service
Let's start by developing a simple Web service that will provide online billing and shipment services for company X. Assume the online order system exists behind a corporate firewall. Let's also assume transactions can be made through a series of client calls to an EJB session bean (see Figure 1).

Start up the Shinka Designer tool using the command menu and create a new project. Next, we need to create an XML schema that will be used by the SOAP interface. The schema will contain a combination of simple and complex XML schema types to define the input and output parameters of SOAP messages. In addition, the XML schema should include data types that define any SOAP exceptions that may be generated by the service. The designer utilizes a UML-based graphical representation to help design your XML schema. You can switch between a graphical representation and an XML-coded (.xsd file) version by switching between the tabs in the designer.

The next step is to create the SOAP service request interface using the designer. You need to provide a unique name for the service along with identifying input, output, and exception parameter names and XML schema types. Again, you can view an XML-formatted view of the interface or the WSDL definition for the service by selecting the tabs on the user interface.

Once you have defined the services for the project, you are ready to generate a series of service stubs. Depending on your platform, the designer can generate Java, C++, or Visual Basic code. (You also may generate enterprise JavaBean components when generating Java code). The stub code that's generated serves as the initial prototype for your implementation, and contains all of the necessary SOAP message conversion bindings to your target language. In fact, the stub is fully functional and can be immediately tested once compiled and configured into the IS server.

Deploying the Service
The next step is to deploy the service prototype to the Integration Server. This is done by configuring the ISCONFIG.XML file and creating a new service tag pair within the services element of the file. You will also need to make sure that any JAR files created for the service are included in the server's CLASSPATH.

Once you have a service prototype compiled and running on your Integration Server, you can use the designer tool to test your service. The designer will automatically create a test version of a SOAP request message and forward the message to the service. Then you can view the resulting SOAP reply message to assess your service prototype.

Once you are satisfied with the interface, you are ready to migrate the current stub to a fully functioning service. At this point, the designer will be of no further assistance in the continued development of your service (i.e., the tool cannot reverse-engineer existing code). This step requires you to substitute the stubbed-out code for fully functioning client calls to an enterprise application. It's up to the developer to be aware of client requirements and exception handling at this point, and to make sure all exception conditions are handled within the SOAP reply message. In our case, we'd be tying the various SOAP request calls to their corresponding EJB methods using Java. We'd also make sure all exceptions are being properly caught and transposed into SOAP exception element tags.

The beauty of the designer is that it takes care of many SOAP integration issues, including data marshalling (SOAP to native language bindings), service dispatching on the HTTP server, multi-threading, etc.

In addition to generating service-side code, the designer will also create client-side stubs, useful when you need to create SOAP service requests from a remote client.

The Command Center
The command center provides several administration functions that allow you to configure and monitor one or more Integration Servers from your browser (see Figure 2). From the command center, you can monitor the server logs and transactional activity as well as profiling data for each service request.

Additional Features

• Database logging and audit tracking
• Secure transactions using SSL and HTTPS request headers
• Generates EJB "skeleton" component code based on the Web service description
• Can run standalone (Tomcat server) or on several major application servers, including WebLogic
• Transaction monitoring

After working with the designer for a while, I noticed improvements that can make it more full-featured. They include adding wizards to help in the service configuration (instead of manually updating an XML file), the ability to edit and compile source code from the designer, and the ability to print from the tool. Since this product and similar ones in the marketplace are still in their infancy, I imagine they may add such features in the future.

Documentation
Shinka provides a set of PDF files containing a Getting Started guide and a series of User and Programming guides. Getting Started is especially helpful to those new to Web service development. It provides a good starting point to understand the technology, and for those interested in additional information the guides include several Web site links.

Obtaining a Copy
You can get a free one-month evaluation copy of Integration Server Version 1.2 by going to the Shinka Web site at www.shinkatech.com/licenses/license.phtml. You must fill out a simple registration form prior to downloading the installation package. You'll also need to sit tight and wait patiently for your license key via e-mail.

Conclusion
The Shinka Integration Server and designer tools take care of many initial setup tasks involved in creating a Web service by generating the XML schema, WSDL definitions, and code generation for binding SOAP messages to your platform's target programming language. Command center features, including user management and database logging, are useful when administering the Integration Server in a production environment.

Handling a lot of the tedious work involved in developing and setting up a SOAP-based Web service, Shinka Integration Server version 1.2 leaves you with time to do more important things - like checking your e-mail.

Shinka Technologies
1 Market Plaza
Spear Tower, Suite 3600
San Francisco, CA 94105
Tel: 415-293-7817

Web: www.shinkatech.com
E-mail: info@shinkatech.com
Available in three editions
Integration Server Java Edition
Integration Server Business Edition
Integration Server Enterprise Edition

Price:
Developer and runtime licenses start at $990 (U.S.). For further information, call Shinka sales.