Re: SOAP vs. REST

On Jul 11, 2019, at 12:28 PM, Marco Facchinetti <marco.facchinetti@xxxxxxxxx> wrote:

https://www-01.ibm.com/support/docview.wss?uid=isg3T1026868

Resources > Documentation

HTH
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno gio 11 lug 2019 alle ore 17:58 Jon Paris <jon.paris@xxxxxxxxxxxxxx>
ha scritto:

Tim,

Re your comment "... it is also able to be programmatically configure and
deployed. "

Any documentation pointers? This is the first I've heard of this.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 11, 2019, at 8:40 AM, Tim Rowe <timmr@xxxxxxxxxx> wrote:

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
--
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: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at 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: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at 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: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.