Web services overview
A Web service is basically a transaction service that runs over the Web using effectively an XML remote procedure call (RPC). At the simplest level, a client encodes a request as an XML message and sends it over the Web to an application service running on a server. The server processes the request, encodes a response as an XML message and returns it to the client.
Web services runtime environments are implemented by many vendors on many platforms. Often, Web services are used in places where other distributed transaction technologies were once used:
- RPCs
- Electronic Data Interchange (EDI)
- Remote messaging solutions such as MQ
- APPC and TCP application-to-application programs
- Remote database access
- Access between applications running on Microsoft and IBM servers
- Distributed applications internally
Why are Web services useful?
The advantages and weaknesses depend on what option above you are comparing to Web services.
Here are some advantages to Web services that apply to some of the options above:
- There's a lower cost to implement utilizing existing Web infrastructures better.
- It has an open standard architecture for linking different applications types on different servers.
- It doesn't require proprietary tools, software or code for implementation.
- There's more support from vendors in tooling and runtime environments.
- By industry, supply chains are implementing Web services registries integrating suppliers and customers (Wal-Mart and UCCnet).
- It connects applications written in different languages easily (Java, COBOL, Visual Basic, etc).
- RPG programs can be wrapped by Java beans as a Web service.
- It saves money in development/maintenance by promoting application reuse.
Issues for Web services compared with other options:
- Other options may be working fine and don't need to be replaced.
- You need a basic Web infrastructure setup to run Web services over the Internet.
- Performance may not be as high as some other point-to-point options.
- Developers don't know HOW to build Web services.
WebSphere, ...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
WebSphere Express and other application servers such as Tomcat, Jboss and others can run Java-based Web services applications well.
If you look at the issues listed above, probably the BIGGEST on the list is IT lack of experience creating, setting up and running Web services. That's the biggest hurdle I've faced so far.
Basics of a Web service invocation
The steps in a SIMPLE point-to-point Web service are as follows:
- The client creates a request and encodes it as an XML message using a SOAP framework.
- The client invokes a Web service on a server by URL sending the request.
- The server decodes the request from the XML message and processes it.
- The server returns a response if the request succeeds or returns a fault (error) if it fails.
- The server response is encoded as an XML message using the SOAP framework.
- The server sends the response back to the client.
- The client receives the response as an XML message and decodes it to access data.
- The client processes the response.
Web services can be discovered dynamically using a broker
A more complex Web service would involve all the steps in a Web service life cycle and use a broker (or registry) to discover the service and how to invoke it as well. The steps in this scenario are more complex but are summarized below:
Attributes of Web services
Some attributes that distinguish Web services from other types of distributed applications include the following:
- Self-contained -- The Web service interface provides access to everything the client needs to run the service.
- Self-describing -- The WSDL document completely describes the service to a client so the client knows how to invoke and even create the client access to the service.
- Accessible over the Web -- Web services usually require much less work to implement using existing HTTP access in most networks today.
- Dynamic -- clients can dynamically discover one or more services in a registry, bind to the service using WSDL info and invoke a service if needed. This fits supply-chain businesses well.
- Language independent – Web services DON'T require Java only like RMI. They can be written in other languages such as C and Visual Basic.
- Platform independent -- Web services are supported as a standard access model now on all platforms (IBM, Microsoft, Sun, etc). As a result, Web services can be run for external clients or used internally to connect applications running on different platforms.
What can be converted to run as a Web service?
Most server resources can be converted or "wrapped" to create a Web service.
- 5250 programs can be converted to send/receive messages using tables or procedures.
- Other server programs are easy to wrap calls to with a Web service.
- Databases can be set as services using Java bean wrappers as well.
- Java and DB2 stored procedures can be wrapped as Web services.
- Almost any Java bean can become a Web service.
Web services roles
A complex Web service involves a provider that creates and runs a Web service, a broker using a UDDI-compliant registry that offers Web services to clients (users or requestors) and the client who finds and uses a Web service. The activities for each role are summarized below. For a simple Web service, you skip publishing the service to a broker or registry and just publish the URL to access the Web service with the WSDL document directly to the client you want to call your service.
Provider:
Creates a Web service
Publishes a Web service to a registry
Runs a Web service
Broker:
Provides a registry for published services
Clients search the registry for matching Web services
Requestor:
Searches a registry for a Web service
Finds a service
Binds to a service
Runs a service
Web services life cycle
For a complex Web service, all the steps below would be included during the life cycle of a Web service:
Create:
Design and create the Web service
Publish:
Publish the service to a registry, either private or public
Registry can be a broker, database or directory server
Advertise:
Promote the service to targeted clients via URL or a registry
Discover:
Clients search a registry to locate a service
Bind:
Clients use service definition to bind to the service
Invoke:
Clients invoke the service
A simple Web service would publish the URL and WSDL document directly to a specific client. The majority of Web services today are simple point-to-point connections either between businesses or run internally to integrate different applications on different platforms.
An example business case for Web services
I developed an APPC link to banks for a credit company. Every time we needed to link to a new bank, I had to create a new link similar to an existing one and usually make small modifications to the APPC code to fit the new bank's data and transaction formats.
Our Web services case study: credit verifications
A credit services company performs consumer credit verifications for banks when customers open new accounts.
Business keys to the verification service:
- Service costs drive customer pricing
- Information quality -- accuracy of rating
- Turnaround time for a call
- Percent of new accounts verified with credit company
Options implemented:
- A call center staffed with representatives to answer verification calls
- A Web application to enter verification requests remotely
- An APPC application linking bank desktops to the credit company
- An Web service application linking bank desktops to credit company (under review now)
A call center staffed with representatives to answer verification calls
The original solution to deliver credit verification services.
Issues with the call center approach
- Very high call center costs drive high customer pricing.
- Information quality -- accuracy of rating is very good.
- Turnaround time for a call is usually too long for bank representative.
- Percent of new accounts verified with credit company -- company didn't know this figure.
A Web application to enter verification requests remotely
A simple Web application written in Visual Basic running on IIS server uses IBM MQ to send a message to an AS/400 request handling COBOL program that performs a complex lookup in an RPG program.
Benefits
- Less expensive to operate than call center staff.
Issues with the Web application approach
- Bank representatives don't want to re-enter information in a browser already in their desktop application.
- Representatives have to learn the information format required by credit company
- Very costly to implement(more than $30,000).
A better option is a simple JSP that runs a stored procedure call to RPG program.
An APPC application linking bank desktop to credit company
Generation 1 B2B. Created custom APPC applications for a credit company and bank. The bank sent a request to the credit company APPC handler, which calls RPG lookup program and returns results.
Benefits
- Average call turnaround dropped from three minutes to three seconds
- Cost to operate was 80% less than the call center
- Information quality improved since bank data mapped to credit format correctly
- Bank representatives saved a lot of time
- Credit company cut pricing for service by 50%
- With low price and fast turnaround and automated verifications, sales volume rose 400%!
- Implementation costs were about $20,000
Issues with the APPC approach
- Very difficult, long process for banks to implement
- Each bank requires a custom connection project to setup
A Web service application linking bank desktops to the credit company
A common Web service application can connect ANY bank to the credit company to automatically process verifications. A client application for the Web service will be supplied to each bank that includes a user-definable data map for request inputs and response outputs to map data into the client database WITHOUT programming. The Web service client securely links to credit company server over existing Web links.
Benefits
- You have all the benefits of the APPC solution.
- There are lower implementation costs initially (less than $10,000).
- There's no significant implementation challenges for banks.
- One solution can be reused with all banks without modification.
Issues
- You need to prototype a solution for a credit company.
- Performance MAY not be as fast as APPC, BUT it will be acceptable.
Clearly, the Web services approach will allow the credit company to rapidly expand its existing business-to-business sales and customer base at a low cost and with minimal requirements for IT services on the banks end -- a MAJOR victory.
J2EE technologies for Web services
Web services run as either J2EE client or server applications. The client portion creates the request and receives the response. The server processes the request returning a response. J2EE technologies that can be used in a Web services implementation include the following:
- http
HTTP is the most common protocol used over the Internet, and most companies have opened HTTP access through their networks for applications to access the Web. What's nice is Web services use the "common Internet highway" companies have in place now.
- XML
XML is used to wrap all messages in Web services with headers and envelopes for data or documents. XSL is often used to transform data and document formats between clients and servers.
- Simple Object Access Protocol (SOAP)
This is a standard for defining XML message formats in a Web service environment. Apache Axis provides the standard reference implementation of a SOAP protocol. WebSphere and open-source application servers use the Axis framework to create and parse SOAP messages.
- Web Services Description Language (WSDL)
This defines the request and response message formats for a Web service, the URL to invoke the service and other service information. WSDL is used to generate Web services applications AND, at runtime, to provide configuration information to Web service applications.
- Universal Definition Discovery Interface (UDDI)
This is a standard definition of a Web services broker architecture. IBM, Microsoft and others run actual UDDI servers for production and test. Applications are published by providers and stored by a specific broker.
- Java Web services frameworks: JAXP, JAXB, JAXR, JAX-RPC, SAAJ
JAXP -- Java interface to XML DOM and SAX parsers
JAXB -- Java XML binding framework binds XML to Java objects
JAXR -- Java for XML registries access UDDI service brokers
JAX-RPC -- Java RPC for invoking a Web service
SAAJ -- SOAP with Attachments API for Java
Other Web Services frameworks
- WSIF
Web Services Invocation Framework.
- WSIL
Web Services Inspection Language.
- WS-Security
Web Services Security.
- JSR-109
JAX-RPC implementation: Web services for J2EE
- Web Services Gateway
Gateway service to access remote Web services for clients
All of the OTHER Web services frameworks listed above are available in WebSphere Network Deployment server version 5.02 today.
Building a simple Web service in WDSC
Use the WDSC Web interaction wizard for iSeries Web services
IBM WDSC offers a great tool to build simple iSeries-hosted Web services quickly: the Web Interaction wizard. I've used it for several years and like it. With no technical knowledge of Web services and only a conceptual model of creating an RPC that runs over the Web to your server, you can easily generate and test a simple Web service in three basic steps:
- Create a Program Call bean
In a Web project in WDSC, you have a Java option to create a Program Call bean that calls a host program (RPG, COBOL, etc). This wizard generates a PCML file that describes the program to call parameters to send and results to receive back.
- Create the Web service using the Program Call bean
Use the Web services wizard to create the Web service from the Program Call bean. Typically you specify which set methods (setName, etc) are used to set parameters first, specify get methods (getPayAmount, etc.) to get the results of the Web service invocation, select options for generation and then generate the service. Depending on the options you selected, when you're finished you have one of the following:
- A basic Web service defined with WSDL and Java code wrapping SOAP messages
- A client application to run the Web service
- A proxy application to test the Web service
- Publication of the application to a test registry to access the Web service
- Test the Web service in WDSC with the WebSphere Test environment
You can launch the Web service automatically at the end of the generation in step 2 or manually. You launch the Web service running on the server first and then invoke the client application in another browser window in WDSC to access it. If you want, you can even test the client application for the service remotely from another desktop PC in your company be specifying the name or IP address of your PC instead of localhost in the URL.
The only issue I've found at times with the WDSC Web interaction wizard for creating Web services is the need for fix packs to solve problems with the generation. Fix packs to solve most problems are usually already available when you need them. The automated update manager for fix packs in version 5.1.0.2 has had problems running correctly for some customers as well, so it's safer at this point to manually download fix packs from the IBM Web site.
Other options for creating Web services
I see three other options you might look at IF you're NOT creating an iSeries-hosted Web service (e.g., calling an RPG server program for the service):
1. Using general Web services wizards included in WDSC
WDSC in version 5.1 now includes other tools that can generate a Web service. Not QUITE as simple as the iSeries Web services, the Web interaction wizard can generate Web services for OTHER scenarios: a Java application running on any server, a DB2 stored procedure call on any server or just any simple Java bean.
2. Using command line tools in WDSC Advanced
You can use command line tools to create a Web service from any Java bean or a WSDL document. These tools MIGHT be useful if you needed to programmatically create a Web service.
3. Writing a Web services application in Java
You can also write a Web service directly in Java using new Java frameworks for Web services. IF you have good Java skills and DON'T have WDSC, you can write a simple Web service fairly easily using an IDE such as Eclipse. Writing a Web service and a client application in Java is not that difficult with the new Java frameworks in J2EE v1.4. You can download a Web services toolkit to add to Eclipse from the Sun Java Web site that will give you the jar files you need to add to your project for these frameworks. Building a simple Web service is a lot like writing an RMI distributed application. You only have to write the basic server and client code as if you were writing ANY Java application. You use command line tools: wscompile, wsdeploy to generate all the Web services coding you need for SOAP, etc.
Most of the time, you can avoid having to deal with SOAP coding in Java.
Next steps on the road to Web services
To learn more about Web services for iSeries development, you can visit several resources:
- WDSC online help
For defining how to generate an iSeries Web service easily!
- IBM's developer works site
For learning about Web services in WebSphere if you want to program in Java
- Apache site
For learning about Web services in ANY runtime environment
- Sun's Java site
For learning how to write a Web service easily in Java
- ebt-now site
For training and development options on iSeries Web services development
- QuickWebSupport
A free Web user group with iSeries tutorials for download for WDSC
---------------------------------------
About the author: Jim Mason, president of ebt-now, is an iSeries WebSphere architect, trainer and developer. ebt-now provides iSeries WebSphere, WebFacing engineering, development and training services. You can reach Jim at jemason@ebt-now.com.
