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 bit.ly/soa-start-small.



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