Ooo... I love these types of questions! :-)
If you were to go the gateway route how would the internal programs talk to
the gateway? Another layer of web services (maybe simplified)? SQL
procedures?
Couple things to consider:
1) Failure points. If you create a gateway then you have a single point of
failure to the outside world, but the internal LAN world maybe just became
more complicated depending on how the internals talk to the gateway vs. just
going direct. For example, if you have .NET programs talking to an RPG web
service that acts as the gateway then you have introduced the failure point
of Apache (i.e. in stead of one remote http server you now have two, a local
AND remote one that both need to be up and running for the processes to work
successfully). I have found the Apache server on the iSeries to be very
reliable, but that doesn't mean a botched nightly job wont forget to start
it up after shutting it off to release file locks. So again, think about
failure points and what is an acceptable medium to have.
2) Logging. If it is something like a credit processing application then
you are going to want to know who called what and when, simply because money
is involved, and for obvious debugging reasons. This is where an ESB starts
looking appealing (i.e. your gateway).
3) Real-time performance. Is this needing to be fast? (i.e. is a user
waiting for the response). If so the gateway or ESB is starting to look
less appealing because it could add anywhere to 1 second to 5 seconds of
additional processing time under "normal processing conditions". If the end
web service is also slow you could be looking at 10 second response times -
completely unacceptable in many cases where a customer is on the phone.
4) Maintenance. If you are connecting directly to the web service from all
internal environments then you are most likely needing to re-implement on
each platform (assuming multiple platforms), and after implementing there
will most likely be changes in a year or two. Those changes will need to be
reflected across all internal platform implementations. Having a gateway
will potentially protect from this as the remote web service will only be
implemented once and then your own internal communication methods will be
used to communicate with the gateway.
I am sure there are more points to consider that I am forgetting. I will
post more if my memory returns to me :-)
HTH,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces+albartell=gmail.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+albartell=gmail.com@xxxxxxxxxxxx] On Behalf Of
Wilt, Charles
Sent: Tuesday, October 23, 2007 9:17 AM
To: RPG programming on the AS400 / iSeries
Subject: Calling web services - Application Architecture question
All,
Lets say you need to call an external web service from multiple applications
on multiple systems.
Does it make sense to create your own internal web service to act as
basically a gateway to that
external web service?
Why or why not?
Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx <mailto:wiltc@xxxxxxxxxx>
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not a
named addressee you are hereby notified that you are not authorized to read,
print, retain, copy or disseminate this communication without the consent of
the sender and that doing so is prohibited and may be unlawful. Please
reply to the message immediately by informing the sender that the message
was misdirected. After replying, please delete and otherwise erase it and
any attachments from your computer system. Your assistance in correcting
this error is appreciated.
midrange.com
