|
The AGMS 1.0 codebase is currently inactive.
Background:
GoodServer’s original technology in 1997 was a SQL-based IMAP4 server, with the key technology being a query translator that converted an IMAP4 FETCH query into a SQL statement (an open cursor) on Oracle, DB/2, or SQL Server.
The product philosophy was to provide the protocol handling, while off-loading all I/O onto the RDBMS.
The chatty nature of the IMAP4 protocol caused the server to respond slowly to MUA operations, even with the RDBMS bearing a healthy load of 200+ TPS (which is all GoodServer could afford at the time). The AGMS middle-tier was born, and initially served as a transaction-aware cache, so that mail store operations per
second were now in the high thousands.
Over the next few years, the IMAP4 protocol stack was separated into GoodServer’s most successful product, the IMAP4 Server SDK. The SMTP Server SDK and POP3 Server SDK products were also born, forming the back-bone of GoodServer’s e-mail server toolkits. For customers unwilling to endeavor building an email server from scratch using these SDK’s, concrete servers were developed for AGMS, and ultimately bundled with AGMS.
AGMS 1.0 was licensed in 2002 (then AGMS 0.8) by a prominent contact center company, and GoodServer performed a rigorous one-year implementation. In that solution, AGMS handles inbound emails, delivering them to an Oracle-based mail store, and routing them based on the contact center’s existing media routing engine. The heavily customized IMAP server also handles agents reading & handling emails, agent-to-agent transfers,
voicemail, and software routing agents.
Some lessons learned during the implementation include:
- AGMS being CORBA-based was a liability, not an asset. CORBA-accessible would have been better. For every JavaMail interface, there had to be a corresponding CORBA IDL type, and a message would often have to be copied many times as it left the JavaMail/IMAP4rev1 world and entered the CORBA world, and vice-versa. This prevented code elegance and simplicity in many areas.
- GoodServer’s persistence library is dated (1997-1998), and not nearly as attractive, or tested, as libraries that are now available.
- The proprietary AGMS container pre-dates J2EE, and in the modern world would be more universally appealing if repackaged as a J2EE solution.
- Coding
business rules in Java in the protocol command handlers (IMAP doFetch, or SMTP doRcpt, for example) led to code complexity. After a hundred or so business rules were implemented (many code-generated and dynamically loaded based on customer-designed email workflows), the code became very heavy and confusing. If at all possible, a future version should help to keep business rules out of the email server, and in a graphical form. A business rules editing tool that deploys to an email workflow
engine might help deal with this issue.
So, after a healthy period of reflection and post-mortem, AGMS 2.0 is now mostly specified, and GoodServer is ready to help a new licensee extend their contact center solution with world-class e-mail handling capabilities.
The AGMS 1.0 Components Were:
- AGMS Service. A Java-based CORBA 2.3 mail store middleware server, capable of persistence to any back-end via a storage driver adapter class. This tier was essential when building a DBMS-backed IMAP server, and the critical role it played was caching and transaction management.
- AGMS Storage Driver . A custom Java class that implemented persistence of the AGMS elements to the customer’s data store.
- AGMS IMAP4 Service. A concrete IMAP4 server implementation, written using the IMAP4 Server SDK framework, coded as an AGMS CORBA client. This full-featured email server was data-driven by the mail store.
- AGMS SMTP Service. A concrete SMTP server implementation, written using the SMTP Server SDK framework, and coded as an AGMS CORBA client.
Links:
|
