RE: User Space extent

>better for whom?  It is easier for the programmer to work with complex and
large data structures when they are a single addressable object rather than
a collection of segments. 

Let me better explain where I am coming from.

It has been my experience that too much data/functionality is shoved into an
xml document when it should in fact be separated out.  For example let's say
an interface to a CRM package like salesforce.com was being built and you
wanted the data on your iSeries to be in sync with your salesforce.com data
(i.e. customer info, order history, etc). In this scenario you could choose
to create any number of xml documents to send/receive documents between the
two machines (say software packages) and here-in lies the initially
difficult part of authoring xml web services - how much data do I put in my
xml transaction? When a prospect turns into a customer through a cold call
you would want that information sent from the CRM app to your iSeries app,
but what does that xml document contain?

One could put every single piece of information about that prospect/customer
into a single xml document/transaction (name, addresses, contacts,
interests, etc), but it has been my experience that this creates problems
when validating information on the receiving end (i.e. address three has an
invalid zip code but the rest were ok).  A better way to do it would be to
model it similar to regular RPG program calls (emphasis on similar). To do
this you would create multiple xml documents/transactions (i.e.
createCustomer, addAddress, addContact, removeCustomer, removeAddress,
removeContact, etc) with each having a set of expected/documented responses
(i.e. SUCCESS, DUPLICATE FOUND, INVALID ZIP CODE, NOT FOUND, etc) and then
program around those specifications.

>more the reason to build the document as a string because appending to a
string is much faster than writing to a stream file.

I am not sure that I agree with having 16MB + strings being passed around.
How well is that going to scale in the end? What happens when you need to
start passing that XML around to different RPG sub procedures/programs? Are
you going to start passing pointers? Are you going to always make sure to
pass by reference so the xml is not doubled/tripled/etc?  There are just a
lot of bad things that can happen when that much memory is allocated to any
one particular job.  Sure every programmer loves to operate in memory
without having to worry about consuming too many resources, but I just don't
think that is a reality.

Also note that once you get into the web service world you will want a
"paper trail" of events that occurred (i.e. the raw xml as it was sent in
and what your service sent out) and you will not get that unless you move
the xml to more permanent storage (i.e. IFS files). Sure you may lose a
little bit of processing time because you aren't operating in memory, but
the benefits far outweigh in this case.

Great conversation!  Let's see if we can come to a "best practices" by the
end of this thread.  If you could state exactly what you are trying to do we
could come up with a great solution, but without that I am just fishin'
around for what you are trying to accomplish:-) (restated: could you give us
your business scenario?)

Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Steve Richter
Sent: Wednesday, December 28, 2005 8:39 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: User Space extent

On 12/28/05, albartell <albartell@xxxxxxxxx> wrote:
> How big of an XML document (or how much over 16MB) could you 
> realistically see being sent to your iSeries and what does that document
contain (i.e.
> PO's, database sync info, etc)?  The reason I ask is because there may 
> be a better approach to what is being done.

better for whom?  It is easier for the programmer to work with complex and
large data structures when they are a single addressable object rather than
a collection of segments.  Look at how some of the list APIs are extra
complex and not functional because all the objects in a library might not
fit in the user space being listed to.

>
> XML can be quite the pig when it comes to size, but a 16MB+ document, 
> well, that's A LOT of xml :-)
>

more the reason to build the document as a string because appending to a
string is much faster than writing to a stream file.

-Steve

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.