This Article is intended to people who just want to start with their SOA Journey and are in process to articulate their “to-be” architecture. This blog covers the best practices followed right from the beginning when any organization is about to begin their SOA journey.
Before you Start
Enterprise Architect (who is responsible for overall SOA implementation) should evaluate the current landscape architecture. to do so following points should be consider –
- What are the current integration strategy? does organization use any middle-ware and planning to move to Oracle SOA Suite or organization built all custom integration.
- What are the primary reason for change (implementation of SOA)? like integration complexity, growing number of applications, TCO etc.
- What is current landscape topology?
- What are the security requirements of the organization?
- How many applications will be integrated using Oracle SOA Suite?
- How many are cloud applications and how many are legacy systems or on-premise applications?
- where is organization’s gravity (on-cloud or on-premise)? current and in future?
Under the topology consideration, topology architecture provided by Oracle should be considered. As shown in below Figure (Courtesy of Oracle)
Other thing which should also be considered is Oracle Identity Manager (OIM) along with above topology to add to the security when data is flowing from outside (publish internet) of organization network to inside the network firewall.
Sizing of the servers will depends on –
- Volume of data synchronization per day
- Size of the data per interation
- Peak load, lean load and average load
- If interaction is schedule based then frequency of the data sync
- Additional data persistence requirement
- Additional mechanism to build to prevent data load
- Production licenses middleware products.
- How many products – SOA Suite, BAM, OSB, BPM, MFT, etc.?
- How many core and CPUs?
There is still a job for architect. This time it could be Integration / Oracle Middleware architect who should go deep down here on. Following design should be laid down before Integration development starts.
Which product from Oracle Middle-ware family should be used and when?
- If there is need to integrate cloud to cloud applications, prefer to use Oracle Integration Cloud Service (ICS) on cloud.
- When should be used BPEL, when should Mediator and when should OSB? Below diagram explain the respective functional area.
- Use OSB for –
- Service Virtualization
- Message oriented Solutions
- only entry point for external systems
- Shouldn’t use OSB for –
- Complex Service Orchestration
- Complex business login in Proxy Message Flow
- Java callout for complex business logic
So, recommendation here is to use hybrid architecture where cloud to cloud integration can be done leveraging ICS while ICS can talk to SOA Suite / OBS securely and on-premise systems should talk to SOA Suite / OSB.
Design of individual interface design
it is important to design the integration interface, gather the functional requirements and draw the skeleton of interface. blue print design should cover interaction pattern with all applicable applications/ systems. Design skeleton spins across with details of adapters, SOA components and security features like OWSM, CSF map and keys etc.
This is the time when architect should decide, based on the business requirements, that implementation should follow top down approach or bottom up approach (Or sometime mixed of both, which I generally prefer).
If you want to migrate Oracle SOA from previous version to new version, it requires whole set of new Strategy and Best Practices which I will try to cover in coming blogs.
Once you have completed blue print design, next step is to start the project (implementation) in agile fashion. Some people think that there is no need to follow Agile methodology during SOA implementation, I strictly feel that SOA implementation must follow Agile, both for small implementation or when organization wants to restructure the whole SOA Strategy and Governance. few best practices which should follow during implementation are listed below –
Implementation Best Practices
- Created services are as atomic in nature as better. those can be separately deployable even better (microservices concept)
- Implementation must follow Agile development.
- One implementation (could be multiple services) should solve one business problem / requirement.
- Common services should be built as generic and extendable services like error handling, logging, notification, business rules, human intervention services etc.
- Use MDS and OER (little advance user) for sharing common artifacts.
- Implement adequate security (depending upon business requirement) around each interface.
- OWSM provides standard based security mechanism, it is highly recommended to use OWSM.
- CSF framework should be used where ever is applicable.
- For the deployment of composites from non-production to production environment is recommend only via automated deployment scrip leveraging config plan or any other deployment plan.
- Use DVM for static references and XRef for dynamic references.
- Use ICS, OSB, Mediator, BPEL, BAM, BPM as appropriately needed and are best fit to that.