Greetings. Joys of having a solution that has been around awhile and had
gone through many evolutions over the years. Seems that some forget that
we at IBM do listen to those that use our products, and we do make updates
and improvements. Is IWS a perfect solution... of course not. But it is
very widely used and continues to be leveraged for both small low
transaction activities as well as very high volume activities (millions of
transactions a day).
There are 2 sides to IWS and no they are not equal.
IWS Server - this is the ability to expose IBM i ILE and now SQL
statements as a REST Api. This support is wizard based, and allows the
user to specify an ILE program or service program or now an SQL statement
and the wizard builds the Java application that is deployed to the IWS
server. This support has changed a great deal over the years. We have
changed to use liberty and JAX-RS today from previous technologies. As we
have leveraged better technologies, the performance as one might expect
has also greatly improved. Re-deployment, that has been added quite some
time ago now and as noted, just works. When the world only revolved
around SOAP, things were much simpler. Thankfully the work has continued
to also evolve, and REST does require a bit more to be exposed to the user
which of course does add complication. Its a fun balance to try and keep
things simple, yet ensure that those that have complex requirements can
take advantage of all that REST has to offer.
If user wish to do all the work to create the REST Apis them self, that is
great. IWS has been created to help simplify this process, provide a
solid solution that is fully supported by IBM (ie... you can call someone
and you get help) easily maintained though normal PTF updates and is
completely scriptable, while yes we have a GUI, it is also able to be
programmatically configure and deployed.
IWS Client, this is the ability to call SOAP or REST Apis from the PRG or
COBOL program. This support does work. It does work very well, its also
NOT easy to configure. We have a very detailed document that helps, but
this is still an area that we understand could continue to improve.
Additionally, we have the HTTPFunctions support that is super simple to
use from SQL and when properly configured does perform very well.
Of course there are also many other options in the industry both free as
well as for pay that also cover this space. But, again, if you have
support, you have the ability to call IBM and get support. IBM also
ensures that these technologies remain current and any security
vulnerabilities that are discovered in the underlying technology stacks
are updated.
Tim Rowe, timmr@xxxxxxxxxx
Business Architect Application Development & Systems Management for IBM i
IBM i ISV Council
IBM i Development Lab, Rochester, MN
(507) 253-6191 (Tie) 553-6191
http://www-03.ibm.com/systems/power/software/i/are/index.html
http://ibm.biz/IBMi_ACS
----- Original message -----
From: Marco Facchinetti <marco.facchinetti@xxxxxxxxx>
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>
To: "Web Enabling the IBM i (AS/400 and iSeries)"
<web400@xxxxxxxxxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [WEB400] SOAP vs. REST
Date: Thu, Jul 11, 2019 2:43 AM
Jon thanks for your comment.
My point of view about Web Services is that there are two completely
separated worlds: Serve and Consume. IWS fits perfectly in the Serve
side.
Therefore, talking of the "Serve" world based on IBM i and using RPGLE
as
the main language of development, my desire today is to replicate the
pleasant experience of my first 15 years of programming using green
screens
without ever having been a specialist of the TN5250 protocol. So, at
least
for me, IWS is exactly what I need.
Best regards
--
Marco Facchinetti
Mr S.r.l.
Tel. 035 962885
Cel. 393 9620498
Skype: facchinettimarco
Il giorno mer 10 lug 2019 alle ore 22:30 Jon Paris
<jon.paris@xxxxxxxxxxxxxx>
ha scritto:
> Why not IWS? The following is my personal opinion and one that I have
> shared with IBM on many occasions.
>
> 1) The inner workings are "hidden" behind a Java App Server. It is
> wonderful when it is working and a nightmare to debug (unless they've
made
> major changes recently that I am not aware of) when it isn't. For a
long
> time redeploying a service was a pain - I believe they are supposed to
have
> fixed that now but I haven't played with the current version.
>
> 2) When things change in the REST world and you need some new
> authentication method or whatever you are stuck until IBM updates the
> wizard and off course you have to be on a release that the update is
> supported on.
>
> 3) One of my biggest peeves - the documentation is in "unixese" and
while
> some of the guides are more helpful I have encountered problems with
them
> not being updated to match the software. Not a problem if the docs
were in
> English but ...
>
> 4) When I ran some performance tests a while back a regular simple
> RPG/Apache/JSON combination handled between 3 and 10 X the number of
> transactions in a given time frame.
>
> 5) There are a lot more people on the lists who can offer advice on
how to
> make RPG drive a REST web service than there are who are familiar with
IWS.
> When it comes to node/Python/PHP that number climbs from "lots" to
> "masses".
>
> As I noted in my original response i have used IWS for a proof of
concept,
> and one client continued to use it in production because the
transaction
> volume was relatively low and the simplicity worked for them in those
> circumstances.
>
>
> Jon Paris
>
> www.partner400.com
> www.SystemiDeveloper.com
>
> > On Jul 10, 2019, at 2:11 PM, Marco Facchinetti <
> marco.facchinetti@xxxxxxxxx> wrote:
> >
> > May I ask why not IWS?
> >
> > TIA
> > --
> > Marco Facchinetti
> >
> > Mr S.r.l.
> >
> > Tel. 035 962885
> > Cel. 393 9620498
> >
> > Skype: facchinettimarco
> >
> >
> > Il giorno mer 10 lug 2019 alle ore 19:09 Jon Paris <
> jon.paris@xxxxxxxxxxxxxx>
> > ha scritto:
> >
> >> REST for sure. And personally I would not use IWS for a multitude
of
> >> reasons. I love it for proof of concept stuff but I'd rather "roll
my
> own"
> >> using PHP, node, Python or RPG.
> >>
> >>
> >> Jon Paris
> >>
> >> www.partner400.com
> >> www.SystemiDeveloper.com
> >>
> >>> On Jul 10, 2019, at 12:21 PM, Jim Oberholtzer <
> >> midrangel@xxxxxxxxxxxxxxxxx> wrote:
> >>>
> >>> Folks:
> >>>
> >>>
> >>>
> >>> I'm about to do an incredibly scary thing, start to develop my own
> >> software
> >>> that includes the use of IWS. To suggest I'm starting from the
> >> beginning is
> >>> at best charitable. I can architect the software, that's easy.
> Actually
> >>> doing the development, my RPG credentials were revoked a long time
ago,
> >> so
> >>> there's that learning curve. Then there are some decisions to be
made
> in
> >> the
> >>> architecture. To that end:
> >>>
> >>>
> >>>
> >>> So as part of the software planning process the question comes up
SOAP
> >> vs.
> >>> REST. I'll assume based on the threads I've seen lately that most
> folks
> >>> would prefer to use JSON, therefore REST as opposed to SOAP which
would
> >> use
> >>> XML.
> >>>
> >>>
> >>>
> >>> This will be entirely IBM i based software with both traditional
> >>> languages/objects and some open source components as well. DB2
will be
> >> the
> >>> database of record.
> >>>
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Jim Oberholtzer
> >>>
> >>> Agile Technology Architects
> >>>
> >>>
> >>>
> >>> --
> >>> This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
> mailing
> >> list
> >>> To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
> >>> To subscribe, unsubscribe, or change list options,
> >>> visit: [1]
https://lists.midrange.com/mailman/listinfo/web400 ;
> >>> or email: WEB400-request@xxxxxxxxxxxxxxxxxx
> >>> Before posting, please take a moment to review the archives
> >>> at [2]
https://archive.midrange.com/web400 ;.
> >>>
> >>
> >> --
> >> This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
> >> list
> >> To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
> >> To subscribe, unsubscribe, or change list options,
> >> visit: [3]
https://lists.midrange.com/mailman/listinfo/web400 ;
> >> or email: WEB400-request@xxxxxxxxxxxxxxxxxx
> >> Before posting, please take a moment to review the archives
> >> at [4]
https://archive.midrange.com/web400 ;.
> >>
> >>
> > --
> > This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
> list
> > To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: [5]
https://lists.midrange.com/mailman/listinfo/web400 ;
> > or email: WEB400-request@xxxxxxxxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at [6]
https://archive.midrange.com/web400 ;.
> >
>
> --
> This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
> list
> To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: [7]
https://lists.midrange.com/mailman/listinfo/web400 ;
> or email: WEB400-request@xxxxxxxxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at [8]
https://archive.midrange.com/web400 ;.
>
>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [9]
https://lists.midrange.com/mailman/listinfo/web400 ;
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [10]
https://archive.midrange.com/web400 ;.
References
Visible links
1.
https://lists.midrange.com/mailman/listinfo/web400
2.
https://archive.midrange.com/web400
3.
https://lists.midrange.com/mailman/listinfo/web400
4.
https://archive.midrange.com/web400
5.
https://lists.midrange.com/mailman/listinfo/web400
6.
https://archive.midrange.com/web400
7.
https://lists.midrange.com/mailman/listinfo/web400
8.
https://archive.midrange.com/web400
9.
https://lists.midrange.com/mailman/listinfo/web400
10.
https://archive.midrange.com/web400
midrange.com
