×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I've done both stored procedures and web services on the i that are used by applications that are in our DMZ with the i in our internal network. From the .Net side, calling a stored procedure on the i isn't any different than calling it from any other database; you just have to have the data provider installed.
There are, however, a couple of advantages to using web services over a stored procedure. The first one is that you can control the messages going back better than you can with a stored procedure. The second is that it is easier to do access control since you are providing a specific interface into the i. When you use a stored procedure, the consuming application has to have a real user profile and it is far too easy to give it access to everything instead of a single interface. This isn't impossible to resolve but you do need to think about it. The third advantage is that when someone else wants to use the service, you can point them to the WSDL URL and they can generate the code to call it without you having to get too involved.
As far as generating the service goes, I'm using Java (running in WebSphere but you can use Tomcat as well) to do it. I think the built in tooling uses PCML under the covers which does have limitations on the number of parameters you can pass in and out. I've also heard that there are limitations on how the request and response are formatted which may not suit your needs. The Java code itself is pretty simple. I start with a skeleton program (has pubic methods I want to expose and any data beans I need) and use the tooling in WDSC to generate the server stubs and WDSL file.
Matt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of GKern@xxxxxxxxxxxxxxxx
Sent: Wednesday, March 11, 2009 1:29 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Socket Server Application Approach
First thanks for all the responses, there's definitely a lot to consider.
As mentioned in my response to Charles I don't know enough about web
services and webserving from the i. My network admin is writing the
asp.net and he doesn't know anything about the i. We also want to keep all
the logic on the i too. His app will only send and receive data. Also we
don't run web apps directly on our i since it is inside our firewall and
this web app will be in the DMZ.
"I would say since you have an ASP.Net application, why don't you simply
write the data to a database via the iSeries Access Driver and be done
with it.
If this sits in a DMZ, you can tunnel just a couple ports for the
database access."
We need to perform some edits on the data to be sure it is complete and
then if all is good will have to interact with with an online payment
processor to initiate an attempt to pay by credit card. Writing to the
database will happen only after a valid transaction is completed and that
will be done on the i using procedures that are already in place.
I hadn't thought about an external stored procedure, and I'm not sure how
it would be called from asp.net if the procedure resides on the i - but
even so that's really much different than my server instance is it?
"I keep the socket-listening job running cxontinuously.
Use of the back button by the user on the client would interact with the
same instance, but we never tested for this."
The socket listener will be continuously running and will spawn a new
server instance each time a connection occurs.
Thanks again for the input!
Regards, Jerry
Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this message.
As an Amazon Associate we earn from qualifying purchases.
This thread ...
RE: Socket Server Application Approach, (continued)
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.