entraspan, inc
e-CommerceServicesExpertiseCohesionProjects

Documentation Manual

1 - Introduction - eCommerce Architecture   [+/-]

Cohesion Technology was originally developed to provide an application framework for developing enterprise software.

Many of the ideas were formed from ideas developed for the Defense Advanced Research Projects Agency (DARPA).

Project development originally started in 2000 and has evolved since that time.

The following primary requirements still hold:

  • Maximum Performance
  • Strong Security
  • Lower Maintenance Costs
  • Platform Independence

The following features were added to help meet and exceed the above requirements:

  • Record Based Caching
  • Role Based Security
  • Database Object Mapping

The current core framework including the generic components now consists of 150K lines of source code after removing comments and blank lines.

Most of the major modules now support large scale e-commerce systems.

The system has kept to the original objectives pretty well, and many of the minor support features have become very robust over time.

Because many errors can be caught at compile time, there have been a few major releases where the things that worked well were were made standard and things that didn't work as well were factored out to minimize any legacy code.

For example a simple caching system has evolved into a multi-level secure write-through cache that supports a variety of caching strategies based on the overall number of records, and access statistics along with several reports to evaluate cache effectiveness.

There has been several applications constituting well over 100K lines of custom development built on top of Cohesion Technology so the framework has proven to be very mature.

1.1  Technology - Technical Overview

The actual technology used is rarely important to the end user but is a factor in overall cost.

Cohesion is built using proven technologies and tools with very broad development support.

Building on the wrong technologies could result in diminished future support and performance options.

Why Java?

The Java programming language was chosen above others primarily because it is a type-safe language.

Type-safe languages are evaluated during compile time verses runtime whether call parameters are correct.

Other type-safe languages include C and C++. The source code is compiled to an executable form before being run.

Scripting languages can't be checked for validity until runtime, which means everything has to be tested when a major change is made instead of catching most of the problems at compile time.

Example scripting languages are PHP, Python, Javascript, and Perl. Each of these has their strengths and weaknesses, but for large enterprise development, compile-time checking is a must.

Java J2EE

The entire system is written using the proven Java development language and utilizes the J2EE Servlet stack.

By choice it does not use all of the functionality offered in J2EE.

It was recently learned that e-Bay also adopted J2EE but only selected the same parts.

A large number of third-party libraries are also used for database drivers, e-mail, etc.

Portability

Maximum portability has been maintained by staying away from proprietary or server specific extensions.

Has been successfully run with a variety of leading application servers on a variety of operating systems.

Performance

By keeping the integration simple, the memory foot print is also far less than what would be expected.

Smaller servers written on our platform are often deployed with as little as 30MB of Java runtime memory.

A very large, very active system may be deployed successfully with upwards of 150MB and run without incident.

Keeping the memory size down means it is easier to deploy multiple application servers.

Lower memory usage means more efficient garbage collection and better overall performance.

1.2  Database - Database Design

There are several good database servers to choose from, but our database of choice is Microsoft SQL Server.

One reason being that the query optimization and performance for complex joins has proven to be very fast.

The second reason is the long-standing support for foreign keys. MySQL now supports foreign keys as well.

MySQL is used for simpler databases or ones with smaller tables, and does a good job with high-transaction rates.

Foreign Keys

A foreign key is a database constraint that is defined between two database tables.

Constraints typically represent real world relationships.

For example every address record in a database exists within one country. By defining a foreign key relationship to a countries table it would not be possible to add an address with a new country code unless it was first added to the countries table. In addition, a country could not be removed from the countries table unless there were not any addresses that used that country. So the database maintains referential integrity of the data so you never get references to data that doesn't exist.

Persistent Objects

There are now several persistent object schemes available for storing object data in a relational database.

Some schemes start with the object, and map the field/data to a small number of generic tables.

Cohesion instead starts with the database table with all of the required fields then generates an object that maps to a record.

So when a change is needed, the database is modified and the object is regenerated from the database schema information.

This provides the maximum level of type-safe error checking at compile time. If a database field changes in anyway the code won't compile correctly until it is fixed. This is a huge advantage over having to manually review and then test every piece of code that might use that database field.

The way fields get mapped to the database records has also proven to be highly resilient to adding new database fields to a live database, making upgrades very simple.

1.3  Editor - Generic Cohesion Editor

The generic "Cohesion Editor" is used to create, edit, search, and delete database records in a uniform way. User access rights control what operations can be peformed on each database table.

