When are Web Services Right?
Presented in Bovine style. No cows were hurt in the making of this presentation.Copyright © Aaron Bartell 2008 by
Aaron Bartell
Abstract
You can hardly get through a trade rag these days without reading
about XML and Web Services. The bummer is that the cited examples
usually entail making calls to "Hello World" or Fahrenheit to Celsius
conversion type applications. While these are incredibly useful
applications <grin> it doesn't really tell you how the real world utilizes
Web Services, or even better, how System i RPG shops are using
Web Services! This session will guide you through some real world
Web Service scenarios and give food for thought as to how you can
extend your organization's data and business logic through Web
Services. We will go through reasons to adopt Web Services vs. other
technologies and provide direction as to how a Web Service project
should be approached.
Traditional Communication
FTP – send a file across the wire and then run a remote
command (i.e. ftp>QUOTE RCMD MYCLPGM)
HTTP Form Hijacking – Dynamically build a URL query string
(http://company.com/page.cgi?var1=val1&var1=val2)
Raw Sockets from client to server
(yucky pooey, but fast)
Use a networked folder to place a request document and poll
it for a response.
SQL Stored Procedures
SMTP – send emails from one server to the inbox of another
and parse the emails for their content.
DCOM (proprietary Microsoft) and CORBA
Deciding on Web Services
Determine why web services are being suggested.
− Biggest Reason: Need to gain real-time access to a remote resource in an
automated, ‘program call’ fashion.
− Business partner mandate (maybe they are switching from an fixed length data
FTP approach to HTTP XML Web Services and require you to switch over)
− Simply want to learn about the technology. This is a VERY valid reason,
because in the past couple years XML and Web Services have become quite popular. Even if they aren't the most performant or standardized methodology, the players adopting the technology is enough to warrant the learning effort.
− Going to save the company money and will pay for itself in a matter of a few
months. (In reference to Example #2 later on)
− Desire for “loose coupling” to get away from things like ODBC drivers or
language specific features. Loose Coupling=XML is just text – most any language can work well with text.
Deciding on Web Services contd...
Determine who is going to make use of this Web Service
− Internal vs External
If internal,would SQL stored procs be more tightly coupled and possibly a
better approach?
If internal, does your company have tried and true proprietary
communication mechanisms in place that should be reused?
− Do you have control over both ends of the spectrum?
Pick the technologies that both parties already have implemented and are
Choosing the right time
You DO NOT need to have a Web Services project on the horizon to start learning
about the technologies now.
− Take the time to read trade rag articles (IBMSystemsmag.com,
SystemiNetwork.com)
− Go through WDSC Web Service tutorials. (in WDSC menu Help->Tutorials Gallery) − Setup Google Alerts for “iSeries Web Services”
− www.w3schools.com has some great, and short, tutorials. Perfect for lunch time
reading.
Web Services are now popular enough that your shop is near guaranteed to have
When NOT To Use Web Services
Data Replication
− Huge waste of bandwidth. For instance, to send a 9 digit customer number it
could take 5 times the data (e.g. <ProductionCustomerNumber>123456789</ ProductionCustomerNumber>)
Replacing solid/existing software implementations
− Working software should never be replaced simply for the sake of hype. For
example, EDI remains the most prominent form of data exchange and will be around for quite some time – hey RPG is still alive isn’t it? Only when EDI has dipped below 30% usage should you consider scrapping/replacing it. EDI
package vendors are very aware of XML and oft times have translators so you can take your EDI formats to/from XML formats.
Real World Example #1
Need: ABC Company needs to verify that potential customers have a high enough credit rating
to provide them with house insurance and adjust the premiums accordingly.
Process: Customer navigates to ABCCompany.com and goes through a web site wizard like
process that requires the entering of their personal information. That personal information is captured and behind the scenes an XML document is composed. The XML is sent via HTTPS POST to https://Equifax.com/webservices/checkcredit.cgi. Equifax receives XML, submits a process to batch on their machine, and then responds back with an XML document containing a unique transaction id. That transaction id is used to compose a second XML document on ABC Company's iSeries which is sent to Equifax to poll for the credit report. If the credit report is done processing it will be passed back, if not it will give a message that it is still processing and to check back again later. This process continues until the credit report is available (usually takes 2 to 8 seconds). Lastly the credit report is used to determine if the user on the web page will be allowed to continue and be provided an insurance policy with ABC Company.
Technologies/Specifications: HTTP, SSL (client and server side certs), XML. Specifications
documented via PDF and XSD. No WSDL. No SOAP. ABC Company used RPG on the iSeries to do all communication, XML composing and XML parsing.
ROI: ABC Company is now able to automate the process of writing new home insurance
policies without human intervention. Being able to check the credit of potential customers also keeps unprofitable policies from being written.
Real World Example #2
Need: ABC Company needs to reduce the cost of creating, enveloping and mailing paper
invoices to its dealers for parts ordered. ABC Company enlists a third party, WeMailInvoices, that offers this service and has an SLA** (Service Level Agreement) which coincides with the dedication to their dealers for prompt creation and delivery of invoices.
Process: Once an hour ABC Company reads through a DB2 table and batches together
invoices to be sent to WeMailInvoices. As records are read an XML document is composed. Next the document is sent via HTTPS POST to WeMailInvoices. WeMailInvoices writes it to their database for further processing and provides an XML response back to ABC Company who marks those invoices successfully sent.
Technologies/Specifications: HTTP, SSL (server side only), XML. XML spec created by ABC
Company and third party complied. ABC Company used RPG on the iSeries to do all communication, XML composing and XML parsing.
ROI: By outsourcing it's paper invoice processes ABC Company was able to save $15K/month
which paid for the development of Web Services in 3 months.
Real World Example #3
Need: ABC Company needs to provide item pricing information residing on their iSeries in RPG
logic to in-house .NET programmers who are creating a new GUI front end for Order Entry. The process to calculate an items price entails 15 DB2 tables and a lot of business logic so it was decided to re-utilize the already tried and true RPG code on the iSeries. ABC Company has plans to expand into more Web Services as needs arise. XML Web Services were chosen because of the variety of languages and platforms within the organization.
Process: Thick client GUI is displayed to ABC Company's “Order Taker”. Order Taker enters
items the customer is requesting over the phone and, as needed, requests are made to the iSeries to calculate item prices. Each request entails a SOAP/XML HTTP POST sent to the Apache server to request an item calculation. A response is immediately provided and the item's price is displayed on the Order Takers screen. Round trip Web Service has sub second response times.
Technologies/Specifications: HTTP (Apache on iSeries), SOAP/XML. WSDL was used to
define the Web Service and XSD to define the XML messages. ABC Company used RPG on the iSeries to do all XML receiving, XML composing and XML parsing. WSDL stored on iSeries under Apache (i.e. http://iseriesip:8181/calcitemprice.wsdl)
ROI: Re-utilize business logic on the iSeries allowing them to "get to market faster" than if they
had to re-implement that same in .NET which would require a large amount of knowledge
transfer. Provides single point of entry for any programming within ABC Company to calculate an items price.
A Web Service Project
If you are being asked to communicate with a web service already in
place, where your iSeries is the client and the Web Service is on a
remote server...
− Learn what technologies are involved at a high level. Most times it will be HTTP/
S, XML, XSD and sometimes WSDL/SOAP, but I am also seeing MQSeries on the rise as a transport mechanism. In the most bare form you will need an
example XML document and the URL where the web service is located.
− If SSL is being used, setup the *SYSTEM certificate store in the DCM (Digital
Certificate Manager) which is available in the HTTP *ADMIN instance (i.e. http:// iseriesIP:2001). Contact me for tutorial on how to do this.
− Ask for any login profiles/keys that will enable you to utilize the Web Service.
This login information is usually sent in the XML document but is sometimes used for what’s called HTTP Basic Authentication. Login information is multi purpose – validate you have access to the Web Service and ensure charges are applied correctly (if it is a pay per use style Web Service).
− If a WSDL is provided, use that to discover what the different “actions” (read
RPG sub procedures) are along with their messages (read data structures). Use WDSC's Web Service Tester to do some initial calls to the Web Service.
A Web Service Project contd..
If you are creating the web service to be offered from your iSeries...
best to figure out technologies before you take on a big project
−
Allows you to rule out what will and won’t work without tying yourself to a
vendor/language/methodology/process/framework.
−
Gives insight as to what will be required if new technologies are adopted.
For instance, you can utilize the Java to RPG web service wizards in
WDSC, but that inherently means your change management system will
need to facilitate Java infrastructure/deployment, your QA team will need
to be versed on how to test the new environments, and your helpdesk
will need to know how to support the new environment.
−
Allows the testing of performance without getting caught up in business
rules. Besides being fun, slapping together an application that does a
whole bunch of XML processing by trying to break stuff will give you
insight as to what your limitations/weaknesses might be.
A Web Service Project contd..
− Determine the “actions” you want to offer (e.g. CalcItemPrice, IsCustomerValid).
This can be done simply with a Word document which will later be re-entered
into the WDSC WSDL editor if you choose to go the WSDL route – you don’t have to. You could relate this process to creating an RPG service program and determining which sub procedures will be EXPORTed.
− Determine and compose the messages that will be passed back and forth for
each action.
Use WDSC's GUI XSD (XML Schema Definition) editor to do this. Creating
an XSD is similar to creating an RPG data structure or DB2 table. You are simply putting rules around the XML data names and their types.
− Publish the web service information on an appropriate server. This does not
need to be a UDDI server. It can be as simple as a shared folder on your
network with a PDF describing the location, actions, and messages for the Web Service.
Use Free Tooling
Eclipse GUI XSD Editor – Download for free from www.eclipse.org
It is important to know the tools available to you so your path to successful implementation of web services is as smooth as possible. The following are some of the tooling I use on a regular basis to aid in my web service efforts.
Use Free Tooling contd...
Use Free Tooling contd...
SOAPSonar Personal Edition – Download for free from www.crosschecknet.com
Great for testing a web service without writing any code.
Also very useful for seeing the actual XML being sent and received back.
Use Free Tooling contd...
SOAP UI – Download for free from www.soapui.org
Great for testing a web service without writing any code.
Also very useful for seeing the actual XML being sent and received back.
More with XML than just Web Services
This is a “mashup” of RPG producing XML being fed into an
Adobe Flex engine. All of this is being hosted on a System i under Apache.
More with XML than just Web Services
This is a “mashup” of RPG producing an XML document
according to Microsoft Office's standard. A .xls extension is then put on it and Microsoft Excel can then open it. Note it requires Microsoft Office 2003 or after.
More with XML than just Web Services
This is a “mashup” of RPG producing an XML document according to Microsoft
Office's standard. A .doc extension is then put on it and Microsoft Word can then open it. Note it requires
Microsoft Office 2003 or later.
Online tutorial:
Aaron Bartell aaronbartell@mowyourlawn.com
lead developer of
RPG-XML Suite
(www.rpg-xml.com)and owner of
www.MowYourLawn.com
and check out his latest effort at
