Re: RPG Web Service Architecture

[Aaron Bartell <aaronbartell@xxxxxxxxx>]

>That way, we know the web service calls are coming to us from our 
application. Does this sound right?

Correct.  Just make sure another Apache instance isn't created that has 
the same ScriptAliasMatch that goes to the same CGI library as the SSL 
configured Apache instance because then that would defeat the purpose 
(just bringing that up because it has happened before :-).  Or maybe a 
better way to state that would be to say you should have all of the web 
services secured by client side certificates in a separate library from 
other CGI web services.  Sure you could do it all from a single Apache 
instance through configuration, but then you would most likely have to 
continuously modify your Apache config as new web services were added.

Another security measure you could take is have a network appliance in 
front of your AS400 and only allow certain IP addresses to talk to your 
AS400.

Also note that you could have a single user/password that .NET uses in 
it's communications to the AS400 (wasn't sure if you were thinking you 
would need one for each insurance agent that was on the ASP.NET side, 
but you really don't).

HTH,
Aaron Bartell
http://mowyourlawn.com

Dean.Eshleman@xxxxxxxxxxxxxx wrote:
> Aaron,
>
> Thanks for the explanation.  We only want our web services to be called 
> from our .NET web application.  We are a health insurance/financial 
> services company and the web services provide information to the person 
> logged in about their accounts.  If they don't have an account (purchased 
> any products from us), they won't be given a login.  At this point, these 
> are inquiry only web services.
>
> Based on your explanation, it sounds like we would install a certificate 
> on the IIS server (client side) where the .NET code is, and also have one 
> installed on the Apache server on our System i.  That way, we know the web 
> service calls are coming to us from our application.  Does this sound 
> right?
>
> Dean Eshleman,
> MMA, Inc.
>
>
>
>
> Aaron Bartell <aaronbartell@xxxxxxxxx> 
> Sent by: web400-bounces@xxxxxxxxxxxx
> 12/11/2008 01:13 PM
> Please respond to
> Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
>
>
> To
> Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
> cc
>
> Subject
> Re: [WEB400] RPG Web Service Architecture
>
>
>
>
>
>
>    What is the context of the web service (i.e. price lookup?, order
>    submission?).   If it is going to be used outside of your company then 
> you
>    will most definitely want to have some sort of credentials to identify
>    what party is communicating with you.  Note that it doesn't have to be 
> an
>    OS400 user/password but could simply be a DB2 table with user/password 
> in
>    it that you chain to.  The other approach would be to use HTTP Basic
>    Authentication (section 8.7 in book). 
>
>    If you want to do SSL for the transmission (i.e. digital certificates)
>    then you can do that without touching your RPG programs or XML.  You
>    simply head over to Verisign (or other preferred vendor) and purchase a
>    certificate by providing them with some information from your machine
>    (which should have been saved when SSL was first setup) and then 
> install
>    the cert they give back to you on the AS400 using DCM and then 
> associate
>    it with the Apache instance that is doing the XML web services.
>
>    Yet another more secure approach would be to require SSL certs on both
>    ends of the connection (so the client would also need to get a 
> certificate
>    they would transmit to you for the handshake).  Then you would allow 
> that
>    certificate to communicate with your Apache server by adding it to the 
> DCM
>    and then configuring it in your Apache instance.  I didn't have the 
> time
>    to put that process in the book :-)
>
>    Hope that helps, and thanks for purchasing my book!
>
>    Aaron Bartell
>    http://mowyourlawn.com
>    Book/TrainingCourse: www.xml4rpg.com
>
>    Dean.Eshleman@xxxxxxxxxxxxxx wrote:
>
>  I guess I shouldn't totally blame the .NET developers.  Rather, the
>  designers of the page.  It is a client search screen and for some reason
>  they didn't want to implement it using paging.  I tried to tell them it
>  was a bad design, but nobody wanted to listen.
>
>  By the way, I do have the XML for RPG Programmers training course you
>  wrote.  It has taught me a few things already.  I'm still concerned about
>  security for a CGI based web service.  The method presented in the
>  training course isn't secure enough for us.  We want to avoid any user
>  id's and passwords on the .NET side.  From the reading I've done, it
>  sounds like digital certificates is what we need to use.  Do you know if
>  this can be done with a CGI based web service?
>
>  Dean Eshleman,
>  MMA, Inc.
>
>
>
>  Aaron Bartell <aaronbartell@xxxxxxxxx>
>  Sent by: web400-bounces@xxxxxxxxxxxx
>  12/10/2008 02:30 PM
>  Please respond to
>  Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
>
>
>  To
>  Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
>  cc
>
>  Subject
>  Re: [WEB400] RPG Web Service Architecture
>
>
>
>
>
>
>   >but the web developers don't want to callthe web service multiple
>  times, so I'm stuck with finding a solution.
>
>  Did they give a reason *why* they don't want to call it multiple times?
>  They might have a good reason, but more than likely they are ignorant or
>  lazy.  Returning 10k of records for each listing request wont scale real
>  well if you have a lot of users hitting that web service.  Instead they
>  should be making multiple requests and stating which page of a result
>  set they would like returned along with a page count.
>
>  Note that for blackbox applications where you own both ends of the
>  spectrum, XML is quite the bloated middle-ware technology - though it
>  does provide insulation from bad technology decisions (i.e. today your
>  front end is .NET, but when it is realized that was a bad decision then
>  they will try Java, and then PHP, and then RoR, etc).  Just think of how
>  many bytes of data would be required for 10k of records and then add on
>  top of that the CPU cost to serialize and parse it - ouch.
>
>  You are right to question them Dean,
>  Aaron Bartell
>  http://mowyourlawn.com
>
>  p.s. if you are looking for a commercial solution check out
>  www.rpg-xml.com (of which I am the lead developer)
>
>
>
>
>  Dean.Eshleman@xxxxxxxxxxxxxx wrote:
>  
>
>  Hi,
>
>  I have some questions about web services and how we are designing them.
>  
>
>  We
>  
>
>  are using web services to provide data from our system i to our .NET web
>  
>
>  
>
>  application. These web services are not intended to be used outside of
>  
>
>  our
>  
>
>  own application. One of our reasons for using web services was to avoid
>  storing a user id and password on the .NET side.
>
>  Our current approach has been to create the RPG program to return the
>  
>
>  data
>  
>
>  and then use the functionality in WDSC to create the web service front
>  
>
>  end
>  
>
>  for the RPG program. Overall, this approach works pretty well for most
>  situations.  The only thing we don't like about this approach is when we
>  
>
>  
>
>  are returning multiple records from the RPG. We set the size of the
>  
>
>  output
>  
>
>  multiple occurrence data structure to be large enough to handle what we
>  think is the highest number we will run into. In one case it needs to
>  handle close to 10,000 records. Personally, I think that is to large of
>  
>
>  a
>  
>
>  number to return at one time, but the web developers don't want to call
>  the web service multiple times, so I'm stuck with finding a solution.
>
>  The generated Java code from WDSC will return an XML document matching
>  
>
>  the
>  
>
>  number of occurrences output from the RPG. We would like it to only
>  
>
>  return
>  
>
>  the number of occurrences that actually contain data.
>
>  Since I don't know Java, my initial thought solve this problem was to
>  create an RPG program to replace the Java in this situation. The RPG
>  
>
>  would
>  
>
>  receive the input XML document, parse it and then call the RPG data
>  retrieval program. Next it would build the XML response document and
>  return that result. I thought I could do this using CGIDEV2 and Scott
>  Klement's port of the Expat parser (thanks Scott). This way, I can
>  
>
>  control
>  
>
>  the XML document that is output. Does this seem like a reasonable
>  solution?
>
>  I was able to test out the XML parsing and that seems to work okay.
>  
>
>  Right
>  
>
>  now, I'm trying to use CGIDEV2 to read the input XML and I'm not sure
>  
>
>  how
>  
>
>  to do that. All the examples I see involve reading input from a web
>  
>
>  page.
>  
>
>  Does anyone know what field would contain the XML after using the
>  zhbgetinput procedure?
>
>  One concern I have about the CGIDEV2 approach is how will I secure the
>  
>
>  web
>  
>
>  service? Only our application should be authorized to call it.
>
>  We are on V5R3 and won't be going to V5R4 until sometime next year and
>  this needs to be solved before then.
>
>  Dean Eshleman,
>  MMA, Inc.
>
>  ______________________________________________________________________
>  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 transmissions errors in the future. Thank
>  you.
>  
>
>  
>