Search - Available when the current user has select privileges on the table. Boolean searches treat values of yes, true, and 1 are all treated as true. Date searches allows dates in 'mm/dd/yy' format. Date searches can also be relative to the current date by entering a numeric value.

New - Available when the current user has insert privileges on the table. Fields marked with a * have to be entered when creating a new record. Some fields may appear during record creation that will not be editable after the record is created if the field is required and the account does not have edit privileges on that field.

Edit - Available when the current user has update privileges on the table. Only fields that the can be edited by the current user will be editable. When a record is being viewed or modified, any related data is displayed on the right side of the screen.

Delete - Available when the current user has delete privileges on the table.

Next - Will take the editor to the next sequential record in the database. Available when the current user has select privileges on the table.

Prev - Will take the editor to the previous sequential record in the database. Available when the current user has select privileges on the table.

First - Will take the editor to the first sequential record in the database. Available when the current user has select privileges on the table.

Last - Will take the editor to the last sequential record in the database. Available when the current user has select privileges on the table.

Records often depend on records from other tables before they can be created, e.g. an address record is not valid unless it is associated with a person. This often requires a records to be created in a specific order, e.g. the person record has to exist before address records. When records are deleted, it can require deletion of other records, e.g. the person can not be deleted until the address record is deleted also.

1.4  Reports - Generic Query Reporter

A generic reporting tool has been developed to make it easy and consistent to manage multiple reports.

Any database query can be turned into a report.

Report Options

  • Column Visibility
  • Column Sorting
  • Paging of Long Queries
  • Adding a Column Total
  • Showing Sub-Totals
  • Cell Formatting
  • Grid Form Elements
  • Drill-Down Links

Date Reports

Another standard report is a date report.

This report is ideally suited to summarizing data grouped by a common date interval such as a day, week, month, or year.

The date report will also do a trailing summary for any number of days. Most reports default to viewing the last 10 days activity.

Depending on the date resolution, additional fields can be displayed. For example at a yearly view you may only get monthly summaries, but when you drill all the way down to a day, you may see the individual records.

1.5  Caching - Advanced Record Level Cache

The Cohesion Cache supports multi-level access controls that limit the visibility to database table rows based on account.

This allows two separate accounts to access the same table and share no records or only some records in common between the accounts.

The cache has been highly tuned to reduce round-trip requests to the database.

In some cases a Cache pre-fetch method may need to be used to speed up data processing.

Sparse cache fetch queries are used where possible to request the minimum information needed.

Data that is not accessed is free'd up from the cache until it is accessed again.

Very small tables may be pulled entirely into cache since it may be easier, but larger tables may only have one record up to a small percentage of the records available in cache at any given time.

Cache coherency is maintained across multiple servers by using a shared broadcast channel.

1.6  Security - Ground-Up Access Controls

Security was designed from the very beginning instead of trying to fit it in at the end.

Role Based Security

A role based security system is provided that defines access levels to one or more modules.

Each module contains a collection of pages, tables, reports, and tools.

Security profiles are defined for each level that can be supported within a module.

Often there may be only one level defined for a module since all users have access to the same things within it.

A profile is managed with a hierarchy of check boxes for different access rights.

If a role doesn't have access to a module, then it will not appear in the menu options at all.

None of the tools or tables will be accessible and any external references to the module will not be linked.

2 - Directory - Contact Directory   [+/-]
3 - Orders - Order Fulfillment Manager   [+/-]
4 - Profit - Sales Profit History   [+/-]
5 - Inventory - Inventory Manager   [+/-]
6 - Purchasing - Purchasing/Receiving Manager   [+/-]
7 - Suppliers - Supplier Profile Manager   [+/-]
8 - Catalog - Catalog Manager   [+/-]
9 - Pricing - Catalog Pricing Manager   [+/-]
10 - Variants - Catalog Grouping Manager   [+/-]
11 - Shipping - Shipping Services Manager   [+/-]
12 - Commerce - Electronic Commerce   [+/-]
13 - Customers - Customer Relationship Manager   [+/-]
14 - Amazon - Amazon Interface Manager   [+/-]
15 - Auctions - Auction Interface Manager   [+/-]
16 - Channels - Sales Channels Manager   [+/-]
company  ::  contact us  ::  site map  ::  privacy  ::  terms  ::  security  ::  © Entraspan, Located in San Diego, CA
Trusted Site SealTrusted Privacy Seal