Thursday, July 25, 2013

Integrated SOA Gateway Vs E-business Suite Adapter

INTEGRATED SOA GATEWAY
E-BUSINESS SUITE ADAPTER
SOAP web service
Standard JCA service
Provided out-of box from EBS
Provided from SOA suite in mid-tier
Provides Interoperability leverage from standard web service client(WLS JAX-WS, Apache Axis,. NET)
Provided via Oracle BPEL Process Manager or Enterprise Service Bus in Jdeveloper
Multi-Service Transaction failures need to be handled explicitly
Multiservice transaction failures are rolled back implicitly via transaction control of JCA framework
Consumption of External web services for lightweight integration via native service invocation framework
Consumption of external web services is via Oracle BPEL Process manager or Enterprise service bus
Integration transactions are monitored via SOA monitor
Integration Transaction are monitored via BPEL PM,ESB Consoles
Comes inbuilt with Oracle E-Business R12+ versions
Full-use licenses  for SOA suite, EBS adapter, WLS suite needs to be purchased
Supports integrations PL/SQL API,BSO,BE,XML Gateway(IN) & Concurrent program, Java APIs (forms)
Support  PL/SQL API,XML Gateway(IN),Concurrent Program, EDI, Open Interface tables & views
WS Policies cannot be defined
WS Policies(AT,RM,MTOM) can be defined (through OWSM and SOA suite)
Asynchronous Interaction pattern is not supported prior R12.2 version
Asynchronous Interaction pattern is supported
New product since EBS R12.1.1
Supports EBS 11iCU2,R12.0.X,R12.1.X

Wednesday, June 26, 2013

SOA Principles

To achieve the above benefits, SOA implementations must incorporate the essential principles/disciplines:
• Loose coupling: This must be incorporated between services thereby reducing the level of dependency between consumers and providers.
• Discoverability: Services should be independently described and be published into services registries (OSR-Oracle Service Registry) and repositories(Oracle enterprise repository-OER) so as to facilitate design-time searches and runtime look-ups. This can be defined in Governance model of the enterprise
 Location transparency: This refers to the ability of a service consumer to be able to invoke a service regardless of its actual location in the network and that the consumer has the right to access the service. Location transparency is often linked to service virtualization concept used in OSB, where the consumer simply calls a logical service and Oracle Service Bus (OSB) maps this logical service call to a physical service.
• Autonomy: Services under the service contract that they make with their resource providers and contracts that they offer to their consumers, need to be self-contained and must manage their own dependencies on other services or contributing applications upon execution.
• State management: Services need to handle their own state management per their contract.
• Reusability: A service should package information and business logic such that, where and when applicable, multiple consumers should be able to use it as a shared resource either directly or via composition.
• Composability: Services should be easily composable from other services and technical functionalities, and should be able to participate easily in other higher-level functionalities, such as a composite service or a composite business application

SOA Benefits

SOA addresses the difficulties associated with silos of IT infrastructure and benefits of applications Enterprise integration with SOA are

§  Greater Interoperability
§  Improved business visibility. Enable faster reaction to business events through increased visibility
§  Manage business and technology change(upgrades)
§  Application and process service enablement
§  Faster data access (better compatibility between applications)
§  Service & process integration giving visibility into information across multiple systems
§  Reduce integration cost and complexity
§  IT Agility and manageability
§  Increased Service Reuse: reducing ongoing development costs and reduced time to market
§  More responsiveness
§  Faster time service
§  Ensure high availability and scalability of the digitized platform
§  Lower ongoing maintenance and support costs: Integrations that are easy to maintain and less risky to evolve even upon upgrades. Provide end-to-end solution monitoring with root cause analysis
§  More flexible configurability with less customizations
§  Lower TCO
§  Support for open industry standards
§  Streamline business process exception handling
§  Compliance and governance by realizing better and standardized operational procedures, SOA provides basis for comprehensive security solution and better visibility into business operations and exception conditions



Tuesday, March 5, 2013

SOA Governance?



SOA Governance can be defined as the interaction between policies (what),
decision-makers (who), and processes (how) in order to ensure SOA success.For Architect,They need to have goverance initiative When implemeting SOA based soln,when SOA roadmap is built,we need to have SOA Governance roadmap, understand risks,appropriate goverance process,how manage lifecycle,How manage change impact analysis,appropriate processes/poliicies/tools.
SOA governance provides ability to quickly and continuously translate and transmit business strategy and requirements into processes,policies and controls that will guide evolution of company's infrastructure and enterprise

Failure to provide effective SOA governance exposes your organization to serious
risks resulting from
• Insufficient adoption of services
• Fragmented approaches to SOA
• Resources wasted on services that can’t be reused
• Rampant and redundant service creation across siloed SOA initiatives
• Ineffective communication of priorities and best practices
• Cultural resistance to change


effective governance ensures that communication, collaboration, and the  flow of information
keeping SOA initiatives and investment connected to the enterprise to deliver sustainable business value

Role of an Architect in SOA Governance model
->It is architect who helps in defining the SOA governance fro an organization and success of governance initiative  rests on Architect.
Following practices provide good foundation upon which organization can extend and grow their SOA capabilities:
1.Translate the vision into corporate strategy:
This could be done by building reference architecture & implementation road map to achieve business goals.Governance reqs are met at each stage of implementation process by incorporating some checkpoints/controls.The startegy must be communicated to stakeholders through guidelines/policies to make sure evrything from high-level metrics to detailed best practices is accessible to everyone-from executive to developer.To gain the most reusability across lines of business, departments, and projects, it is important
to create standards to which architects can design solutions.

