Service-Oriented Architecture Explained

  1. BUSINESS PROCESS MODELING
    • It is clear that for SOA projects to be successful they must be driven by business requirements and processes. One way to drive business and process agility is to utilize a Business Process Modeling (BPM) tool. These tools can transform systems development from a slow, error-prone manual coding effort into a rapid, automatic generation of executable BPM code. Today when business changes occur, users have to manually change code in monolithic programs and manually retest. By using SOA BPM products these changes can be made diagrammatically at the process model or workflow diagram level. Executable code that reflects these changes will then automatically regenerate, driving business agility.
  2. Lower Left Corner: COMPONENT/SERVICE/APPLICATION MODEL/DEVELOPMENT IDEs
  3. SOA POLICY
    • To adequately address the risks associated with the proliferation of XML and Web Services in the enterprise a series of SOA policies are required that span the application design and development phase and extends to operations and deployment. While organizations are striving to achieve interoperability while reducing integration costs and increasing reuse, they must do so in a way that adheres to existing standards and provides active governance.
  4. CENTER: SERVICE/APPLICATION DEVELOPMENT GOVERNANCE
    • An SOA Governance solution starts with Enterprise Architecture (EA) definition to service design and development through the SOA performance and operational attributes of a deployed web service. With this integration, performance, and policy information about a deployed web service will be made available at the design and development phase so that services can be managed and maintained more effectively, and application developers can make better informed decisions about service usage in the application development lifecycle.
  5. Lower Center: FILE/ARTIFACT REPOSITORIES AND BUILD TOOLS
    • Source Change Management, etc.
    • Being able to access artifacts from systems of record, such as source change management tools is essential to building a robust repository.
    • Security is a critical run-time component of SOA implementations, ensuring information isn't compromised by unauthorized individuals. Security considerations range from threats to message integrity to appropriate access controls existing between services and messages within an application server and those remotely accessed.
  6. RIGHT PANEL: [TECHNICAL]

    SOA OPS MANAGEMENT
    • Web Services Performance
    • Because web services may be distributed in an SOA environment, monitoring and capturing performance data from the end user's perspective is more important than ever. What is needed is a comprehensive service level management tool that monitors, captures, reports and pinpoints the cause of services level exceptions across clients and servers. Services response times are monitored from the workstations, servers and compared to service level thresholds. Diagnostic information should be captured 24x7 and reported on when the thresholds are exceeded.
    • Key performance metrics should be tracked so that they form the basis for the creation and monitoring of Service Level Agreements (SLAs). SLAs are usually established between the operations group and the various lines of business that they support. Key information required to create and monitor a SLA include:
      1. Average throughout
      2. Peak throughput
      3. Type & description of committed SLA
      4. Availability
      5. Consuming service clients
      6. Hardware and software configuration
      7. Fault history
      8. Alert thresholds
  7. SOA Services Network/ESB
    • The infrastructure often requires a messaging system to handle the increased flow of traffic generated on a SOA infrastructure. An ESB guarantees delivery of messages and helps to mitigate the effects of resource failure within applications collaborating on a bus. ESBs are used when the number of services and their interaction grows and/or when guaranteed delivery of messages to a service or within an orchestration process is of utmost importance. ESBs also provide for broadcast style communications, allowing multiple services to be notified in parallel of certain events.
    • The ESB represents each service using a common interface model, regardless of the nature of the resource on which a service is based. The interaction model-how a service is invoked-is event driven and invoked though messages (typically in XML or binary wrapped with XML metadata).
  8. UDDI V2 + auto-publication
    • UDDI products and components are distributed from multiple vendors and are also available as open source. These products and components fall into various categories such as UDDI Registry Server, Java, and .NET client toolkits and UDDI-integrated Web services platforms.