ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Late to the Party with IWS - do I come at all?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Late to the Party with IWS - do I come at all?

    I am new to the IBM I series (very experienced on the Z series) though the company I just joined has used it for years. Since we were so focused on the I, we did little for integrations to other platforms. I am interested in implementing IWS to allow us to leverage a lot of our domain code as soap services or rest APIs (had a lot of success with similar functions on the z series).

    I engaged a vendor with experience on the platform to help us implement our first IWS. They are discouraging us from implementing IWS and are steering us to stored procedures. They site issues with the IWS services.

    My question for you experts is since I have no IWS services, should I start now or am I in-fact better off using stored procedures. I know everything is situational, but just give me your feedback on if you've used it and if you would again.

    Thanks!

  • #2
    Depending on your needs, RPG-XML Suite (RXS) might be a viable alternative. It offers a free trial through a proof of concept, and has capabilities to offer and consume both SOAP and REST web services. It can also compose and parse both JSON & XML. IWS is admittedly kind of buggy, so hopefully this helps.

    Comment


    • #3
      IWS has improved a lot over the years and is certainly a viable option. Stored procedures seem to be falling out of fashion and I don't see many people implementing them these days as a vehicle for remote access by "outsiders". For me the biggest potential downside to IWS is how difficult it can be to debug. If your organization has Java/Websphere skills this is not a problem but I have met clients who made a great start with IWS and proved the value of offering RPG etc. code visibility as web services, but who didn't have the Java skills to debug and tune the system as the volumes increased.

      There are several third party tool sets being offered these days at very reasonable prices. Profound Logic have one as do Eradani. Both of those vendors did sessions in System i Developer's Lunch and Learn series recently and the recordings are still available. http://www.systemideveloper.com/page...ts/LunchLearn/

      Comment


      • #4
        Originally posted by dseyfried
        I engaged a vendor with experience on the platform to help us implement our first IWS. They are discouraging us from implementing IWS and are steering us to stored procedures. They site issues with the IWS services.
        Originally posted by JonBoy View Post
        Stored procedures seem to be falling out of fashion and I don't see many people implementing them these days as a vehicle for remote access by "outsiders".
        The advantage of remote stored procedure (or udtf) calls is that its very simple to code. It takes very little time, just a simple wrapper around a program call and BANGO, you've got integration. The disadvantage is that it requires you to set up a database connection between these applications. Often this isn't possible because there isn't a database driver available for every platform. Furthermore, its a HUGE security risk to give someone else access to your database, so you must be careful to only use this technique in a trusted scenario. I.e. between two applications on the same machine, or LPARs within a machine, or computers on the same network or VPN, which are protected by a firewall so that outside people cannot access the database. Works fine and is simple, so makes a lot of sense.

        On the other hand, if you want to allow people in different organizations to call something, or make calls from a public site (such as public web page) or a mobile app, it makes no sense at all to use stored procedures. That would be a huge security risk. You can't trust people being able to make database queries from anywhere on the Internet, or especially from anywhere there might be wireless access... this would be crazy from a security perspective. So a tool like a REST API that severely limits the exposure makes a lot more sense.

        In today's world where it's quite common for employees to work from home, and mobile apps are common, and companies are increasingly hosting parts of their applications in the cloud, it makes absolutely no sense to use stored procedures. Especially since tools likw IWS or the commercial offerings that Jon listed make it very nearly as easy to set up a REST API as it would be to use a stored procedure.

        Comment

        Working...
        X