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:
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:
Issues for Web services compared with other options:
WebSphere, 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:
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:
What can be converted to run as a Web service?
Most server resources can be converted or "wr
To continue reading for free, register below or login
To read more you must become a member of Search400.com
apped" to create 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:
Options implemented:
A call center staffed with representatives to answer verification calls
The original solution to deliver credit verification services.
Issues with the call center approach
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
Issues with the Web application approach
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
Issues with the APPC approach
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
Issues
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:
Other Web Services frameworks
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:
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:
---------------------------------------
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.
