Re: Solutions Assessment

Reeve,
  
  It has been an intense week for me at a customer site.  I would  have 
responded earlier.  It sounds like HTML, CSS, &  JavaScript essentially provide 
the palette you need to design new  interfaces and reach new customers.
  
  One problem with .Net is the tight coupling between base Web controls,  the 
development environment (Visual Studio), the generated software  components 
(.aspx files, etc.), and the generated user interface (HTML,  CSS, & 
JavaScript).  The tight integration is helpful for  first time users, and makes 
a great demo, but is overly constraining in  the long run, from my point of 
view.
  
  HTML, CSS, XML, DOM, and other elements of a UI may need to change over  
time.  XUL, the UI language supported equally under Windows,  Linux, and Mac 
platforms (via Firefox) may take off.  You may find  a need for XSL in an 
application, or a preference to define your own  HTML standards, but you?d be 
locked into the UI that?s generated by  Visual Studio?s Web controls.  
Microsoft?s stated direction is to  generate both thick and thin client 
interfaces from the same base  components, further binding developers to 
Microsoft?s palette, if you  will.
  
  A better approach, in my opinion, is to use whatever tool works best  for 
designing UI elements.  My preference is Macromedia  Dreamweaver.  Delimit HTML 
pages with ?record? and ?field?  markers.  Use a template tool to substitute 
field markers with  data at runtime, and write records dynamically, similar to 
the native  iSeries workstation interface.
  
  I think I get your point about WDSC.  I still use PDM and SEU, and  may 
switch to WDSC if they ever get it to the point that it doesn?t  feel clunky, 
in comparison to tools like Dreamweaver, or Visual  Studio.  WDSC seems to be 
going down the same path as Visual  Studio with tightly coupled IDE, UI 
components, and languages, but the  IDE itself feels weighted.  Moreover, if 
you?re deploying Java  applications using WDSC, your applications feel weighted!
  
  .Net, like J2EE is a distributed architecture.  If you go that  route then 
prepare for the headache of designing, deploying, and  distributing components 
across multiple physical layers.  .Net  looks great when the number of users 
and applications are small, but if  you?re planning on deploying broadly scoped 
product lines, like an ERP  system, prepare to deploy and manage application 
and database  components across multiple servers.
  
  My Web applications take less time performing database I/O and  generating 
HTML, than database drivers do when they perform database  I/O and generate 
ODBC / JDBC formatted data streams.  I?ll stick  with the iSeries native 
environment.  The interfaces are  streamlined.  I?ll stick with an environment 
where applications  reside on the same box as the database.
  
  Wintel servers tend to destabilize when running complex  workloads.  If that 
happens, you may not know whether the system  is infected with a virus, or 
whether the runtime environment is  inherently fragile, or whether certain 
software components overly tax  resources, but the answer will always be to 
plan and design for the  deployment of application components across server 
farms, reboot, scan  for viruses, update or reinstall Windows, etc.
  
  When you?re accustomed to having a database interface that shares  record 
buffers with low-level OS routines performing I/O, it?s  frustrating to limit 
your access to ODBC or JDBC interfaces, which are  constraining and poorly 
performing, in comparison.  Vendors end up  developing their own interfaces 
that look like record level access, but  never quite behave like record level 
access with ODBC or JDBC under the  covers.
  
  Microsoft seems to prize innovation over backward compatibility.   MS 
recently announced its intent to beef up its workforce in India from  4,000 to 
7,000.  How long before cultural differences begin  appearing in MS developer 
tools, paradigms, and architectures?   How many applications will break as 
Wintel transitions from 32 to 64  bit architecture?  Prepare to redesign and 
rewrite your  applications every few years, or so.  Prepare to pay through the  
nose, or prepare for limited choices, if MS extends its monopoly from  the 
desktop to the server.
  
  No matter how cool Microsoft or IBM tools become, vendors may need to  plan 
on developing some of their own interfaces, tools, and  standards.  I work for 
an iSeries ISV, and during our first three  (3) years of business, it may not 
be a stretch to say we?ve spent more  time developing models for UI and server 
components, and tools, and  frameworks, and shared procedures, than we?ve spent 
on end-user  applications.  One reason for that is because one side of the  
company is creating something under the iSeries native virtual machine,  while 
another side is creating something comparable under a Java  virtual machine.
  
  My only real complaint about the IBM, is that if Microsoft can package  
roughly 10,000 CPW into an xBox, using three (3) Power5 processors, for  under 
$500, then why does an iSeries model 520, limited to only 500  CPW, cost 
roughly $10,000?
  
  http://news.com.com/Xbox+specs+revealed/2100-1043_3-5705372.html
  
  
  Nathan Andelin
  
  

Reeve <rfritchman@xxxxxxxxx> wrote:  I'm a software developer *and vendor*.  
There's a small market out
there I can't touch with an iSeries solution.  I know how inexpensive
small boxes are and I even have an ASP available but green-screen, in
the mind of many, is associated with DOS-like unsophisticated
applications, the same way I look at a System/36 application.

But the green-screen environment, as stable as it is, doesn't provide
me with the palette I need for more sophisticated designs...and I have
context-sensitive help, strict UI standards, and click-to-sort column
headings on subfiles.  I do a lot with the 5250 data stream but I have
screen size, attribute, and color limitations limiting my ability to
develop better solutions.

The ability to interface to thousands of applications is far better
when working from a PC platform.  Yes, many applications have iSeries
interfaces but many of them are primitive (example: PC*MIler).

Visual Studio isn't perfect but it's light years ahead of WSDCi.  Hey,
IBM: throw out WDSCi and write a Visual Studio snap-it like ASNA.  San
Antonio is much nicer than Rochester or Toronto!

If you're in the iSeries software business with a green-screen
application, here are your choices: go with Java, Websphere, and the
IBM Services group or go with a Microsoft .NET environment.  Now ask
yourself which approach will provide more business and which approach
is focused on software.  The answer in both cases isn't IBM's
solution.

I'm being pulled to serious consideration of Microsoft by virtue of
the size of the customer base, many of whom won't consider iSeries. 
And IBM's pushing me (and other ISV's) away by failing to provide a
practical, integrated iSeries development environment.

That's why I'm doing the Solutions Assessment.  I really want to make
sure I'm not missing the iSeries boat.

There's been a lot of talk in the last few years about what we need on
the iSeries to get it competitive from a development standpoint. 
Let's see if IBM has listened and let's wait for the V5R4
announcement.  I suspect there will be nothing of value.

-reeve



                        
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.