Replied: Tue, 12 Jun 2001 17:52:19 -0400 Replied: "mehmet sen" Replied: Ozgur Balsoy Replied: John Yin Return-Path: msen@anabas.com Delivery-Date: Tue Jun 12 14:29:17 2001 Return-Path: Delivered-To: fox@csit.fsu.edu Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by mailer.csit.fsu.edu (Postfix) with SMTP id 6952E23A15 for ; Tue, 12 Jun 2001 14:29:16 -0400 (EDT) Received: (qmail 24641 invoked from network); 12 Jun 2001 18:29:16 -0000 Received: from capricornus.hosting4u.net (HELO anabas.com) (209.15.2.36) by mail-gate.hosting4u.net with SMTP; 12 Jun 2001 18:29:16 -0000 Received: from hizmet ([66.47.65.114]) by anabas.com ; Tue, 12 Jun 2001 13:29:14 -0500 Message-ID: <001701c0f36d$ae3f1b10$9865fea9@hizmet> From: "mehmet sen" To: , "John Yin" , "Ozgur Balsoy" Cc: Subject: New Architecture Proposal Date: Tue, 12 Jun 2001 11:29:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0F333.009DD800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0F333.009DD800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With Ozgur we discussed an interesting architecture design for the = backend of the current system, which coupling of GXOS and EJB pool. We can replace backend database with the GXOS file system storage in our = regular server. Some expected obstacles can be avoided by using the = following strategies: Performance (Scalability):=20 Currently we guarantee it by using Weblogic EJB Pool and = Oracle database. Instead of retrieving data from the database, we can get it from the = GXOS file system. However, different than the lightweight version, we = can manage the XML object in EJB pool. We will continue to use Weblogic = EJB pool with XML objects loaded from files. No use of Oracle anymore. = In fact, EJB pool idea is to isolate the storage from the application. = Therefore, nothing is against the EJB model. Performance (Memory management, caching) Directly comes from EJB pool management. =20 Performance (Efficiency of searches): The XML model removes almost any need for the search of old = style SQL searches in our current application. In the future, there may = be needs for extra free searches like description of meetings, titles, = address searches, etc. Though we do not have them currently, we may need = to improve different strategies for them later. In worst case, we can = include database partially as a search tool in the design. Some benefits, Current EJB implementations (at Anabas and outside world) do = not really utilize the EJB pool idea. The main reason is that relational = database is not object database. Therefore, to construct object = understanding at application level, we need many unnecessary database = accesses.=20 In contrast, GXOS provides object understanding at = application level, at the same time stores it in the same way. Loading = XML objects from the file system to EJB pool will be very efficient. Our = application wants to see them as whole objects, and EJB pool is designed = to manage objects. GXOS stores objects in logical chunks, like = participants of meeting, hostings of user, etc. Mehmet ------=_NextPart_000_0014_01C0F333.009DD800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

With Ozgur we discussed an interesting = architecture=20 design for the backend of the current system, which coupling of GXOS and = EJB=20 pool.

We can replace backend database = with the GXOS=20 file system storage in our regular server. Some expected obstacles can = be=20 avoided by using the following strategies:

Performance (Scalability):

Currently = we=20 guarantee it by using Weblogic EJB Pool and Oracle database.
Instead = of=20 retrieving data from the database, we can get it from the GXOS file = system.=20 However, different than the lightweight version, we can manage the XML = object in=20 EJB pool. We will continue to use Weblogic EJB pool with XML objects = loaded from=20 files. No use of Oracle anymore. In fact, EJB pool idea is to isolate = the=20 storage from the application. Therefore, nothing is against the EJB = model.

Performance (Memory management, caching)

= Directly =20 comes from EJB pool management.

Performance (Efficiency of searches):

The XML = model=20 removes almost any need for the search of old style SQL searches in our = current=20 application. In the future, there may be needs for extra free searches = like=20 description of meetings, titles, address searches, etc. Though we do not = have=20 them currently, we may need to improve different strategies for them = later. In=20 worst case, we can include database partially as a search tool in the=20 design.

Some=20 benefits,
= =20 Current EJB implementations (at Anabas and outside world) do not really = utilize=20 the EJB pool idea. The main reason is that relational database is not = object=20 database. Therefore, to construct object understanding at application = level, we=20 need many unnecessary database accesses.

= In=20 contrast, GXOS provides object understanding at application level, at = the same=20 time stores it in the same way. Loading XML objects from the file system = to EJB=20 pool will be very efficient. Our application wants to see them as whole = objects,=20 and EJB pool is designed to manage objects. GXOS stores objects in = logical=20 chunks, like participants of meeting, hostings of user, etc.

Mehmet

------=_NextPart_000_0014_01C0F333.009DD800--