Board index » delphi » Like I said...

Like I said...


2005-12-02 06:59:25 AM
delphi231
Google this: "Economy of Scale Might Inspire Companies to Ditch IT
Departments"
This a huge opportunity for Borland to break from MSFT and secure a brighter
future. Powerful native backends that run on multiple operating systems,
with web or other thin-client delivery are the future of development. The
first company that can provide a development framework for this service
delivery is going to do very well. I think there will also be a huge
position to fill for the middleware providers, RO, kbm, Asta, etc., provided
they can deploy natively to multiple platforms. And yet another area that
will have a big role to play is the interface providers. Morfik has
potential here.
This is Internet 2.0, and it is going to be an exciting time for anyone
willing to participate in its development. As Delphi developers, we're
surrounded by all these tools that have the potential, or could have the
potential (as in the case of Borland) to make this happen. Exciting and
frustrating at the same time.
James
 
 

Re:Like I said...

Let me add that this is not anti-MSFT or anti-Borland.net rhetoric. I think
.net is great for web development, and since more and more of our computing
time will extend to devices, CF is going to be very strategic in the future.
James
 

Re:Like I said...

James K Smith writes:
Quote
Let me add that this is not anti-MSFT or anti-Borland.net rhetoric. I
think .net is great for web development, and since more and more of
our computing time will extend to devices, CF is going to be very
strategic in the future.
Thin clients and mobile/handheld computing has been 'the future' for the
better part of a decade now. it is a very boring future, which must be why my
boss got me a shiny new Dell Optiplex GX620 in my office yesterday...
--
Kristofer
 

Re:Like I said...

Quote
This a huge opportunity for Borland to break from MSFT and secure a brighter
future. Powerful native backends that run on multiple operating systems,
with web or other thin-client delivery are the future of development.
This "future" is here today, you can use Citrix now, or Terminal Services, clients run on pretty much everything, from PCs to
small slim cheapo net boxes, and if you use the "Application mode", it is transparent.
Many large-scale server installations work today, support load balancing across multiple servers and all kinds of niceties.
Quote
I think there will also be a huge position to fill for the middleware
providers, RO, kbm, Asta, etc.
I personnally am not convinced these layers have any long-term future, as they place too much burden on the developpers to
actively support and use them, while providing neither complete solutions like Citrix, nor streamlined monitoring, auditing or
standardized support and diagnostic tools for admins.
On the other side, write a standard UI application, pop it in Citrix Application Mode, and there you have your thin client,
that can be server-farm'ed easily with very little work and investment on the code.
Doing that with middleware libs will require quite a bit more work, and quite a bit of admins training.
Doing it with citrix only requires not to litter config data on random registry keys or ini files.
Sorry to pop your bubble :)
Eric
 

Re:Like I said...

Citrix is in no way a replacement for a good middleware library. The program
you are running still has to connect to a database or server in some way,
even when running in Citrix. For instance, with the traditional client/server
model in an app running under Citrix, there is no easy way to have centralized
logic (unless you do everything stored proc - yuck though) or to have bidi
communication where the server can easily communicate back to the client.
Even if you are running on a LAN these are nice features and are complimentary
to Citrix.
Personally, I don't like the Citrix alternative. For one thing, the burder
of running the OS session is on the server which is a waste of resources
if you aren't using thin-client dumb terminals. Also, most users don't like
having two desktops (or have a hard time getting used to it) and I would much
rather give the option of running my app natively on a laptop running thin
via SOAP, XMLRPC, or whatever back to the middleware server.
Don't get me wrong - we use terminal services for remote access and in some
locations while our app is undergoing a middleware transition, but I would
not be comfortable with it being the only option. Think about QualityCentral!
It is not plausible to share that app via a Citrix connection - perfect
example of a middleware/thin client solution.
Ryan
Quote
I personnally am not convinced these layers have any long-term future,
as they place too much burden on the developpers to actively support
and use them, while providing neither complete solutions like Citrix,
nor streamlined monitoring, auditing or standardized support and
diagnostic tools for admins.
 

