Board index » delphi » Re: Availability and reliability of Enterprise applications

2003-11-20 04:10:35 AM
delphi226
memory....GC has consequences other than more of something. IMO,
programmers need to be aware of what a GC will collect and reasonably
understand how and when they do.
 

availability/reliability measures than J2EE systems; one can argue that that
is comparing apples to oranges, but FMPOV it is interesting nonetheless.
The study is what it is. One can reasonably conclude that there is room for
improvement here...an opportunity for fun and profit. <g>J2EE isn't the
silver bullet. Not that I believe anything is a panacea. I do believe that
it's more "who" than "what", but as a whole I think we have a ways to go as
an industry.
 

"Byoob" <XXXX@XXXXX.COM>writes
5 minutes in 10 years. It was assembly language , very expensive to build
and maintain, and uptime was top priority. Only the US government could
afford it. Furthermore, all FAA operational systems require at least
(.999997) availably. They are also very expensive to build and maintain.
What I am saying is that availably is a system design consideration and is
very cost sensitive.
You only get what you pay for if your lucky.
James Crea
 

That could be another factor! How much do companies pay for software?
Enough to get by or enough for solid software?
"James Crea" <XXXX@XXXXX.COM>writes

Brian Moelk writes:
unnecessary.
I believe that those who are not using EJBs would not only experience much
higher uptimes (could be and may be up to 99%, if written correctly), but
also increased performance.
If you have to use EJBs, it is going to require a lot of tuning on and of
the App Servers, and you had better be using the newer standards (2.1 and
above) with a mix of local EJBs. If an orgranization can facilitate mixing
local and remote EJBs, they wil be much better off. If they can avoid EJBs
(especially CMP Entity Beans), they will be even better off.
The App Server providers (such as BEA, IBM, etc), want and desire more
dependence upon EJBs primarily for three reasons (1) High cost and great
revenue stream, (2) More license cost for more servers to handle increased
CPU and server load, and (3)Lock into vendors for repeat sales in upgrades,
new sales, etc.
EJBs have been vastly overhyped, IMHO. If used when needed and sparingly, it
can be successful. If used as a cure all for distributed application
support, it can be nightmarish in terms of performance.
performance to really suck, load an app with Remote Entity EJBs. I will
garantee you you will get a huge performance hit <G>.
shortcomings of J2EE (primarily bad application design by the development
team, not Javasoft, BTW.), it is still the best route to get there in
Enterprise and Web application development.
One of these days Delphites will learn XPlatform is VERY IMPORTANT in the
Enterprise and to serve Enterrpise customers. They are NOT GOING TO run
their mission critical systems on Windows, no matter how much you might
believe otherwise (does not apply to you, BTW, Brian). Oracle, IBM, SAP,
Peoplesoft, and CA ar the most predominent Enterprise players, and they use
and recommend Linux, AIX, Solaris, and Big Iron, not Windows. These major
players also highly committed to Java based solutions.
in Kylix for it to be taken seriously (now it is dicontinued), and more
importantly, not too many Enterprises are wild about placing their entire
IT infrastructure on a product that has only one vendor and only one means
of support. Add to this the problematic assertion that Deplhi has an
uncertain future (real or perceived).
Personally I feel Borland's real chance to make Delphi a real player in the
market, has come and gone about 5-6 years ago. I am not speaking Desktop
wise on Windows, mind you, but as an Enterprise wide solution.
It makes much more sense to bet on a platform that is not dependent upon a
single source, is widely supported by the industry, and has penetrated the
entire IT space.
 

Brian Moelk writes:
it is always wise to perform clean up type operations (making sure objects
are disposed in the finalize sections, setting object values to null, etc).
NET folks are going to notice these same types of leaks.
 

I worked on 427M at NORAD on the commutations backbone system and I just
checked the internet for its status at
www.fas.org/nuke/guide/usa/c3i/cmc.htm
Its hard to believe but the system I worked on during the mid 1970s may
still be in operation today. The m{*word*203}to this story: Good code never dies.
:o)
James Crea
 

"eWolverine" <XXXX@XXXXX.COM>writes news:<3fbbb5af$XXXX@XXXXX.COM>...
- Peter
 

