Date: Sat, 3 Mar 2001 06:33:52 GMT
Reply-To: Jay Stevens <jay@WHITEHURST-ASSOCIATES.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jay Stevens <jay@WHITEHURST-ASSOCIATES.COM>
Organization: Giganews.Com - Premium News Outsourcing
Subject: Re: JAVA replacing SAS? and J2EE...
My humble opinion...
SAS has already invested HEAVILY in Java development. They have a
complete CORBA compliant interface and object broker that allows JAva
to talk to SAS "objects" on the server. SAS will probably not be
"rewritten" in java but my prediction is that we will see a
significant expansion of the Java interfaces to SAS objects. For
example, rather than using Java to obtain a "workspace" object then
use the "language service" to run a PROC MEANS. Its likely/possible
that PROC MEANS would be just another Java class in the SAS library.
SAS would still be doing the work, but the user would use the MEANS
class and set properties and invoke methods to do the work. Under
this scenario it becomes REAAALLLLLY easy to put just about any
front-end you want on SAS. This is what's been started with the whole
IOM model and Integration technologies.
Rumour has it that development/redevelopment in Java of the actual
front-end software for both Enterprise Miner and Data Warehouse
Administrator has already begun.
As far as interoperability with EJB and J2EE, I don't know that much,
but I think it will be necessary to get more detailed support for Java
(similar to what I've outlined above?) before EJB scalability is
Oh another prediction... AF/SCL are dead dinosaurs. They have already
begun to look an awful lot like Java. My guess... they soon WILL be
Also heard another rumour that v.9.0 will offer some kind of
experiemental support whereby you can embed Java in SAS code. Not
sure about this though.
Whitehurst Associates, Inc.
On Tue, 06 Feb 2001 16:50:55 GMT, firstname.lastname@example.org wrote:
>It is not an issue of replacing, but an issue of development trend. If
>I understands correctly, it seems that Oracle is trying "rewrite" their
>system in Java so that it can run multiple platforms and reduce cost of
>maintaining on so many platforms. I don't know if SAS is willing to
>It is more interesting to look at how Java and SAS can work together. I
>am trying to understand that in the J2EE framework, how SAS can fit in?
>I am not an expert on this. But I heard people talking about CORBA or
>some kind of connector so that SAS application can be hooked with EJB.
>If anybody can shed some light upon this with their development
>experience or thought or some good references/web sites, I will greatly
>appreciate it. It will help me or any other folks who are also
>interested in it understand better ..
>In article <08B08C9FA5EBD311A2CC009027D5BF8101055DC6@remailnt2-
> Sigurd Hermansen <HERMANS1@WESTAT.COM> wrote:
>> I think that they should replace use of java with decaf. They are
>> too wired for their own good.
>> Java has more than its share of advantages as a development tool for
>> interfaces. Java may also evolve into the language of choice for
>> new generations of database systems like Oracle and data mining
>> SAS. SI is certainly trying to write application generators in Java.
>> say that Java will replace SAS is much the same as saying that
>> chips will replace automobiles. Computer chips have replaced or
>> many components of automobiles, but outside virtual reality they
>> real good and tend to be short of amenities.
>> I suspect that wider use of Java will actually make SAS more
>> application developers. When people need to reach into data sources
>> different formats distributed across the Internet, a general purpose
>> access and management tool such as SAS has much to offer. Sig
>> -----Original Message-----
>> From: bill_kossack@MY-DEJA.COM [mailto:bill_kossack@MY-DEJA.COM]
>> Sent: Monday, February 05, 2001 11:03 AM
>> To: SAS-L@LISTSERV.UGA.EDU
>> Subject: JAVA replacing SAS?
>> I've seen a trend of a number of companies thinking that they can
>> replace the use of SAS with JAVA.
>> What do people think of that?
>> Sent via Deja.com
>Sent via Deja.com