Web Services Architecture Design Using Structured Methodology

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing Web Services technologies lack a structured methodology and design patterns for scalable and reliable architectures, leading to capacity and performance issues, and often fail to provide reusable components and effective integration with legacy systems and cross-platform interoperability.

Innovation Solution

A structured methodology and design patterns for Web Services are introduced, incorporating a framework that assists in deriving reference architectures, implementing Web Services architecture design mechanisms, and applying design patterns for scalability, reliability, and security, enabling integration with legacy systems and cross-enterprise integration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If Web Services are implemented without a structured methodology, then development speed may be increased, but architecture reliability and scalability deteriorate

Engineering Contradiction:
Improvearchitecture reliabilityVSAvoidmethodology complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the Web Services development process into distinct phases (requirements analysis, architecture design, implementation, deployment, maintenance) with specific deliverables and gateways for each phase. This structured segmentation ensures reliability by providing systematic control over each aspect of development while managing complexity through phased approach.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent emphasizes preliminary actions in the form of upfront requirements analysis, architecture design documentation, and establishment of governance frameworks before implementation begins. These preliminary actions ensure that reliability considerations are built into the foundation of the Web Services architecture, preventing later issues while maintaining manageable complexity through proper planning.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If legacy systems are integrated using traditional methods, then integration capability is achieved, but system interoperability and reusability deteriorate

Engineering Contradiction:
Improvecross-platform interoperabilityVSAvoidintegration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces service registries, description languages (WSDL, UDDI), and standard protocols as intermediary layers between legacy systems and Web Services. These intermediaries enable cross-platform interoperability by providing standardized interfaces and communication mechanisms, reducing integration complexity through abstraction and standardization rather than direct custom integrations.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent promotes universal integration approaches using standard Web Services protocols and descriptions that can work across multiple platforms and legacy systems. By using universal standards like SOAP, WSDL, and UDDI, the solution achieves broad interoperability while managing complexity through standardized rather than custom integration patterns for each system.

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

3Adaptability or versatility

If vendor-specific Web Services architectures are used, then product functionality is achieved, but vendor independence and reusability deteriorate

Engineering Contradiction:
Improvevendor independenceVSAvoidarchitecture design complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent inverts the traditional vendor-specific approach by starting with open standards and generic Web Services architectures, then allowing vendor-specific implementations to build upon this standardized foundation. This inversion ensures vendor independence by making standards the base layer rather than vendor products, managing complexity by providing a common framework that all vendors must adhere to.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent emphasizes universal, vendor-independent Web Services architectures based on open standards that can be implemented by any vendor. By focusing on universal protocols and descriptions rather than vendor-specific implementations, the solution achieves vendor independence while managing complexity through standardized approaches that work across different vendor products.

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

4Productivity

If Web Services lack reusable components, then implementation flexibility is maintained, but development productivity and maintainability deteriorate

Engineering Contradiction:
Improvedevelopment productivityVSAvoidcomponent framework complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent promotes preliminary creation of reusable service components, templates, and patterns during the architecture design phase. By preparing reusable elements in advance through proper planning and documentation, development productivity increases as these pre-built components can be leveraged across multiple projects, while complexity is managed through systematic organization of the component library.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7698398B1System and method for generating Web Service architectures using a Web Services structured methodology
Publication Date: 2010.04.13 ORACLE AMERICAN INC
  • US7698398B1 patent drawing
  • US7698398B1 patent drawing
  • US7698398B1 patent drawing

AI summary

System and method for generating Web Services using a Web Services Structured Methodology. One embodiment may be implemented as a Web Services architecture design mechanism. Lifecycles of the Web Services design process may include vision and strategy, architecture design, development, integration, and deployment. In one embodiment, the Web Services architecture design mechanism may implement a structured methodology design process for Web Services. One embodiment may include a reusable Web Services design pattern catalog and a mechanism for maintaining and updating the catalog and for using the catalog to apply design patterns when designing and implementing Web Services. One embodiment may be used for Enterprise And Cross-Enterprise Integration of Web Services. One embodiment may be used for Legacy Mainframe Integration and Interoperability with Web Services.