I have never done anything with OpenClient ... not surprising considering how I avoid UI ... but there was a recent exchange in another thread which pointed out that sending a TT as a parameter from AppServer resulted in a native data type at the other end for a foreign technology.
I am wondering conceptually how this is actually done. Does the development environment provide a class for the destination technology that knows how to read the wire protocol for a TT and spit out a dataset or whatever? Or, is it sent differently? I.e., where does the conversion actually take place?
There is a proxygen tool that will generate classes or DLLs that Java or .NET can use to call the appropriate procedure/internal procedure and handle all of the data type mapping.
There is also an OpenAPI for .NET and Java that lets you construct the calls much like you would for stored procedure calls for other databases.
The 11.5 documentation is very detailed and all of the approaches are easy to use and perform well in most cases. Older versions had a few quirks but recent versions are pretty solid. Current company makes close to 500K proxy calls a day and has every day for the last few years.
The conversion all takes place on the client side but some of the information on how to do that comes from the r-code itself in the case of proxygen.
I have never done anything with OpenClient ... not surprising considering how I avoid UI ... but there was a recent exchange in another thread which pointed out that sending a TT as a parameter from AppServer resulted in a native data type at the other end for a foreign technology.
I am wondering conceptually how this is actually done. Does the development environment provide a class for the destination technology that knows how to read the wire protocol for a TT and spit out a dataset or whatever? Or, is it sent differently? I.e., where does the conversion actually take place?
Flag this post as spam/abuse.
I don't have need to actually use it. I was just having a "discussion" with someone about the relative merits of different approaches and wanted to confirm my expectation that there was a single transmission protocol with the conversion happening at the destination.
What happens then with a REST or browser client? Conversion to JSON at the server?
Yes. REST adapter converts the .p output to JSON. There are tools in PDSOE that allow you to configure how the temp table, or really any output parameter, is mapped to the JSON.
Thanks. As I expected.
How about for mobile?
How about for mobile?
Flag this post as spam/abuse.
As I expected, thanks.
Mobile, browser, and any other HTTP client would use REST to access to the AppServer via the REST adapter and its JSON conversion.
Normally for mobile you would be using the JSDO or something to deal with taking care of the HTTP calls (get/put/post/delete) and parameter mapping.
Mobile is no different. The backend for "mobile" is the REST adapter. Typically on the mobile client (phone or tablet or really anything at all), you're making an HTTP call, and getting back a blob of JSON.
This might sound like blasphemy, and its a personal opinion...one could say using pure appserver protocol is completely legacy and there is no reason to use it anymore. I pretty much don't see any reason that any sort of client, and that includes ABL, java, .net to use proprietary appserver protocol anymore.
Between JSON as a message encoding, REST as a set of protocol best practices/standards, and HTTPS as transport layer you can write any client: but it "mobile", "desktop", "web", or "batch" or simply a perl script, and have it all talk to the same backend without worrying about proprietary stuff.
Look at the NoSQL databases out there, All the ones I'm familiar with all support HTTP+JSON as their primary protocol. PAS for new stuff, and REST adapter for legacy make this possible in the OpenEdge world.
Mobile absolutely requires that you use HTTP+JSON. Just consider everything "mobile" and you're halfway there.
This might sound like blasphemy, and its a personal opinion...one could say using pure appserver protocol is completely legacy and there is no reason to use it anymore. I pretty much don't see any reason that any sort of client, and that includes ABL, java, .net to use proprietary appserver protocol anymore.
Between JSON as a message encoding, REST as a set of protocol best practices/standards, and HTTPS as transport layer you can write any client: but it "mobile", "desktop", "web", or "batch" or simply a perl script, and have it all talk to the same backend without worrying about proprietary stuff.
Look at the NoSQL databases out there, All the ones I'm familiar with all support HTTP+JSON as their primary protocol. PAS for new stuff, and REST adapter for legacy make this possible in the OpenEdge world.
Mobile absolutely requires that you use HTTP+JSON. Just consider everything "mobile" and you're halfway there.
Flag this post as spam/abuse.
Interestingly, Matt, the discussion I am having is with my OO mentor, who is from outside the OpenEdge realm .. *way* outside. His position was that all communications should be in as simple a form as possible to eliminate any coupling between the ends. I started out thinking that any communication crossing the AppServer boundary should be in a technology neutral form, but being made recently aware of the automated conversion to a technology appropriate datatype I was exploring the subject with him. He tends to think there is a lot of overhead in the existing protocol which would be eliminated if one went to packing and unpacking a buffer (i.e., the equivalent of a C struct). Well, I wouldn't want to pack and unpack such a thing in ABL without some language support for it, but I am also guessing that the current protocol is probably pretty dense as long as one uses the options to minimize the amount of TT information passed. Jeff certainly has a point that one couldn't just switch, but that doesn't mean that one couldn't make some new option available ... if that new option was better. But, I don't see JSON as an improvement since that I'm sure would increase the payload size. So, I have somewhat mixed feelings at this point. I can see and agree that there is a virtue in non-proprietary, but providing a mechanism for conversion to native at either end largely removes the disadvantages of proprietary unless one wanted to communicate with some totally new technology ... and what would that be. His notion of a packed buffer would be technology neutral and very compact, but would require some language additions if we were going to pack and unpack our own and would still want proxygen to keep people from having to code the other end themselves.
not the first time have heard appsrv applications labeled as 'legacy' by
PSC peoples... abl is still 4gl, that doesn't mean everything written in
it is legacy but as Gus replied when I was acting puzzled 'legacy' might
mean something proven to be working, out of alpha/beta :)
else, Thomas seems to imply binary and proprietary means more or less
the same things... I can understand the virtues of binary protocols but
those can be open so everyone can write 'adapters' that can adhere to
the protocol so the 'service' is open to anyone.
[collapse]On 08/05/15 18:28, Jeff Ledbetter wrote:
>[collapse] From: Jeff Ledbetter
> Post: RE: AppServer to non-ABL clients
> Posted in: Forum
> Link: http://community.progress.com/community_groups/openedge_development/f/19/p/17878/63382.aspx#63382
>
> Well, not blasphemy but not practical either.
>
> “I pretty much don't see any reason that any sort of client, and that includes ABL, java,
> .net to use proprietary appserver protocol anymore.”
>
> Although it is your personal opinion, you work for PSC, your opinion has weight so it is a bit irresponsible to say that.
>
> There are many applications which use traditional AppServer protocols. They are therefore deemed “legacy” and outdated because they have not adopted yet another
> technology offering from PSC? Why add the additional layers, adapters and what not, if they are unnecessary for a specific configuration?
>
> Jeff Ledbetter
> www.roundtable-software.com
> email:
> jeff.ledbetter@roundtable-software.com
> skype: jeff.ledbetter
>
>[collapse] From: Matt Baker [mailto:bounce-mbaker@community.progress.com]
>
> Sent: Friday, May 8, 2015 9:59 AM
> To: TU.OE.Development@community.progress.com
> Subject: RE: [Technical Users - OE Development] AppServer to non-ABL clients
>
>
>
> RE: AppServer to non-ABL clients
>
>
> Reply by Matt Baker
>
>
> This might sound like blasphemy, and its a personal opinion...one could say using pure appserver protocol is completely legacy and there is no reason to use it anymore. I pretty much don't see
> any reason that any sort of client, and that includes ABL, java, .net to use proprietary appserver protocol anymore.
> Between JSON as a message encoding, REST as a set of protocol best practices/standards, and HTTPS as transport layer you can write any client: but it "mobile", "desktop", "web", or "batch" or
> simply a perl script, and have it all talk to the same backend without worrying about proprietary stuff.
> Look at the NoSQL databases out there, All the ones I'm familiar with all support HTTP+JSON as their primary protocol. PAS for new stuff, and REST adapter for legacy make this possible in the
> OpenEdge world.
> Mobile absolutely requires that you use HTTP+JSON. Just consider everything "mobile" and you're halfway there.
>
>
> Stop receiving emails on this subject.
>
>
>
> Flag
> this post as spam/abuse.
>
>
> --
> You were sent this email because you opted to receive email notifications when someone created a new thread.
>
> To unsubscribe[collapse] from:
> - ...only this thread, disable notifications at http://community.progress.com/community_groups/openedge_development/f/19/p/17878/63382.aspx#63382.
> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>
>
--
m.edu
keep it simple
http://www.ganimede.ro
http://ro.linkedin.com/in/marianedu
medu@ganimede.ro
mobile: +40 740 036 212
skype: marian.edu[/collapse][/collapse][/collapse][/collapse]
Flag this post as spam/abuse.
I think that one of the key issues is the role of AppServer. If one sees AppServer as a tool primarily for talking to UI clients (closing our eyes for the moment on fat clients) then there are a certain set of requirements. In particular, the number of destination technologies that matter is fairly limited, so the combination of proprietary transmission protocol and native adapters is an effective solution and possibly preferable to an open, but bulky solution like JSON. If, however, one sees AppServer as a general purpose communication tool between subsystems which are distributed, then there is a much stronger argument for non-proprietary protocols and also a requirement for things like guaranteed delivery. Not to mention, of course, that AppServer is intrinsically pull technology and a more general purpose solution would include push, currently available only for mobile.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
Jeff, define "native".
Flag this post as spam/abuse.
Actually, I was pretty unsure of your meaning since my first impression was the opposite of what I thought you expressed earlier ... that's why I asked.