Re:Like I said...

Quote
But this connection is between servers in the same room or even same
rack, ie. high-speed connection. No need to get dirty/risky/complex
with weird caching, encryption protocols, etc.
Exactly, but there are MANY things that you cannot do with a regular connection
to say, SQLServer. Some industries require encryption even on the LAN, some
want HTTP only, some want TCP only, some don't want but one port open. You
CAN NOT make really flexible feature rich apps running a unidirectional database
connection. You can not get live updates of data, notifications, centralized
complex logic, etc from a regular database connection these days - and even
if you do, then you are tied to a specific database for these features (which
is why I don't use stored procs at all).
Quote
You mean business logic in the middleware? That is often be quite
yucky too, as they typically end up with some stored procedures
anyway (for things the middleware is inefficient at) and other things
in the client-side (because, hey, you still have a rather fat
client with UI logic).
How is keeping it all in the client running over Citrix any un-yuckier (is
that a word? ;) than keeping it all in the middleware? I said yucky on stored
procedures because a) they are not in your native language (I know that SQL2005
has .NET, but that is new) and b) it is all SQL based and the things you
can do are very limited and c) they are a pain to update (not like copying
a new exe).
Quote
They are nice, but as everything runs server-side anyway,
you don't actually *need* them. At the cost of hardware and
the cost of the developper hour, many developpers prefer to
go the cheaper route... We use a middleware, but many of our
competitors don't, they just place their fat client in Citrix
and that is all... it may not be as sophisticated, but it works
and most customer don't really perceive the technical difference.
Can you access regular $50 USB scanners via TWAIN in an app shared like that?
I'm not trying to make a point, I am actually curious as this has been an
issue for us in the past with regular TS and Citrix...
Quote
Try that with regular PCs or when you have multiple "middleware-based"
applications, each using different middlewares (that may or may not
scale to multi-servers smoothly) and each using different thin-clients
that have to be installed and maintained on the PCs.
See last paragraph...
Quote
hmmm... SOAP and XML... talk about protocols and formats that are a
major waste of CPU and memory resources :)
The are options that are available is someone requires remote access from
a severely locked down network (port 80 out non-binary only). I'd not
dream of deploying on point-to-point offices or running over a LAN that way.
Quote
Terminal Services, the one that comes with Win2k3, doesn't support
application mode AFAIK, nor many niceties of Citrix.
Yeah, I don't think it does. That is a pretty cool feature.
Quote
The QC client? Dunno, it never worked here and UI looked quite
prehistoric at the time I tried (was years ago though, dunno if it has
evolved).
Actually, sorry, I meant the JED QC client. Check it out sometime. I like
it much better than the browser version. Yes, the old QC standalone was
pretty bad UI wise.
Quote
As soon as you need an application-specific client, you're in practice
leaving the realm of "thin-client" (or stretching the concept quite a
bit), simply because you have an EXE on the client machine that'll
have to be updated, patched, maintained, configured, virus-checked
etc... just like a fat client would.
Properly designed, the app is self maintaining by sending it is own updates
to the clients. Again, you can only do this with middleware - you can't
really transfer large files with a database-only connection.
But, I think you are missing my point (or maybe I just haven't explained
it properly). Even if you ARE using Citrix application mode on your app
in a completely enclosed LAN, you STILL have no flexiblity in your programming
design if you are accessing a database directly. There are SO many more
options that can be done using a centralize running app. Exchange uses middleware,
BizTalk uses middleware, StarTeam uses middleware, and basically anything
that has a server running that the client connects to.
I'm not saying that Citrix isn't cool, I am saying that it is not an applicable
replacement for the features and benefits of middleware that I feel are the
most important ones.
Ryan
 

Re:Like I said...