2.Enforcing this strategy
Standards,policies and process gates(best practices) are created to support this strategy to ensure that project meet requirements/resources.
Guidelines for priortizing service requests need to be made.SOA staregy should be aligned with where your business is going and develop a concrete idea of what you expect from SOA investments.SOA Roadmap outlines projects to be implemented with SOA to ensure that you deliver business and SOA Strategy.

3.SOA Visibility
SOA Visibility needed to be established and maintained with constant analysis to make good decisions.An automated and structured tool for SOA monitoring,enforcement,traceability and compliance need to be used.Use this information to support a product lifecycle
approach, complete with a versioning strategy, service retirement, and upgrade path, to minimize disruption to your customers.

4.Support for innovation and protect performance
A well-managed SOA nurtures innovation by providing an enevironment in which services and systems can be used in creative,unanticipated ways which provide unexpected business value.Effective governance must balance this flexibility with system performance through continuous  monitoring.

5.Tracking and promoting SOA Success
Good SOA governance depends upon on information up and down value chain so communicating goals and progress to all stakeholders help in ensuring both top-down and bottom-up support for SOA.To ensure SOA success, you should enact policies and supporting processes that support the
delivery of the SOA Roadmap. You should communicate them widely, and then monitor their
implementation and make adjustments as you go. This is the essence of governance with
SOA—enacting policies and procedures to ensure the timely and appropriate execution of
your SOA Roadmap.

According to a strategic planning assumption by Gartner Group’s Paolo Malinverno, through 2010, the lack  of working governance arrangements will be the most common reason for the failure of SOA projects (0.8 probability). Conversely, companies that have established governance to help individuals make good decisions within the context of the problem space, have matured their SOAs successfully. These companies have also achieved an effective layering of SOA
capabilities in areas such as architecture, technologyinfrastructure, operations, information, governance, people and organizational structure, portfolios, project execution, and finance.A SOA Roadmap built using a maturity model, such as Oracle’s Five-Level SOA Maturity
Model: Level 5 SOA,1 allows companies to begin the SOA journey, and manage the transformation to SOA by building on each successive step, and ultimately delivering the SOA benefits expected: service reuse, improved integration, interoperability and business agility

To meet business,EA and SOA goals,policies must be enacted across different business areas:architecture,technology infrastructure,information,finance,portfolios,people,projects and operations.This is the role of
governance: i.e. policies, which need to be designed and enacted to ensure this alignment. The format and medium for policies may be different - some policies can be captured and enforced in technology.The greatest benefit and return on investment with SOA occurs when companies stop trying to maximize investments locally (silos) and start maximizing all assets across the entire
enterprise.


SOA Maturity Model?


Why we need SOA Maturity Model?

SOA maturity model basically serves for following purpose

1.Descriptive purpose-where companies are with respect to othrs in industry so they are talking in same  language
2.Roadmap--they are able to set priorties

To be clear about the gaps to meet business requirements and individualize based on business goals and to be able to put effort in terms of work,resources,budget,enable business to meet goals.

Framework which we put around SOA how project is funded,data ownership/data standards,how portfolios are built,operations are carried,architecture,technology foundation,project are funded,people built.We can use the same framework to define policies/governance framework that we need to make SOA successfull,we can defined goal for future,understanding risks and mitigating against it.

Signifance of 8 dimensions in SOA maturity model

->The 3 SOA strategies

->Project driven--you apply SOA tools/techniques project based betn depts.foundation to be built on SOA capabiliies
->Service/consolidation driven--SOA is means to consolidate the duplicate capabilities betn different systems betn diff depts
->Process driven-Companies automate business processes and use SOA as foundation for the automation of processes.

Based on maturity you can decide any of three strategies

Oracle AIA PIPS Vs Oracle SOA

Oracle AIA PIPS
Oracle SOA
1.It is Built on SOA framework and leverages features of SOA.
1.It is an underlying layer of AIA
2.PIPS are pre-built by oracle
2.SOA interfaces are not pre-built.They need to be architected based on company’s governance and maturity to adopt SOA.
3. lots of customization/extensions makes it complicated/ambiguous
3.More flexible configurability with less customization
4.Lack of good logging/reporting capabilities
4.Good logging/reporting capabilities
5.Modularaity not much supported
5. Provides support to Open SLA standards and providing modular approach.
6.Reduced development time and high reusability but there was risk of inconsistent data for development  & maintenance
6. Reduced development time and high reusability
7.There was risks involved to evolve and maintain
7.Integrations that easy to maintain and less risky to evolve
8.Interoperability issues
8.No interoperability issues due to canonical data model approach
9.TCO is more compared to SOA TCO
9.Less TCO
10.Deployment involves risks and has bottlenecks
10.Speed Deployment by reusing components (service reuse)
11.Higher on going cost of maintenance and support costs
11.Lower ongoing cost of maintenance and support costs
12.Less agile across businesses
12.Increased business agility
13.ROI is less,however coupled with risks,errors and higher maintenance cost
13.Less ROI with speed deployment and less maintenance cost