Service-Oriented Architecture
What is SOA?
In computing terms, SOA is a standards-based method of systems development and integration. SOA is a design paradigm for organizing and utilizing distributed application. SOA is an architectural framework for software design that works around the concept of services.
SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them. XML is often used for interfacing with SOA services. JSON is also becoming increasingly common.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.
It is an architecture where small application is running independently. SOA defines how to integrate widely disparate applications for a web based environment and uses multiple implementation platform.
Principles
· Reuse, granularity, modularity, composability, componentization and interoperability.
· Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
· Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
· Service reusability: Logic is divided into services with the intention of promoting reuse.
· Service optimization: All else equal, high-quality services are generally preferable to low-quality ones.
· Service encapsulation: Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
Why Is an SOA Approach Required?
SOA approaches to software systems structured around the concept of services enables:
· A consumer of the service to be decoupled from the service provided (producer)
· A business process to be decomposed into discrete, reusable functional components (or services)
· The following benefits:
—Improved business agility
—Align IT with the business.
—Remove barriers between business units and business partners.
—Lower cost of maintaining IT systems
—Speed up delivery of applications to meet business demands.
—Protect IT investments by reusing the existing infrastructure.
SOA and Services
· Services are SOA building blocks
· SOA can be thought of as:
—A collection of services on a network that communicate with one another
—A set of services that are loosely coupled, with well-defined, reusable, platform-independent interfaces
—A higher level of application development
· Services provide access to data, business processes, and IT infrastructure, ideally in an asynchronous manner.
What are the different design patterns in SOA?
Orchestration (Erl, Loesgen)
Co-existent application of Process Abstraction, State Repository, Process Centralization, and Compensating Service Transaction, can can be further extended with Atomic Service Transaction, Rules Centralization, and Data Model Transformation. |
Enterprise Service Bus (Erl, Little, Rischbeck, Simon)
Co-existent application of Asynchronous Queuing, Intermediate Routing, and the Service Broker compound pattern and can be further extended via Reliable Messaging, Policy Centralization, Rules Centralization, and Event-Driven Messaging. |
Service Broker (Little, Rischbeck, Simon)Co-existent application of Data Model Transformation, Data Format Transformation, and Protocol Bridging.
|
Canonical Schema Bus (Utschig, Maier, Trops, Normann, Winterberg, Erl)
Co-existent application of Enterprise Service Bus, Decoupled Contract, Contract Centralization, and Canonical Schema. |
Official Endpoint (Erl)
Joint application of Logic Centralization and Contract Centralization. |
Federated Endpoint Layer (Erl)
Joint application of Official Endpoint, Service Normalization, Canonical Protocol, Canonical Schema, and Canonical Expression. |
Three-Layer Inventory (Erl)
Joint application of Utility Abstraction, Entity Abstraction, and Process Abstraction.
Web service
Web service is type of software system which is used for exchange the data and use information from one machine to another machine through network. Generally Web services based on the standards such as TCP/IP, HTTP, Java, HTML and XML.
Communication method between two electronic devices over world wide web, service that is "always on". It is use for connecting to standard-based services using SOAP over HTTP.
Web services are pure xml based which is used for exchange information through Internet to direct application to application interaction. These systems include programs, objects, messages or documents.
Many software applications written in various programming languages and running on various platforms can use web services to exchange data over computer network.
You can develop Java-based web services on Solaris and that is accessible from your V.B Program that runs on windows.
Difference between XA and Non XA
XA- Extended Architecture
It is an X/open group standard for executing a "global transaction" that access more than one back-end data store. XA specifies how a transaction manager will roll up the transactions against the different data-stores into an atomic transaction.
atomic: a serious of database operation either all occur or nothing occur.
An example, i)both pay for and reserve a seat or
ii)neither pay for nor reserve a seat.
XA is a two-phase commit (2PC) protocol for the transaction. All the operation (Transaction) will completed then commit otherwise abort (rollback). An XA driver can be engaged in a multi-DBMS transaction.
NonXA- Extended Architecture
A non-XA driver only knows the simple setAutoCommit commit or rollback, so two of these (XA & Non-XA) can't cooperate in one transaction.
Non XA driver will not depends on, all operation will completed or not. But Non-XA driver will call commit() one by one operation.
Disadvantages of 2PC
The greatest disadvantages of 2PC is that it is a blocking protocol. If the coordinator fails permanently, some cohorts will never resolve their transactions. After a cohorts has sent an agreement message to the coordinator, it will block until a commit or rollback is received.
What is SOAP?
SOAP stands for Simple Object Access Protocol. SOAP is a communication protocol. It is a format for sending messages. It communicates via Internet. It is based on XML. It is a W3C recommendation. SOAP message loaded in HTTP (envelope is there), for hiding the message. HTTP is a carrier.
What is REST?
REST is Representational State Transfer. It means that each unique URL is a representation of some object. No WSDL is in REST. No envelop directly loaded in HTTP. You can get the contents of that object using an HTTP GET, to delete it, POST, PUT, or DELETE to modify the object.
Service Component Architecture (SCA)
Oracle SOA Suite uses the SCA standard as a way to assemble service components into a SOA composite application. SCA provides a programming model for the following:
■ Creating service components written with a wide range of technologies, including programming languages such as Java, BPEL, C++, and declarative languages such as XSLT. The use of specific programming languages and technologies (including web services) is not required with SCA.
■ Assembling the service components into a SOA composite application. In the SCA environment, service components are the building blocks of applications.
The key benefits of SCA:
■ Loose coupling
Service components integrate with other service components without needing to know how other service components are implemented.
■ Flexibility
Service components can easily be replaced by other service components.
■ Services invocation
Services can be invoked either synchronously or asynchronously.
■ Productivity
Service components are easily integrated to create a SOA composite application.
■ Easy Maintenance and Debugging
Service components can be easily maintained and debugged when an issue is encountered.
A SOA composite is an assembly of services, service components, and references designed and deployed in a single application. Wiring between the services, service components, and references enables message communication. The details for a composite are stored in the composite.xml file.
All service engines can interact in single composite components.
Service Components
Service components are the building blocks that you use to construct a SOA composite
application.
The following service components are available. There is a corresponding service engine of the same name for each service component. All service engines can interact in a single composite.
■ BPEL processes provide process orchestration and storage of a synchronous or an asynchronous process. You design a business process that integrates a series of business activities and services into an end-to-end process flow.
■ Business rules enable you to design a business decision based on rules.
■ Human tasks provide workflow modeling that describes the tasks for users or groups to perform as part of an end-to-end business process flow.
■ Mediators route events (messages) between different components
■ Spring enables you to integrate Java interfaces into SOA composite applications
Binding Components
Binding components establish a connection between a SOA composite and the external world. There are two types of binding components:
■ Services provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. These capabilities are used for contacting the SOA composite application components. The binding connectivity of the service describes the protocols that can communicate with the service, for example, SOAP/HTTP or a JCA adapter.
■ References enable messages to be sent from the SOA composite application to external services in the outside world.
Wires
Wires enable you to graphically connect the following components in a single SOA composite application for message communication:
■ Services to service components
■ Service components to other service components
■ Service components to references
Service Infrastructure
The Service Infrastructure provides the following internal message routing infrastructure capabilities for connecting components and enabling data flow:
■ Receives messages from the service providers or external partners through SOAP services or adapters
■ Sends the message to the appropriate service engine
■ Receives the message back from the service engine and sends it to any additional service engines in the composite or to a reference binding component based on the wiring
SOA Composite
Designer:
You drag service components, services, and references from the Component Palette into the composite in the designer. When you drag and drop a service component into the designer window, a corresponding property editor is invoked for performing configuration tasks related to that service component. For example, when you drag and drop the Oracle Mediator service component into the designer, the Mediator Editor is displayed that enables you to configure the Oracle Mediator service component. For all subsequent editing sessions, you double-click these service components to re-open their editors.
Left Swimlane (Exposed Services):
The left swimlane is for services, such as a web services or JCA adapters, providing an entry point to the SOA composite application.
Right Swimlane (External References):
The right swimlane is for references that send messages to external services in the outside world, such as web services and JCA adapters. Component Palette The component palette provides the various resources that you can use in a SOA composite. It contains the following service components and adapters:
■ Service components
Displays the BPEL process, business rule, human task, Oracle Mediator, and spring components that can be dragged and dropped into the designer.
■ Service adapters
Displays the JCA adapter (AQ, file, FTP, database, JMS, MQ, Oracle Applications, and socket), Oracle BAM binding component, B2B binding component, EJB binding component, ADF-BC binding component, direct binding component, HTTP binding component, and web service binding component that can be dragged into the left or right swimlanes. If the Component Palette does not display, select Component
Palette from the View main menu.
Resource Palette:
The Resource Palette provides a single dialog from which you can browse both local and remote resources. For example, you can access the following resources:
■ Shared local application metadata such as schemas, WSDLs, event definitions, business rules, and so on.
■ WSIL browser functionality that uses remote resources that can be accessed through an HTTP connection, file URL, or Application Server connection.
■ Remote resources that are registered in a Universal Description, Discover, and Integration (UDDI) registry.
If the Resource Palette does not display, then select Resource Palette from the View main menu.
You select these resources for the SOA composite application through the SOA Resource Browser dialog. This dialog is accessible through a variety of methods. For example, when you select the WSDL file to use with a service binding component or an Oracle Mediator service component or select the schema file to use in a BPEL process, the SOA Resource Browser dialog appears. Click Resource Palette at the top of this dialog to access available resources.
Log Window:
The Log window displays messages about application compilation, validation, and deployment.
Property Inspector:
The Property Inspector displays properties for the selected service component, service, or reference. If the Property Inspector does not display, select Property Inspector from the View main menu.
Application View:
The Application View shows the artifacts for the SOA composite application.
Service Components:
BPEL Process:
Create BPEL Process dialog to create a BPEL process that integrates a series of business activities and services into an end-to-end process flow.
Business Rule:
Create Business Rules dialog to create a business decision based on rules.
Human Task:
Create Human Task dialog to create a workflow that describes the tasks for users or groups to perform as part of an end-to-end business process flow.
Mediator:
Create Mediator dialog to define services that perform message and event routing, filtering, and transformations.
Spring Context:
Create Spring dialog to create a spring context file for integrating Java interfaces into SOA composite applications.
No comments:
Post a Comment