(posted on peg, but is out of services, i guess, temporarily)
I'm about to embrace a route in the development of our system, that I think I should have experience in forehand.
I have some third party provider that are going to interact with us. this interaction primarily and, perhaps, exclusively, is "To post data in our database".
We need to get some summary data that third party is collecting in behalf of us. Their developer said they had other customers that use that same kind of data, and they have developed web services calls, and app server calls for posting the same data.
As I have just to develop the gateway for our system to collect, i'm thinking in the long run, about maintainability, performance and all that..
What is best?:
a) develop web services that get the data in datasets, and internally, they scatter the data in our database.
b) develop appserver apps. that do the same.
The speed at which we expect to be called, either method, is something 20 datasets by minute at first, and something like 200 a minute, at full capacity for some two hours a day,and rest of working hours drop significantly the throughput perhaps to 1/10th of that .
each dataset could be something like 6 to 10 records (total, head and detail) of regular size, nothing out of a small league...
What would be, in your experience, the most profitable solution for my employer, in terms of my work (salary), the maintainability, the machine to hold the interaction, and perhaps something I can't see yet.
Is Rest technology somewhere in my future? .
Hope to get some old sea wolf's advice.
Greetings!
Jorge Olguin
Forgot to mention... I'm on 11.4, with workgroup db in unix. Grow to enterprise database won't be problem.
In my opinion, I would chose writing ABL logic for handling(inserting into database and retrieving back) the data and expose the application logic as REST Services. I would chose to do this for two reasons based on your requirements
1. It is easier for third party to interact with OpenEdge through REST
2. As a third party would like interact with OpenEdge, I can tighten my security above the application logic which is at the REST Adapter
As far as Performance is concerned, I have worked on passing 100 records in a datasets over REST where each record has of around 100 columns and I could see that it would not take more than 1000-1500 milliseconds(based on my logic and machine) to insert and retrieve back the same data from the database.
Thanks for replying. Then we can consider that techonolgy is moving ahead to REST paradise? is it safe and sound to base a desicion on this promise? the third party is based on openedge also.
I give last fact is because when we started talking, they talk about app server calls, and web services calls they had already developed. In fact, i'll be programming the thing based in the procedure call they are already doing. We dind't talk about rest calls. So i guess they haven't faced that scenario before.. I don't know. I will call them in few hours (still very early at this hour here). They are open to develop some missing things, that would be created besides the current calls, as they are feeding customers already, if that would be the case, but mostly they had a solid base of calls right now. I haven't seeing the specs yet. I wanted to be informed ahead to the formal interviews.
Thanks for your feed back, sounds very promising....
TIA
Jorge Olguin
Hi Jorge,
For me, REST is good because it is easier to consume by any parties and light weight to consume. It all depends on your necessity and requirement
1. If your clients(third party) are only Openedge, then you writing Appserver logic should be sufficient/suffice.
2. If you foresee in future that there will be a need for you to expose your application logic as services so that they could
be consumed by much diverse clients, then I would suggest you to prefer REST.
You can keep this question open for more suggestions/feedback.
Yes, indeed.
I'm open to suggestions, but as you mention, I guess i'm aiming toward REST.
Hope to get more discussion on the subject!
Thanks.
Jorge Olguin