× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Jim,

First, I would ask a couple of questions. Who is going to be consuming these web services? Are they for internal use or external use? What programming languages are the developers familiar with? Do you want to do SOAP or REST? So many questions to answer.

For the last seven years or so, we have been using Websphere Express on the IBM I for our web services. We utilize the web service wizard in RDi to generate a Java front end for our RPG programs. The Java code is deployed in Websphere. These are SOAP based web services that are consumed by our .NET developers. It makes it easy for them because they import the WSDL file which generates the interface code for them. This approach does require buying RDi Business Developer in order to get the web service wizard functionality. This approach has worked well for us since we don't have any Java expertise here. We have over 60 web services deployed using this approach.

I know that some people say that REST web services are the way to go these days due to performance and a less wordy interface. For us, we haven't experienced any performance issues with ours. The other downside to REST web services in my opinion, is the development effort to implement them both from the provider and consumer side. On the provider side, you need to parse the input and build the output string yourelf. Same way on the consumer side. There may be code available that makes it easier than building the entire string manually. With our approach, the generated java handles all of that for us. I'm sure others will disagree with my opinion. Having said all of that, if you want to call these web services from the browser via ajax calls, I think REST is a better fit than SOAP due to javascripts ability to call the two types of web services. It likes REST better.

I have looked at the IWS the last few years to see if that is a better option for us, but I haven't been convinced yet. The one thing I don't like about it is it is hard to manage the generated objects and move them between a test and production environment. At least I haven't found a way that works very well. I should say this opinion is based on what I have read about it, I haven't actually tried it.

Hopefully, this is helpful information.

Dean Eshleman
Software Development Architect

On 5/3/2016 9:12 AM, Jim Oberholtzer wrote:
Folks:



I have a customer that is about to take the plunge into web services. They
first need to choose if they use WAS 8.5 Express, IWS or TOMCAT. Some of
the IBM i instances have the Zend server so they would use that when
available. Next they need a good primer about design and implementation.
I've found the basic web sites from IBM but I'm wondering if the group has
some suggestions on best practices and resources to use.



The customer is at V7R1 now but will be at V7R2 very soon and potentially
V7R3 by end of year. Any comments on the IBM i environment as it relates to
web services would be welcome as well.



While I can build and deploy a simple web service, I am far from an expert
therefore my request to you.



--

Jim Oberholtzer

Agile Technology Architects



______________________________________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.