speak. JSP/Servlets are an improvement over ASP and PHP, but ASP.NET raises
the bar quite a bit.
[...]
IMO has been greatly underdelivered. The best route really depends on many
factors. If I were developing a web app on *nix I would consider two options:
J2EE or PHP. On windows it is either .NET or a combination of Delphi
technologies. Requirements determine the best solution, not technology.
combinations of Windows and *nix.
is that these systems don't necessarily outperform (cost, speed, throughput,
etc) Windows based systems.
interested in knowing what percentage of their revenue come from Windows
based products or deployments. Not saying that it would be a majority, but
it would be interesting nonetheless.
The ironic thing is that many of those Enterprises only run Solaris or only
run BEA or IBM, etc. They *are* locked into a vendor, and they actually pay
more for the perceived freedom of vendor-independence than if they just used
Windows in the first place.
They are a niche player; but there is IMO a lot more they can do and can
continue to do.
The vendors that produce products for the platform? It really depends,
there are no clear cut answers. FMPOV, users don't care, they just want
something that works. In my experience and from what I gather this survey
shows about J2EE, I believe there is large room for improvement.
 

Brian Moelk writes:
more of a perception problem.
EJBs, themselves, do not lock you in (the code for BEA is the same as it is
for BES, Web Sphere, etc), but the deployment descriptors are different. It
is a perception thing, that we cannot change because of X. In reality, it
is relatively simple to do, if you use a non specific IDE, like JBuilder,
or Net Beans, for example.
are not running in the same JVM.
For example, if you have an application that originally host 1000 users, but
you need to add another server, how would you run the object pool across
several servers, which do not share the same JVM? Answer is either (1) RMI,
(2) Web Services, (3) Servlets.
The problem with # 3, is the typecating of those objects. You have to be
able to get a reference to the originating object, but unless you have the
same libs on both machines, using the same JVM (or a compatible version),
then you could have problems. EJBs rectifies this problem, by containing
the reference in a RMI/IIOP relationship (similar to Corba solution). By
calling the referenced EJB through RMI/IIOP relationship, you ensure that
the Context in which the object is instantiated, is the object you will
recieve back.
You can use RMI instead, but then your code base becomes much more complex
and reuse becomes a more rigid exercise.
That is the real reason for using EJBs, multi-server environments, where
scalability and reuse becomes the issue. I have no problem with this
approach, when it makes the most sense. However, care must be taken to make
sure that the remote calls and methods are minimized. One way to do this,
is to use SessionBeans and use either BMP Entity Beans, and/or/better,
local Entity beans.
In other words, if I use a Session Bean to call routines on the remote
server(s), then I could invoke the Entity Beans in the local context. That
means that the need to serialize and remote the object, becomes nil.
SessionBeans (which do not have to retain state and container persistence),
greatly reduces overhead. If you code carefully using SessionBeans, you can
greatly reduce overhead and speed up transaction times, yet retain the
remote benefits. I have not witnessed hwoever, many companies following
this pattern. To be fair to them however, EJB 2.0 is pretty new and many
probably have not upgraded their architecture nor app servers to take
advantage of these newer methodologies.
Web Services hold great potential, especially as it matures and if they do
not fragement into a MS only version verses the rest of the world.
involved, like wrapping legacy code and controlling Objects and/or
repositories that do not fit well in the Internet/Intranet browser based
type application. I have not seen anything to date, that works as well as
Java in the Enterprise overall. With 75% of Enterprises planning to stick
with Java, my opinion does not seem to be an isloated one<G>.
PHP is nice for smaller comapnies or Web Sites, but the MVC architecture is
not inherent in PHP. They are moving in that direction, but they are not
there yet. What you have with PHP is more of a intermingling with HTML and
Server side code. That makes reuse very hard to maintain and makes web site
upgrades, hard to obtain.
There are always certain situations and demands where Java may not be the
best fit. Of course my statement and intent refers to an overall solution
solving paradigm, not a one size fits all type situation.
Overall I think J2EE and EJBs become one and the same in the eyes of the IT
staff. Realistically they are not, though usually J2EE means EJBs, at least
in the corporate IT world.
other specialty OSes and devices. The problem realm has always been
seamless integration and interaction across all platforms and boundaries.
What solves this problem better than Java?
Oracle's latest benchmarks, as well as IBMs). Linux is a much lower cost
for Enterprises than Windows. The problem with the TCO Microsoft sponsered
reprots is that they believe that the user and network engineering firms
have no knowledge of Unix. As you alluded to earlier (a mixed envrionment),
we know that is not the case.
however that neither Oracle nor IBM, nor SAP recommend Windows servers for
their products. They do recommend gheavily these days, Linux or Big Iron. I
do not think most Enterprises are going to pay thousands to hundreds of
thosuands of dollars for the Enterprise wise solutions and then go against
the solution providers recommendations <G>.
ture (real or perceived).
however have more pressing things to worry about in the App Server space.
JBoss is now the most widely used App Server ( beating out IBM and BEA) and
it's cost is like the Linux cost, free (as in beer, not in speech). JBoss
now can be J2EE certified as well.
Sun offers a free version of Sun One and if you buy a Sparc or AMD/Intel
Server from Sun, you can get a free Sun One App Server, already setup and
to some degree, optimized for that server.
If you want to buy support, of course, it is available. But buying support
for Linux and JBoss combined, is much less than Windows licenses in a
large server environment.
agressive Java strategy, an xplatform C/C++ strategy, and a NET strategy.
This is what they should do; -- go with the market solutions and implement
those markets better than anyone else by coming up with winning IDEs and
architecture that makes any/all easier to use.
staffing, maintenance and upgrade issues. I certainly agree there is always
room for improvement. However, each major release of Java gets better, as
usually does each subsequent release from MS, Borland, Oracle, IBM, C, etc.
I would be willing to bet that most of these firms interviewed are relying
too heavily on EJBs and not structuring their Enterprise apps correctly. I
think they admitted to such.
Any of us who have done 'n tiered programming' know it takes much more
timing and planning than a traditonal two tiered approach or more than a
real 3 tiered approach (aka, Client on Workstations, server side processing
on a middle tier, and a Database tier on another server farm). That is true
whether we are working with MS based solutions, Java based ones, or some
other type of n tiered architecture, like Corba.
I do think that as grid computing becomes more popular, many of these
concerns and performance degrading options will become less and the
application tiers will become more manageable. Once a plethora of servers
really do work as one (and we can plug and play server farms as easily as
adding hardware to a PC), many of the n tiered problems become much less in
complexity and state/persistent management.
Have a great evening Brian. Always a pleasure.
 