Quote
Citrix is in no way a replacement for a good middleware library. The
program you are running still has to connect to a database or server in
some way, even when running in Citrix.
But this connection is between servers in the same room or even same
rack, ie. high-speed connection. No need to get dirty/risky/complex
with weird caching, encryption protocols, etc.
Quote
For instance, with the traditional client/server model in an app
running under Citrix, there is no easy way to have centralized logic
(unless you do everything stored proc - yuck though)
You mean business logic in the middleware? That is often be quite
yucky too, as they typically end up with some stored procedures
anyway (for things the middleware is inefficient at) and other things
in the client-side (because, hey, you still have a rather fat
client with UI logic).
Quote
Even if you are running on a LAN these are nice features
and are complimentary to Citrix.
They are nice, but as everything runs server-side anyway,
you don't actually *need* them. At the cost of hardware and
the cost of the developper hour, many developpers prefer to
go the cheaper route... We use a middleware, but many of our
competitors don't, they just place their fat client in Citrix
and that is all... it may not be as sophisticated, but it works
and most customer don't really perceive the technical difference.
Quote
Personally, I don't like the Citrix alternative. For one thing, the
burder of running the OS session is on the server which is a waste of
resources if you aren't using thin-client dumb terminals.
The cost per session in actually quite low, and anyway, dumb terminals
are so cheap you can easily afford the extra RAM and server power. And
when you factor in the lower maintainance costs, it becomes an
unambiguous win. A single admin can manage hundreds of "clients" with
Citrix, supporting rich applications as well as intranet browsers, can
easily ensure patchings, backups, and other security requirements, can
replace a dead client machine in minutes, can handle the death of a
server almost transparently, etc.
Try that with regular PCs or when you have multiple "middleware-based"
applications, each using different middlewares (that may or may not
scale to multi-servers smoothly) and each using different thin-clients
that have to be installed and maintained on the PCs.
Quote
Also, most users don't like having two desktops (or have a hard time
getting used to it) and I would much rather give the option of running
my app natively on a laptop running thin via SOAP, XMLRPC, or
hmmm... SOAP and XML... talk about protocols and formats that are a
major waste of CPU and memory resources :)
Anyway two desktops isn't required:
- dumb clients don't have two desktops, get a dumb client ;)
- if you have PC, use application mode, a remotely-hosted app on
citrix will then behave like a "normal app", with individual
windows mixing with the rest of your local windows on your desktop
Quote
Don't get me wrong - we use terminal services for remote access and in
some locations while our app is undergoing a middleware transition, but
I would not be comfortable with it being the only option.
Terminal Services, the one that comes with Win2k3, doesn't support
application mode AFAIK, nor many niceties of Citrix.
Quote
Think about QualityCentral! It is not plausible to share that app
via a Citrix connection - perfect example of a middleware/thin client
solution.
The QC client? Dunno, it never worked here and UI looked quite
prehistoric at the time I tried (was years ago though, dunno if it has
evolved).
Always used the web interface, which is in that case a much better (and
convenient IMO) solution than a middleware (you can bookmark entries
f.i., and link them for others to see).
As soon as you need an application-specific client, you're in practice
leaving the realm of "thin-client" (or stretching the concept quite a
bit), simply because you have an EXE on the client machine that'll have
to be updated, patched, maintained, configured, virus-checked etc...
just like a fat client would.
Eric
 

Re:Like I said...

