January 23, 2021
Hot Topics:

Assembling "New" Service Based Solutions from Existing Services

  • By Surekha Durvasula
  • Send Email »
  • More Articles »

Overview of Architectural Components

A full-scale set of architectural service components includes the following:

  • Enterprise Content Collaboration Service: This is a course-grained Service Façade responsible for orchestrating multiple services. This Service Façade enables the details of internal service orchestration details and the inner workings of the request/response flows to be hidden from the consumers (whether they are visual consumers or true system consumers). This layer of indirection also enables the Content Collaboration Service provider to insulate its consumers from any negative impacts when switching work flow engines, content management repositories, or XML-processing engines. In addition, this layer insulates the provider by enabling it to make product decisions based on its ability to meet QoS needs and business SLA needs without getting tied down in consumer interactions with the low-level components. Having the coarse-grained service interface also allows the service provider to make better capacity-planning decisions about which candidate services and/or business components it can scale out to remove bottlenecks without causing disruptions to the consumers. Without this layer of indirection there is a possibility that consumers will consist of hard-wired legacy components and low-level APIs—or even specific service URLs that make both the provider and the consumers more fragile and vulnerable to changes.
  • Enterprise Security and Workflow Service: This is a service component that authenticates Content Collaboration service users and provides an interface to edit the authorization rules that control how malformed user request exceptions are handled. Exception flows could include scenarios where the user request cannot be processed due to "data not found," "invalid request parameters," or "incompatible grain-of-information issues."
  • Enterprise Information Optimization Service: This Utility Service component applies XPath/XSL and CSS-type XML payload and/or envelope transformation rules to "canonicalize" a request or response. It also internally deals with the complexity of processing the XML, dealing with XML fragments resulting from XPath/XQuery operations, and allows the request to be generated to optimize the interaction with the Information Integration service. Other benefits of the utility service include consumer ease of use, because it can formulate a request with correct metadata without forcing the consumer to create the request in a specific format. This facility enables the provider to offer a friendlier service interface while ensuring that the rest of the service components do not have to invest in exception-handling logic—which in turn makes the subsequent provider service component interactions more deterministic. The response is also canonicalized in one and only one utility to ensure that none of the other service components have to worry about changing their response parameters, all while still enabling consumers to get a well-formed and standard response back from the Content Collaboration service provider.
  • Enterprise Information Integration Service: Another utility service that coordinates between structured content and unstructured content repositories to process and aggregate user requests. The efficiency of this service is proportional to the mapping metadata available on the content, the inclusion of the right request metadata, and the canonical request formation by the Information Optimization service. This service takes a canonical XML request and turns it into SQL to access a content repository and/or relational data structures to get the information to create a response.
  • Execution Path of the Architectural Components

    All these architectural components must be coordinated to execute a call. As discussed earlier, user request metadata, content metadata taxonomy, XPath and XQuery expressions, SQL filter statements, or DAO API mappings must all be determined at design time, leaving associations of keywords and metadata to occur efficiently at runtime. Here's an explanation of the execution path:

    1. End user service or customer logs into the enterprise portal
    2. Request parameters and service authentication credentials are passed to Enterprise Content Collaboration Service
    3. The Enterprise Content Collaboration Service calls the Security Service to authenticate the user and forwards the call to the Enterprise Information Optimization service.
    4. The Enterprise Information Optimization service validates the request parameters, identifies the right pre-configured XPath/XQuery function to perform XML transformation—making the request a "canonical request" (one that includes the correct request parameters and mapping metadata).
    5. The canonical request is now forwarded to the Enterprise Information Integration Service, which associates the request keywords to content-tagging information in the content repository or to the structure relational constructs. The XML request is turned into SQL WHERE filter statements by a Data Access Object (i.e. data access API) to call the content repository and/or the relational structures.
    6. The SQL query gets executed and retrieves the binary content and/or relational data based on the user request parameters. If an error occurs, an exception or error message gets sent back to the Enterprise Information Integration service.
    7. Enterprise Information Optimization service processes the response to turn this into a canonical response or report any processing errors that occurred during the request. Exceptions could occur because mapping metadata wasn't found or because user request parameters were at a different grain of information than the data granularity in the content repository—thus causing the request to be incompatible with the data. For example, a user request for low-level transactional information is at a different grain or level than a request for summarized information in the structured data repository. Similarly, a user might request legal pre-trial preparatory documents, but the content repository may contain only trial proceeding documents.
    8. The Enterprise Content Collaboration service returns the canonical response or error notification to the user. The Content Collaboration service examines the response status to determine the next steps.
    9. If the response caused an error notification, then that error notification gets forwarded to the Security and Workflow service to identify the "appropriate manual work flow process" to be executed, determined by mapping the error code in the response to the error handling flow in the workflow engine
    10. As part of the exception workflow, the response error also allows the appropriate call center or help desk service associate to help resolve the issue. In addition, the request/response pair may be logged, to track future enhancements to the Content Collaboration service that will help satisfy the service consumer.

    All the steps above demonstrate the importance of including the right keywords in the canonical request/response models to enable identification and execution of the right design constructs. This underscores the importance of having XML Schema-based validation for the canonical request/response models. Additionally, library selection is based on the association of the "appropriate" metadata (such as content meta-tagging, mapping to structured data filter statements, mapping to a DAO to execute the appropriate SQL, association to XPath/XQuery functions to extract the right keywords from the canonical models, error notification tagging of the exception-handling flows etc.).

    Page 2 of 3

    This article was originally published on July 22, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date