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