Eric Grange writes:
Quote
>For instance, with the traditional client/server model in an app
>running under Citrix, there is no easy way to have centralized logic
>(unless you do everything stored proc - yuck though)
Why?!? Our application is a three-tier DataSnap application. We have
many customers that use Terminal Services or Citrix. Note, this is not
to provide a "thin client", as our product does not use TS/Citrix for
it's multi-tier implementation.
The unfortunate fact is that DCOM is not tolerant of the noise and
disconnects of the Internet. And DataSnap, while a really cool
technology, doesn't scale well when a dozen users have a T1 between
them and the server components.
TS/Citrix solves both of these very nicely. Our centralized logic is
still in a middle-tier, running on another server, sitting in the same
room as the TS/Citrix box. So:
1) network connectivity between client/middle tier/database is
extremely fast.
2) the user experience is very fast, as screen deltas are the only
thing being transferred.
3) TS/Citrix are *much* more tolerant of Internet hick-ups than DCOM is.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Like I said...

Ryan McGinty writes:
Quote
You can't make really flexible feature
rich apps running a unidirectional database connection. You can't
get live updates of data, notifications, centralized complex logic,
etc from a regular database connection these days - and even if you
do, then you are tied to a specific database for these features
You seem to be saying that using TS/Citrix to solve some problems
prevents you from having a middle tier in your C/S solution. It
doesn't.
Quote
I said yucky on stored procedures because
b) it is all SQL based and the things you can do are very limited
Not as limited as you may think. Just not the way you're used to doing
them. You can do some /amazing/ things with SQL's SET based logic, and
/fast/ performance since it is right there in the DB engine. But SQL
coding past the basic uses SELECT/INSERT/UPDATE can get tricky.
Quote
c) they are a pain to update (not like copying a new exe).
Ok, I don't follow this. Running a script to update hundreds of stored
procedures on dozens of databases is *much* easier and typically faster
than copying a single EXE to a workstation.
Quote
Can you access regular $50 USB scanners via TWAIN in an app shared
like that? I am not trying to make a point, I am actually curious as
this has been an issue for us in the past with regular TS and
Citrix...
No, you cannot. One major disappointment of TS/Citrix is that it only
supports character device drivers, not block device drivers. And this
is a major limitation for our customers. For our customers using
TS/Citrix, we have to install one PC that accesses our middle-tier over
the WAN if the customer wants scanning capabilities.
Quote
Properly designed, the app is self maintaining by sending it is own
updates to the clients. Again, you can only do this with middleware
- you can not really transfer large files with a database-only
connection.
Again, what?!? Aside from the debate of BLOB storage in DBs (which I
won't go there), we have hundreds of various DLLs (most are report
plug-ins) stored in our database. Our product /does/ have a middle
tier. But we could transfer these binaries to our client even if we
didn't have a middle tier.
Quote
But, I think you are missing my point (or maybe I just haven't
explained it properly). Even if you ARE using Citrix application
mode on your app in a completely enclosed LAN, you STILL have no
flexiblity in your programming design if you are accessing a database
directly.
But you don't HAVE to access the database directly!
Quote
There are SO many more options that can be done using a
centralize running app. Exchange uses middleware, BizTalk uses
middleware, StarTeam uses middleware, and basically anything that has
a server running that the client connects to.
And even more options if you combine Citrix with your middle tier.
Quote
I'm not saying that Citrix isn't cool, I am saying that it is not an
applicable replacement for the features and benefits of middleware
that I feel are the most important ones.
Ok, that is a statement I will agree with. :)
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Like I said...

