Re: Getting started with Net.data -was-I'dbetterdomorethan talk

Regarding the point about why I would advocate SOA layers between
applications on a single machine...

Just to be clear, I would NEVER try to dictate what internal developers
are using, as long as it's PHP :-P

What I was really fishing for was from a Vendor perspective. If you
have ever glued a TMS solution like LogPro into an ERP like say JD
Edwards, then you know how painful an experience that can be. That
coupled with the fact that as transportation requirements change yearly
you may want to stay current with the transportation solution, even if
you haven't taken an upgrade of your ERP in 10 years! An SOA method of
gluing provides a more resilient integration layer that could provide
faster upgrades and implementations. And, yes, I have no problem
talking to a WS on another platform. I love the IBMi, but have given up
on believing it will be the ONLY machine in the house :-)

Regards,

Mike


Also, check out the i5 content at ZendCon 2008 - Our annual PHP
ConferenceSeptember 15-18:
www.zendcon.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Aaron Bartell
Sent: Monday, August 18, 2008 9:39 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Getting started with Net.data
-was-I'dbetterdomorethan talk

Good points, this is a grey area and we both have points that don't make
it
black and white.

Last I checked, RoR was Open Source and no one was paying for that :-)

I don't think open source has anything to do with it, and instead we are
talking about what is selling hardware, or more specifically, what ISN'T
selling AS400 hardware. I am glad to see people using PHP as a reason
to
stay on the IBMi, but I am incredibly interested in hearing the sales
pitch
for getting people to run PHP IBMi in the face of a cheaper Lintel
solution
where they have no prior experience with the IBMi.

What makes the i5 unique among Wintel / Lintel server arena? Things

like
vertical scalability, rock solid performance, easier to manage, etc.

Agreed, and after reading that HarrisData article you linked to I was
bummed
out because they didn't really "sell" the AS400 on any of it's strong
points.

I think the XML like savior you anticipate will be Web Services.

It can't be because web services promotes "spread thyself so thin across
multitudes of OSes and languages that it takes double the time to get a
collaborative project done". FYI - I eat/sleep/breath web services for a
living. They are GREAT for communicating with third parties. They are
not
so great for where you have control over both ends including the OS,
language, and data transfer to use. As this opinion goes against
popular
opinion I don't expect others to jump on my bandwagon without first
going
through the various puddles.

Remember that SOA is a crutch to hold us up on the bad leg named
"we-let-any-server/language/OS-in-the-door-that-wanted-in-over-the-past-
15-years".
As much as we would like to call SOA the next wave of a good thing, the
reality of it is that the bleed edge companies are already moving past
it
and are instead gaining effciencies by simplifying their software stack
and
eliminating (not adding) new languages and OSes. Does that cost a lot
of
money? You bet. But the cost will be less than what many (not all)
companies
will have in 10 years with an SOA mess.

Applications even if they are running on the same box will communicate

via
web services.

Very interesting; WHY would you introduce so much complexity for a
simple
program call simply for the sake of generic interface? This is flat out
Kool-Aid drinking (btw, I have partaken of this Kool-Aid when I first
started with XML 8 years ago - it is so sweet on the tongue but so
bitter in
the stomach). Now on the flip side I FULLY promote modular programming
for
re-use for a variety of purposes (i.e. develop an RPG *SRVPGM so it can
be
called from SQL, from an XML web service, from JT400, from PHP, etc).
But
that is a lot different that using web services to make calls from one
module to another on the *same* machine. Maybe you can expound on this
to
correct any generalizations I am making.

And being successful! (Stay tuned for a case study on this one!)

I have also seen the success. But for most it has only been able to be
measured in very short time frames. The proof will be in 10 years, and
I
think we are in for a big surprise.

Then again, I might be smoking the drapes :-)

Who knows, maybe I am too :-)

Aaron Bartell
http://mowyourlawn.com

On Mon, Aug 18, 2008 at 9:07 AM, Mike Pavlak <Mike.Pavlak@xxxxxxxx>
wrote:

***OPINION PIECE*** I'm sure this has been discussed before, but...

I like to disagree on occasion, and certainly cannot paint with a

broad

brush on this. So I will concede that SOME folks out there will buy
hardware based upon tooling...today. But look at the facts. What has
sold .Net (IMHO) is the proliferation of Windows servers. Call me
naive, but I can't believe anyone would start down the road of .Net if
they knew nothing about Windows and had no investment in the

technology.

Linux and the open source arena would make so much more sense from a
ground zero perspective. And why are there windows servers? Because
there are many windows solutions. Starting in the beginning with the
dreaded NT file sharing and heading on down to SQL Server, Exchange,
MoM, WSUS, DNS, Active Directory, etc. Once a customer heads down

that

slippery slope of resolving business needs with Windows solutions,

then

M$ solutions become the path of least resistance. It becomes "easier"
to develop M$ solutions when you have 20 servers lying around at 5%
utilization. Rationalities like "Hey, we have to support Windows
anyway" and "Windows is the defacto standard" etc. play very hard into
this line of thinking. I'm not saying the folks at M$ had all this in
mind when they embarked upon the server adventure some 15 years ago as
they were wringing the bugs from NT (or should I say VMS part 2). The
M$ folks do a great job of convincing folks that they have an ALL
ENCOMPASSING solution and that solutions like .Net will allow you to
"capitalize on your Windows investment". Doesn't have to be true.
Heck, it doesn't even have to work! As long as they believe it! The
last two shops I worked in got on the .Net bandwagon because they

bought

solutions written in .Net. Call me old fashioned...

Last I checked, RoR was Open Source and no one was paying for that :-)

My point is, I see people are selecting the hardware based upon
solutions today. If you want to run RoR, or better yet, an

application

developed in RoR, what hardware solution do you need? A simple Wintel

/

Lintel server will do you. Can you perform session clustering with

RoR?

Maybe, maybe not. I know we were measuring the uptime of Twitter in
minutes but that may have gotten better. What makes the i5 unique

among

Wintel / Lintel server arena? Things like vertical scalability, rock
solid performance, easier to manage, etc. But, if the solutions
available are not attractive, folks will vote with their feet! IBM

has

recently refocused on this advantage. They have approached the ISV's
with renewed vigor. Hope it's not too late and that the approach is

not

half hearted. We'll see.

I think the XML like savior you anticipate will be Web Services. I
envisioned some years ago, with the help of one of my developers, the
days of the "bound call" will go out the window. In 2005 I was
demanding that our i5 application vendors wrap their code with an SOA
layer so I we could have a more resilient coupling. Applications even
if they are running on the same box will communicate via web services.
Check out the book "Small Pieces Loosely Joined" by David Weinberger.
EDI has been doing this for years and WS is just another way of doing
the same old thing. But the abstraction insulates us from platform or
hardware dependence. David wrote this book in the post-apocalyptic
Internet era of 2001-2002 and I think he got it right. Once you have

an

SOA layer around your apps, who cares what it is written in? And I

have

seen customers doing it. And being successful! (Stay tuned for a

case

study on this one!)

Discipline and development have and always will be the challenge.

Many

development managers were developers. If the tools they used as
developers was .Net, then gues were the direction may be headed. I'm
not saying that a development manager from the development ranks is
inflexible. But familiarity doesn't always breed contempt!

Then again, I might be smoking the drapes :-)

Regards,

Mike