Eric
 

you can end up eating hundreds of MB and enter swapping hell?
Eric
 

than it does the way the code is executed within different App Servers.
works when you switch from BEA to IBM or JBoss....it is expensive and most
devs (myself included) recommend switching app servers if you can afford to
stay with one. There are additional costs like retraining your sys admins
so they can configure different app servers, etc. it is a much bigger/larger
deal than the Java community would like everyone to believe because it is how
they sell App servers.
[...]
I appreciate the response and I agree...but you can quickly see how the J2EE
solution becomes inordinately complex for something that webservices solves
quite elegantly.
like Web Services stuff. I don't see how MS can fragment the standards too
badly here. Java supports SOAP, the problem is there is so many different
implementations and the J2EE spec was late IMO.
based standards like JCA, but at the same time I think you will see SOAP stuff
being widely adopted to do the same things ITO enterprise integration.
can separate HTML from code to a large degree.
J2EE guys will almost always recommend J2EE, even if the application could
use LAMP. IOW, I am skeptical about your openness. <g>
but themselves. It also helps to sell a bunch of app servers for them, so I
doubt if it will change until all the EJB apps implode. <g>Perception is
reality.
doesn't mean that you have to actually execute on those boxes directly. You
can get things done via sockets, C API's, etc. or Java itself exposing
things in a hybrid solution. It doesn't mean that you have to have Java
throughout.
Oracle's or IBM's and not Microsofts?
an issue for enterprises.
This goes both ways, IT departments that are primarily Windows shops will
want to stay with windows.
 

"pNichols" <XXXX@XXXXX.COM>writes
understand, I don't see what Entity Beans are good for. I'd choose
POJO's and Hibernate anytime instead...
 

"Eric Grange" <XXXX@XXXXX.COM>writes
insert a System.gc in those cases...