Eric Grange writes:
Quote
Image scanners are not supported directly, though this has never been
a practical limitations are they are rare, and usually have to be
tied to local applications for usefulness (such as OCR). The cases
where we encountered them had PC clients running the app via
Application Mode, so that was not a bother.
If the app in question uses scanning directly, than this is not
practical limitation. it is a major limitation for us and our
customers. :(
Quote
Our application had such a facility built-in from the start, but over
the years, it has become more and more impractical, as end-users
accounts have less and less rights.
I'm about to convert our workstation updater to a service just so it
can perform updates on workstations where users have no extra rights.
:(
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Like I said...

Quote
I said yucky on stored procedures because a) they are not in your native
language (I know that SQL2005 has .NET, but that is new)
That's not truly a bad thing, many notions are simpler to express and
understand in SQL and stored procedures than they are in whatever
language the client/middleware are written.
Of the clients/middlewares in my immediate surroundings I can find
Delphi (of course), C/C++, Java, C#, VB(Visual Basic) (old & .Net), Progress,
WinDev... each using a variety of "standard" libraries/beans/assemblies
with their idiosyncracies, terminologies, dialects and datatypes...
In the end, SQL and DB is the only place where everyone understands
everyone, in a clear, unambiguous way, right from the start.
Even when discussing data exchange over XML, everyone quickly falls back
to describing data and its constraints in SQL terms (not null, primary
key, foreign key, join etc.) because that is common ground, kinda like
the english language -- and probably also because no human seems to be
able to speak XSD fluently for long :p
Quote
b) it is all SQL based and the things you can do are very limited
Not a bad thing either. If you have to write complex data manipulation
code server-side that SQL can not handle, odds are you're doing it wrong
anyway :)
Quote
and c) they are a pain to update (not like copying a new exe).
Copying an exe is only a fraction of the update complexity, the real
complexity is in validation, deployment on hundreds of machines,
updating config/security files/rights, etc. rinse & repeat for all the
customers and their specific environments. Sometime self-updating EXEs
are possible, sometimes you have to setup and test deployment scripts,
have them validated on the various hardware setups, etc.
By comparison, DB (or Citrix) updates are performed on a "single
machine", in an environment that can protect you from fatal mistakes.
Quote
Can you access regular $50 USB scanners via TWAIN in an app shared like
that? I am not trying to make a point, I am actually curious as this has
been an issue for us in the past with regular TS and Citrix...
support.citrix.com/kb/entry.jspa
Image scanners are not supported directly, though this has never been a
practical limitations are they are rare, and usually have to be tied to
local applications for usefulness (such as OCR).
The cases where we encountered them had PC clients running the app via
Application Mode, so that was not a bother.
Quote
The are options that are available is someone requires remote access
from a severely locked down network (port 80 out non-binary only).
base64 encoding would go through that just fine too :)
Quote
Properly designed, the app is self maintaining by sending it is own
updates to the clients. Again, you can only do this with middleware -
you can not really transfer large files with a database-only connection.
Our application had such a facility built-in from the start, but over
the years, it has become more and more impractical, as end-users
accounts have less and less rights.
Nowadays, it is not rare when users don't have enough rights to
overwrite/delete/create a ".EXE" file (or .DLL or .BAT or...), so we've
learned to live without any auto-update facility... Usually the only
customers where auto-update is still allowed are the small ones -- where
there aren't enough clients to make autoupdates really useful :p --
those with large IT droids services have it forbidden, updates have to
go through some centralized update/validation layers.
Eric
 

Re:Like I said...

Ahh... We're a proud bunch. I should have started this thread with a topic
name that sounded less hubris-ridden. Not my intention.
Quote
This "future" is here today, you can use Citrix now, or Terminal Services,
clients run on pretty much everything, from PCs to
small slim cheapo net boxes, and if you use the "Application mode", it's
transparent.
Many large-scale server installations work today, support load balancing
across multiple servers and all kinds of niceties.
Citrix certainly could play a big role in the future. I don't dispute it.
Quote
I personnally am not convinced these layers have any long-term future, as
they place too much burden on the developpers to
actively support and use them, while providing neither complete solutions
like Citrix, nor streamlined monitoring, auditing or
standardized support and diagnostic tools for admins.
Well, no doubt some work could be done here, but your reply sounds
contrarian for its own sake. A Citrix solution is just one part of the
equation, especially if I want a simple client/server interaction with an
application. But what if your app presentation reveals too many features,
isn't 508 compliant, doesn't meet requisite trust objectives and the
evidence to back up the objectives, don't like your screens, blah, blah,
blah, do I call you up and ask you to make changes? What if I don't want an
interface at all, and just need service access, and btw I want to be charged
just for specific services that I use?
Middleware answers these questions nicely because the access I need can be
easily revealed, controlled, and extended. So you create a service provider
for your app. So now where does Citrix fit into this solution? Maybe it
does; I am not a Citrix expert.
By the way, I would also like to extend the functionality you have in your app,
then resell it. How would Citrix work here?
What I am getting at is that the hardware is now powerful enough without
being monopolized by any one manufacturer, the connectivity is good and
getting better, and when you take all this into account, the business case
is far more compelling than with old-style IT solutions. Additionally,
security solutions are moving from perimeter based to trust reciprocation
based, so now the internet will become even more of a business driver than
it has in the past. The end user can extend his or her operating environment
off of the desktop such that the distinction between running a app this way
on your desktop and running an app that way on the internet becomes blurred.
Citrix plays a role in this, no doubt. But Borland has an opportunity here
to apply tools like ECO to help us design large scale distributed apps that
allow for new ways to sell computing power and access to services, and ways
to help developers extend existing distributed apps. MSFT has developed its
own dead-end in this regard; why should Borland continue to follow?
James
 

