Multi-Tiered Transaction Model for Deployment Operations

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional two-tiered client-server architectures are inefficient for large enterprises due to the tight coupling of business logic, presentation logic, and user interface logic, making it difficult to maintain and update applications, especially in dynamic environments.

Innovation Solution

A multi-tiered architecture is employed, where presentation logic, business logic, and database components are logically separated and moved to dedicated servers, using J2EE standards, allowing for a more flexible and scalable solution with improved deployment services and management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a two-tiered architecture is used, then the system structure is simple, but the coupling between business logic, presentation logic and user interface logic is tight making maintenance and updates difficult

Engineering Contradiction:
Improvesystem structureVSAvoidmaintenance and updates
Core Design Contradiction:
Device complexityVSEase of operation

Solution Approach 1:

The patent divides the monolithic application into separate logical layers: presentation layer, business logic layer, and data access layer. Each layer is independent and can be modified without affecting others, resolving the tight coupling problem while maintaining manageable system architecture.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts the business logic from the client-side monolithic application and places it on the server-side. This extraction allows the business logic to be centralized, making it easier to maintain and update without redistributing client applications.

Inventive Principle:
Principle #2Taking out (Extraction)

2Adaptability or versatility

If business logic is changed frequently in response to changing business rules, then the system adapts to dynamic environments, but the tight coupling in two-tiered architecture makes client-side code brittle and requires frequent updates

Engineering Contradiction:
Improveadaptation to changing business rulesVSAvoidclient-side code stability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements a dynamic architecture where the business logic layer can be modified independently on the server-side. The presentation layer can adapt to different user interfaces through a standardized interface, allowing the system to respond to changing business rules without breaking client-side code.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent introduces a standardized interface as an intermediary between the presentation layer and business logic layer. This interface acts as a contract that allows changes in business logic without affecting the presentation layer, thereby maintaining client-side code stability while enabling frequent business rule updates.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of manufacture

If presentation logic and business logic are tightly coupled in client applications, then the implementation is straightforward, but changing the user interface requires breaking the business logic

Engineering Contradiction:
Improveinitial implementationVSAvoiduser interface changes
Core Design Contradiction:
Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent segments the application into distinct presentation and business logic layers with well-defined interfaces. This segmentation allows the user interface to be changed independently by modifying only the presentation layer, while the business logic remains intact and unchanged.

Inventive Principle:
Principle #1Segmentation

4Adaptability or versatility

If a multi-tiered architecture is implemented, then flexibility and scalability are improved, but the deployment complexity increases

Engineering Contradiction:
Improveflexibility and scalabilityVSAvoiddeployment structure
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal deployment framework that can handle multiple types of components (presentations, business logic, data access) through a standardized deployment mechanism. This framework provides common operations for deployment, management, and monitoring across all layers, reducing the actual complexity despite the multi-tiered structure.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS7747698B2Transaction model for deployment operations
Publication Date: 2010.06.29 SAP SE
  • US7747698B2 patent drawing
  • US7747698B2 patent drawing
  • US7747698B2 patent drawing

AI summary

A system and method are described for performing deployment operations according to a transaction model. In one embodiment, a request to initiate a transaction to perform a deploy service operation is received. In response to the request, the transaction is initiated at a container. The transaction is then committed to a database if the transaction is successful. The successful transaction reflects the deploy service operation being completed at the container.