I though we ruled out the fat client solution several years ago. Microsoft is re-releasing the Client-Server paradigm, and the fans are cheering! There are definitely other things in the DNA that's more appealing. One of the things is that you actually get a good, well-integrated, GUI for administration and development, that actually is working. This is really something missing from the Java world. What I'm thinking about is what would happen if Apple would be doing some serious apps on the app-area. I've always regarded Apple's GUI to be more appealing. (Now they don't even support Java 2.) Jon Tirs�n Chief Architect Itec Open Business Integrator AB PGP key lookup: http://certserver.pgp.com:11371/pks/lookup?op=get&search=0xE9032B9A > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Javier Borrajo > Sent: Thursday, December 02, 1999 10:49 AM > To: [EMAIL PROTECTED] > Subject: Re: Roger Sessions World Tour > > > >Javier Borrajo wrote: > >> Hi, Roger won't come to Spain, only US & Canada it seems. Too bad ! > > > >Indeed. You'll miss all the fun <g> ;-) > > > >> I've just been through a COM+ presentation and I can say it > is(will be?) > >> a fine piece of technology. It includes almost everything I > can think of > >> to develop, deploy and administer enterprise apps. > > > >Indeed, having just gone through a "crash course" in Win DNA I can agree > >that it is indeed a rather impressive solution. However, it is at every > >point a subset of J2EE. > > > What I like most about DNA and what I think J2EE still lags behind is: > + IExplorer 5 Dynamic HTML clients with XML Data Islands, > HTML Data Binding, Remote Data Services and local XSLT support. > There is nothing in J2EE as powerful as this combination. > With this technology you can implement a DHTML client with database > access, data sorting and filtering functions, with about 30 lines of > HTML/XML/XSLT/JavaScript code. > We are providing solutions to our clients using JSP and cross-browser > DHTML > and we are severely crippled by not being able to use IE5 non-portable > features > like the ones you can see at > http://msdn.microsoft.com/xml/articles/xml020899.asp > http://msdn.microsoft.com/workshop/author/databind/dude080299.asp > + ADO 2.1 disconnected recordsets. JDBC looks positively crude compared to > this. > With ADO things such us asynch operations, cancel > functionality, conflict > resolution, HTML/JavaScript/XML integration is by far better than > whatever > J2EE provides... well, actually J2EE does not provide **anything** for > HTML > client-side functionality. > > >> So instead of buying > >> 1. a machine with an operating system (let's say UNIX) > >> 2. an app server including EJB and JMS, maybe also JSP/Servlets > >> 3. a web server (can be free, open source such as Apache or included in > the > >> app server) > >> 4. a Servlet/JSP engine (can be Apache or included in the app server) > >> 5. an LDAP directory > >> 6. a database > > > >Or you can buy a machine, isntall Linux for free, and either pick up all > >the software for free, or buy a complete solution such as WebSphere or > >WebLogic Server. This is not a black and white issue; there are lots of > >nuances of grey IMHO. > > > Indeed this is complex subject. And very often we simply cannot choose > the platform, since our client may already have decided that one. > BTW, WebLogic is $15.000 per cpu, WebSphere Advanced is $7.000 per cpu, > Enterprise $35.000 per cpu, probably far more than whatever W2K > may actually > be. > > >> you can simply buy > >> 1. a machine with Windows 2000 including: > >> + Active Directory which is an LDAP directory > >> + ADSI instead of JNDI > > > >But requires all clients to be Win2000, yes? > > > Depends on what you need to accomplish: > + For network authentication clients must be NTLM (propietary) > or Kerberos (standard) enabled, so maybe W2K can be used to > authenticate > UNIX clients? > Have to check that one, first I need to get a 256MB RAM+ Pentium III > server to run > W2K Advanced Server though ;-) > + For Remote Data Services you need OLE DB and RDS Data Factories > at the server for full functionality, what we have used a > limited subset > of RDS on the client with XML/JSP/JDBC/Oracle/HP-UX on the server. > + Using XML/HTTP as the preferred Internet communication mechanism > efectively > makes clients and servers completely independent of one another. > > >> + IIS instead of Apache or whatever web server > > > >IIS is hardly the most functional webserver around. > > > Not a lot of functionality needed from a web server, I'd say. > > >> + COM+/MTS instead of EJB > > > >COM+ has not progressed that much compared with its predecessor COM/MTS. > >It is still functionally a subset of EJB. > > > + Functionality: CORBA Components 1st, EJB 2nd, MTS 3rd. > + Maturity: MTS 1st(available since 1.996), EJB 2nd (usable more or less), > CORBA Components 3rd (non-existent) > > >> + COM+ Events instead of JMS, including a great console to administer > the > >> service. > > > >COM+ Events are severely crippled due to its lack of load-balancing > > >features IMHO. > > > COM+ load balancing may be available more or less when JMS is integrated > with EJB. > > >> + Component Queues instead of... well, Sun still has to "specify" > >> something like this. > >> It can be emulated in J2EE passing serialized Command objects > through > >> JMS. > > > >It's been discussed here how to do this, and I believe someone has > >already implemented this: www.gluebeans.com > > > >> + HTTP load-balancing > > > >Which most J2EE offerings provide as well. > > > HTTP load-balancing is relatively simple. Session replication is another > matter. > Several J2EE vendors provide solutions. > > >> + Components load-balancing... well, someday when it's released. > > > >According to MSFT this will be in AppCenter, which is at best available > >next summer, and most likely with a rather hefty price tag attached to > >it. Saying that "Buy W2K and you get everything for free" is a huge > >overstatement. > > > Certainly so. > > >> + Microsoft Management Console (MMC) instead of another propietary > >> app server console. > > > >Any app server console is proprietary, even MMC. When JMX becomes > >supported however, it is quite possible to make a non-server specific > >console for J2EE servers. > > > Agree, but still have to see a management console that rivals MMC range of > services and ease of use. > > >> 2. a database > > > >Which you have to buy (MS SQL Server). There are lots of good, free > >database servers around, such as mySQL. > > > Choosing database is almost impossible, our client will for sure > decide on this matter. Too much politics on this one. > > >> Too bad ASP is so unsatisfactory compared to servlets/JSP. > > > >No kidding... I can't believe anyone actually uses this crap.. I tried > >once, and it totally sucked. > > > ok > > >> I'd say COM+ is something to consider seriously if your client > >> uses Wintel servers. > > > >Correction: if your client uses W2K servers *and* W2K clients. > > > >/Rickard > > > + Win32 clients actually, not necesarily W2K > + Windows clients is not a terrible requirement for an enterprise app, I'd > say ;-) > > Please don't take this idle rumblings as an endorsement of COM+ > I just try to have as many arrows in my basket for whatever our future > developments may bring. Who knows, maybe we need to do VBasic (!!) > one of these days ;-) > > Best regards > > Javier Borrajo > www.tid.es > > ================================================================== > ========= > To unsubscribe, send email to [EMAIL PROTECTED] and include > in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > >
BEGIN:VCARD VERSION:2.1 N:Tirs�n;Jon;;; FN:Jon Tirs�n ORG:Itec; TITLE:Chief Architect TEL;WORK;VOICE:+46 (8) 343431 TEL;CELL;VOICE:+46 (709) 306109 TEL;WORK;FAX:+46 (8) 343438 ADR;WORK:;;Box 23049;Stockholm;;104 35;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Box 23049=0D=0AStockholm 104 35=0D=0ASweden ADR;POSTAL:;;Ynglingagatan 17;Stockholm;;104 35;Sweden LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Ynglingagatan 17=0D=0AStockholm, 104 35=0D=0ASweden URL: URL:http://www.itec.se EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:19990417T134712Z END:VCARD