Re:Like I said...

"James K Smith" <XXXX@XXXXX.COM>writes
Quote
MSFT has developed its
own dead-end in this regard; why should Borland continue to follow?

I followed you up to this point.
I assume you are refering to .NET, but I don't see how
it relates to the rest of your thesis.
--
Brad.
 

Re:Like I said...

I consider n-Tier and middleware the same thing. So, you are reinforcing
my point. He was saying that Citrix by itself eliminates the need for DataSnap
and other middleware (n-tier) technoloiges... I was saying that Citrix doesn't
change the application model and that middleware/n-tier is the way to go
regardless of how the app is deployed.
Ryan
Quote
Why?!? Our application is a three-tier DataSnap application. We have
many customers that use Terminal Services or Citrix. Note, this is
not to provide a "thin client", as our product does not use TS/Citrix
for it is multi-tier implementation.
 

Re:Like I said...

Quote
Ok, I don't follow this. Running a script to update hundreds of
stored procedures on dozens of databases is *much* easier and
typically faster than copying a single EXE to a workstation.
I support multiple databases so updating stored procs would not be fun since
each DB would be different. I guess it is probably no more difficult that
updating metadata though...
Quote
Again, what?!? Aside from the debate of BLOB storage in DBs (which I
won't go there), we have hundreds of various DLLs (most are report
plug-ins) stored in our database. Our product /does/ have a middle
tier. But we could transfer these binaries to our client even if we
didn't have a middle tier.
I complete agree - we were on the same page!
Quote
But you don't HAVE to access the database directly!
I understand that - again I think you are actually arguing the same point
I am. The fact that Citrix is not a REPLACEMENT for n-tier - it is complimentary
for all types of applications.
What James said was this:
"I think there will also be a huge position to fill for the middleware providers,
RO, kbm, Asta, etc., provided they can deploy natively to multiple platforms."
What Eric said was this:
"This "future" is here today, you can use Citrix now, or Terminal Services,
clients run on pretty much everything, from PCs to
small slim cheapo net boxes, and if you use the "Application mode", it's
transparent."
Eric was saying that (or at least this is how I read it) Citrix is a replacement
for all the middleware frameworks and I am saying that Citrix has nothing
to do with middleware and that the frameworks mentioned above ARE extremely
important because it provides a completely different design paradigm. I
read Eric's message as saying, "you don't need middleware frameworks any
more because you can just run your app in application mode." Maybe I completely
misread what he was trying to say, but if anyone reading this comes away
with any info it should be this: if you are developing a large scale app
and want the most flexibility: a) don't access a database directly b) have
a middle tier that you can centralize your logic in. If you want to deploy
it with Citrix, that is a fine way to go, but don't expect Citrix to bring
the features of n-tier to your C/S app.
Ryan