Saturday, January 28, 2012

Start Small, Grow Fast | Companion Checklist

A companion checklist that summarizes the Oracle SOA Suite best practices contained in the "Start Small, Grow Fast" Oracle whitepaper by Demed L'Her, Edwin Biemond, and Ronald van Luttikhuizen at

Administrative considerations

  • Involve operations teams from the beginning.
  • Make sure your organization has dedicated middleware administrators.
  • Prefer scripting for deployment of composites.
  • Use SOA Suite configuration plans to capture all environment-specific information instead of hardcoding them in your composites.
  • Avoid creating a separate configuration plan per composite per environment - consolidate these to a few or a single configuration plan per environment.
  • Script as many configuration tasks as possible from the beginning.
  • Document configurations in a well-known central location such as a team Wiki, readily available to all stakeholders.
  • Consider using NFS shares for JCA adapter configuration plans.
  • Use partitions to categorize composites and execute various tasks for multiple composites at once.
  • Use composite sensors to enable the search of specific instances.
  • Negative testing is an absolute requirement.

Infrastructure considerations

  • Build a cluster from the start -even if only with a single node. Think of the following when configuring a cluster:
    • Use individual IP addresses for all components (WebLogic Admin Server, Node Manager, and the Managed Servers).
    • Use the JRockit JVM and Mission Control to detect problems and perform tuning.
    • Leverage WebLogic channels to separate cluster traffic from production traffic.
    • Use a load balancer to divide traffic between services and detect outages of servers in the cluster.
  • Think about your domains. There is no such thing as a “one-size fits all” domain topology; however there are a few tips and guidelines in this area:
    • Always setup Node Manager.
    • Do not combine Admin and Managed Servers; except maybe in non-critical environments such as development.
    • Deploy your software and services to Managed Servers.
    • Leverage domains to partition environments with different lifecycles or significant functional differences.
    • Dedicate the most performant hardware to Managed Servers.
  • Linux x86 is a great entry-level platform for Oracle SOA Suite.
  • Favor Oracle Database as infrastructure database.
  • Perform realistic load tests.
  • Define and test a purging procedure well before going live.

Design-time considerations

  • Use MDS to centrally store artifacts and avoid duplication.
  • Have a canonical model for your core objects to ensure future re-use and consistency.
  • Consider taking a contract-first or meet-in-the-middle approach for interfaces exposed to the outside world.
  • Formulate and adhere to a small set of service design guidelines and naming conventions:
    • Language conventions
    • Naming conventions for composites, services, references and components
    • Naming conventions for BPEL and BPM components and activities
    • Naming conventions for composite sensors
  • Wrap frequently used SOA Suite APIs in simpler custom APIs.
  • Use Domain-Value Maps (DVM) and Business Rules to improve flexibility and agility.
  • Use fault policy files to separate exception and fault handling from “normal” process logic. Centrally store them in MDS to enable re-use across composites.
  • Unit test your composites using SOA Suite’s test framework as you would unit test your Java code using e.g. JUnit.

Architectural considerations

  • Use a simple and concrete service categorization.
  • Spend some time thinking about the granularity of your services to avoid too frequent refactoring. Reusability is a key factor. Other factors are rate of change, availability, and ownership.
  • Building asynchronicity through business events or messaging will improve loose-coupling, ease of deployment and administration and enable throttling.
  • Consider supporting multiple versions of the same service in production to allow service consumers to upgrade at their own pace.
  • SOA governance is needed but can start very simply with a wiki. Consider a full-fledge repository as you grown your SOA efforts.

No comments:

Post a Comment