ObjetX Software - Application Development for Web 2.0

Architect Services - Use our experience and expertise to design an architecture to meet your specific system requirements

Architect Services from ObjetX - Get the most out of your development by building for the future

The team at ObjetX has the experience to design or help you design an architecture that will meet your specific requirements. We believe that the ObjetX Application Framework provides a strong foundation for any Microsoft .Net based system; the needs of your application may go beyond the structure of a standard application. Two different approaches to system design may both meet functional requirements - the right architecture can make the difference between a system that works well and one that fails miserably.

One of the key challenges to producing high-quality software architecture is identifying and understanding the software’s architecturally significant requirements. These requirements are the ones that have the most far-reaching effect on the architecture.

Determining which requirements have architectural significance is currently a matter of experience and judgment. For any particular system, architecturally significant requirements must be coupled to the business and mission goals for the system.

If functionality is the only concern in designing an architecture, just about any structure will do. Architecturally significant requirements often arise from

Quality attributes. Security, performance, reliability, modifiability, and so forth are all quality attributes that might affect the structure of the system. Each quality attribute has a collection of structural techniques (i.e., architectural tactics) that are used to achieve it.
Volume of functionality. Any particular function will not have an impact on structure, but large collections of similar functionality will. One example of a structural impact is breaking up the functionality so it can be implemented in a timely fashion. Another example is identifying commonality within the functionality to reduce implementation and maintenance time.
Architecting for a family of related systems. When requirements are being gathered for a collection of similar systems such as in a software product line, the commonalities and variations in those systems may be architecturally significant.
Choice of technologies. There may be a requirement to use a particular technology for a system, such as .NET or J2EE (Java 2 Enterprise Edition). These requirements may be architecturally significant, since many other decisions will be constrained by the use of particular technologies.
Integration characteristics. The need to tie disparate technologies together into a seamless system will have a significant impact on the structure of the solution.
Deployment and operations. Requirements that describe an anticipated deployment strategy and how the system will be operated may be architecturally significant, since structural entities may be required to support deployment or operational considerations.

Service Oriented Architecture

Service-oriented architecture (SOA) describes a software architecture that defines the use of loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

You’ll hear a great deal about the benefits of an SOA, particularly when it comes allowing companies take advantage of existing systems. It is a great concept and very attainable, but there is one element that is required to make any kind of significant SOA based system work – a service broker.

The service broker coordinates and manages all of the resources available to any application component which is involved with the SOA based system. An SOA without a service broker is akin to a telephone system without a phone book – or worse, without a standard way of defining telephone numbers or assigning them to telephones.

The Object Manager can provide the backbone for an SOA. It can facilitate management and authentication, dealing with the thousands of transactions necessary to provide baseline inter-operability amongst disparate systems. It can manage long-transactions to ensure that a process which involves two or more sub-components is managed through from start to finish.

Object Manager – Built for transaction processing.

Intense performance and scalability testing of the Object Manager has led to a deep understanding of how to tune and configure the OM for maximum throughput under various loads. The OM has demonstrated the ability to handle large numbers of discrete, simultaneous transactions as well as a large number of simultaneous users performing a wide range of moderate to heavy application related tasks.

Using a three tier configuration (web server, app server and database server) utilizing intermediate server technology (2.8 GHz, Xeon dual single-processor systems), the OM has demonstrated capability up to 400,000 transactions per hour and support for up to 500 simultaneous users. It has also demonstrated the capability to manage internal resources effectively over a sustained period of heavy application load, including the ability to tune itself and even throttle throughput to ensure continued availability.