What is SOA?
SOA stands for service oriented architecture. Before we define SOA lets first define a service. In real world service is what we pay for and we get the intended service. For instance you go to a hotel and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.
So in order to order a item from a hotel you need the three logical departments / services to work together (counter, kitchen and waiter).
In the same manner in software world these services are termed as business services. They are self contained and logical. So let's first define a business service, SOA definition will be just an extension of the same.
Definition of business service: - It's a logical encapsulation of self contained business functionality.
For instance figure 'order system' shows a simple ordering system which is achieved by different services like payment gateway, stock system and delivery system coming together. All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it's just a black box which takes messages and serves accordingly. For instance the 'payment gateway' business service takes message 'check credit' and gives out output does the customer have credit or not. For the 'order system' business service 'payment gateway' service is a black box.
Now let's revise some bullet points of SOA before we arrive to a definition of SOA.
. SOA components are loosely coupled. When we say loosely coupled means every service is self contained and exist in alone logically. For instance we take the 'payment gateway' service and attach it to a different system.
. SOA services are black boxes. In SOA services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes services become more loosely coupled.
. SOA service should be self defined: - SOA services should be able to define themselves.
. SOA Services are maintained in a listing: - SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
. SOA components can be orchestrated and linked to achieve a particular functionality. SOA services can be used/orchestrated in a plug and play manner. For instance figure 'Orchestration' shows two services 'Security service' and 'Order processing service'. You can achieve two types of orchestrations from it one you can check the user first and then process order or vice-versa. Yes you guessed right using SOA we can manage work flow between services in a loosely coupled fashion.
So let us define SOA.
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.
(I) In SOA do we need to build systems from scratch?
No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in generic fashion to the external world.
(I) Can you explain business layers and plumbing layers in SOA?
In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
The simple order system can be divided in to two layers (see figure 'business and plumbing layer' one which is business related and second which is more technical related. You can see the plumbing layer consisting of data access layer , AJAX , yes more of technical stuff.
Figure: - Business layer and plumbing layer
(I) what's the difference between services and components?
Services are logical grouping of components to achieve business functionality. Components are implementation approaches to make a service. The components can be in JAVA, C#, C++ but the services will be exposed in a general format like Web Services.
(A) Can you describe the complete architecture of SOA?
Figure 'Architecture of SOA' shows a complete view of a SOA. Please note this architecture diagram is not tied up with implementation of Microsoft, IBM etc. It's a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.
Figure: - Architecture of SOA
The main goal of SOA is to connect disparate systems. In order that these disparate system work they should messages to each other. ESB (Enterprise service bus) acts like a reliable post office which guarantees delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It's not hardware or some wire etc. It's a group of components/software which helps you to send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle, progress etc.
SOA registry is like a reference database of services. It describes what each services do, where are they located and how can they communicate. It's a central reference of meta-data for services.
SOA workflow allows us to define work flow using the services in SOA registry. We will read more about BPM in the further questions.
Service broker reads the work flow and takes services from the SOA registry and ties them together. Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.
Process manager is nothing but the collection of SOA registry, SOA workflow and service broker.
SOA supervisor is traffic cop ensuring that services do not have issues. It deals mainly with performance issues of the system so that appropriate service levels are met. If any of the services have performance problems it sends messages to the proper infrastructure to fix the issue.
Note: - The above explanation is of general architecture for SOA. Any vendor (Microsoft, IBM, SUN etc) who gives solution for SOA should have the above components in some or other manner. As this is a Software architecture book, we will not be covering specific vendor implementation. We would advise the reader to map the same to their vendor products for better understanding.
(I) Can you explain a practical example in SOA?
(I) What are ends, contract, address, and bindings?
These three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be available to the client. End consists of three important things where, what and how:-
. Contract (What)
Contract is an agreement between two or more parties. It defines the protocol how client should communicate with your service. Technically, it describes parameters and return values for a method.
. Address (Where)
An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
. Binding (How)
Bindings determine how this end can be accessed. It determines how communications is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or BINARY over TCP. So for each of these communications medium two bindings will be created.
Below figure, show the three main components of end. You can see the stock ticker is the service class, which has an end hosted on www.soa.com with HTTP and TCP binding support and using Stock Ticker interface type.
Figure: - Endpoint Architecture
Note: - You can also remember the end point by ABC where A stands for Address, B for bindings and C for Contract.
(I) Are web-services SOA ?
SOA is a thinking, it's an architectural concept and web service is one of the technical approach to complete it. Web services are the preferred standards to achieve SOA.
. In SOA we need the services to be loosely coupled. A web service communicates using SOAP protocol which is XML based which is very loosely coupled. It answers the what part of the service.
. SOA services should be able to describe themselves. WSDL describes how we can access the service.
. SOA services are located in a directory. UDDI describes where we can get the web service. This nothing but implementation of SOA registry.
oracle soa bpel interview questions
1. Is Oracle SOA same as Oracle Fusion Middleware
Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services from J2EE and developer tools, to integration services, business intelligence, collaboration, and content management. Oracle Fusion Middleware offers complete support for development, deployment, and management.
Oracle SOA Suite is an essential middleware layer of Oracle Fusion Middleware. It provides a complete set of Service Infrastructure components for designing, deploying, and managing composite applications
2. What is SOA Governance
Service-Oriented Architecture (SOA) governance is a concept used for activities related to exercising control over services in an SOA
3. How to increase performance increase in bpel (Db Adapter/file adapter)
We can increase the performance by writing indexes and sequences.
(Or) Go to application server --- >Configurations ----- > Change Xml file
4. Predefined errors in BPEL?
Custom errors
Timed out errors
BPM errors
Validation Errors
5. Is it possible to use MS SQL Server as dehydration store with SOA Suite ?if yes how?
Yes it is possible.
To automatically maintain long-running asynchronous processes and their current
state information in a database while they wait for asynchronous callbacks, you use a database as a dehydration store.
Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. This feature increases both BPEL process reliability and scalability. You can also use it to support clustering and failover.
6. What are the various elements in WSDL?
Various elements are:
Types, messages, operation, port, bindings and Services.
Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints.
7. Why do we need to have messages in WSDL, aren't operations and types enough to describe the parameters for a web service
Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. The set of message-typing attributes is extensible.
•The element describes the data being exchanged between the Web service providers and consumers.
• Each Web Service has two messages: input and output.
•The input describes the parameters for the Web Service and the output describes the return data from the Web Service.
•Each message contains zero or more parameters, one for each parameter of the Web Service's function.
•Each parameter associates with a concrete type defined in the container element.
So describing the parameters cannot performed by operations and types this is the main need of Messages
8. What is structure of SOAP message?
The structure of a SOAP message: A SOAP message is encoded as an XML document, consisting of an element, which contains an optional element, and a mandatory element. The element, contained within the , is used for reporting errors.
The SOAP envelope
The SOAP is the root element in every SOAP message, and contains two child elements, an optional and a mandatory .
The SOAP header
The SOAP is an optional sub-element of the SOAP envelope, and is used to pass application-related information that is to be processed by SOAP nodes along the message path.
The SOAP body
The SOAP is a mandatory sub-element of the SOAP envelope, which contains information intended for the ultimate recipient of the message.
The SOAP fault
The SOAP is a sub-element of the SOAP body, which is used for reporting errors.
With the exception of the element, which is contained in the of a SOAP message, XML elements within the and the are defined by the applications that make use of them, although the SOAP specification imposes some constraints on their structure. Figure shows the main elements of a SOAP message.
Asynchronous vs. Synchronous BPEL process
This article explains the difference between an asynchronous and a synchronous process.
I have tried to explain the difference with the help of a simple example below:
Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.
Case 1: Client invokes SynchronousBPELProcess.
1. Client invokes SynchronousBPELProcess.
2. SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
3. SynchronousBPELProcess completes its operations and sends a response back to Client.
4. Client continues and completes its processing.
Case 2: Client invokes AsynchronousBPELProcess
1. Client invokes AsynchronousBPELProcess.
2. AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
3. AsynchronousBPELProcess completes its operations and callback the Client with the response message.
Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.
Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.
What makes the difference?
Synchronous Process:
The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.
Asynchronous Process:
In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.
Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.
Fig 3: An image showing a call to asynchronous and synchronous process.
We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.
* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.
