Re: "EGL is the easiest langauge to learn" - Joe Pluta was-> Problem updating Rational Developer for System i for SOA Construction

Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:

Although I *don't* use DSM for displays (i have but anyway...ick) it's not that i don't understand your point. it's just that i don't agree with *all* of it. and yes i meant permanent log and i do that at the database level as well...however i'd prefer to know enough that i can interrogate the actual data being sent and *how* it looks during the transport phase. being able to see that i sent the data is one thing. being able to ensure that the format of the data (i.e. the XML) is correct, i'd like to be able to look at it and *know* i'm sending the data as it is expected to be on the other end. i know i don't *have* to write the code to support JSON, XML,etc. but being able to interpret the output visually is a *good* thing.

I'm not sure we agree on what my point is, though <grin>. I agree that you should be able to interrogate the data stream. Here's an example of XML-encoded JSON (it's our current hjybrid approach which allows either web services logic or RESTful JSON as we need it).

<p632:getUserResponse xmlns:p632="http://services";>
<userid>joepluta@xxxxxxxxx</userid>
<return>{"UserID" : "joepluta@xxxxxxxxx", "Name" : "Joe Pluta (Gmail)", "error" : false, "message" : ""}</return>
</p632:getUserResponse>


This is the getUser function. You send is a user ID (an email address) and it returns a JSON string with the information. I agree that you ought to be able to see this exchange and understand what it does. But I don't think you need to be an expert in either JSON or XML to read this response, right?

You do have to understand the concept of tagged languages to see the XML and serialized data (the name:value pairs) to understand JSON. But a lot of the appeal of these formats is that they are by their nature "human readable".

My point is that you shouldn't need to write the code to either format or parse this data! Let the generator do that for you. I have no problem with dumping this to a trace log (although that obviously need to be switch settable - you shouldn't have to trace production data streams unless there's a problem). Again, my point is that you shouldn't have to write the code that handles this; it should be part of the tool.

With EGL, it is.

By the way, since your last email I wrote the services for the next phase of the project - that includes the EGL and the RPG - deployed it and sent the specs to the other side. That's how productive this is.

Joe