Q1: While using a file adapter if we have declared an elements schema length as 100 and file reading the

file adapter that element contains 120 characters, then what will happen ? Is there any way to read that file? Q2: In a BPEL process there is a partner link which is invoked more than once in this BPEL. While creating assertions in Test suit for this composite how we will write assertions for this partener link? Q3: In a Flow activity if we have added 2 assign activities in each branch, then will we really have performance improvement as compared if we use them serially? Q4: In OSB how to restrict the no of messages coming to Proxy service? Q5: in OSB how to use dynamic URL of business service? (we will get to know the url at rum time or we have to create url at runtime) Q6: While using fault policy framework if have set the retry count as 3. Now when the retry count is exhausted then how this fault will be clost.faulted or open.faulted? Q7: can we have two service bindings in one composite if there is only one BPEL process in that composite? Q8: Q: If we need to validate any message in OSB after pipeline stage according to its destination

****************************************************************************8

soa interview questions

1)Why SOA? What are the advantages? What are the disadvantages?

Service Oriented Architecture Service Oriented Architecture is a technique used in software development based on the concept of Service. A service can be defined as an independent function which is well defined and self contained. In SOA different services communicate each other to perform some activity. Even two or more services can be synchronized together to perform some complex activities. Even though SOA is a new term, the concept of services was introduced long back itself. At that time it used DCOM or ORB depending on the CORBA requirement. A simple Service Oriented Architecture consists of a Service Provider and a Service Requester. The requester requests for some service and the provider implements the service and returns the result for the request. The communication happens in such a way that it is understandable to both provider and requester. Normally a service has to be published before its usage. These need to be invoked to get the benefits of the published service.

Web Services SOA architecture mainly makes use of Web Services in the implementation process. But it does not mean that Web Service is the only method to implement SOA. Other technologies can also be used to implement Service Oriented Architecture. A web service can be defined as a functional component or as an Application Programming Interface (API) which can be accessed over a network. This means that Web services actually reside in some web server and utilized by some W eb connected applications. Web Services are

Self contained Self describing Modular Language independent Interoperable Dynamic

As these services are to be available independent of the platform, technologies or even implementations, they have to follow some standards. This is made possible by using some open technologies. They include

Extensible Markup Language (XML) Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Universal Description, Discovery and Integration (UDDI)

Java EE is a development platform which is mainly intended for Web Service applications. .Net framework can also be used easily for web service development. Comparison to Object Oriented Programming

Service Oriented Architecture can be considered similar to Object Oriented Programming in many ways. In both these design methods, independent functions are kept to implement the functionality. And some techniques are used to communicate among these independent functions. Even the concepts like inheritance and data abstraction exist in both these methods. Both of these techniques ensure reusability, modularity and maintainability. Entities and Processes Involved The main advantage of using SOA is reusability itself. In real life itself, suppose you know that one of your friends developed software as part of his project. You are studying in another college and you have to develop another project with some additional functionality to that of your friends work. Surely you will try to contact your friend, so that you can save your time and effort by reusing your friends work. SOA concept is also somewhat similar to this. Here you can be considered as a Service Requester and your friend as Service Provider. If you already know that somebody else has developed a piece of work which you can completely reuse, you dont have to again do it. Thus you can minimize the complexity involved in your work. But you should know in prior which all services are available and can be reused. This is done with the help of Service Registry. Service Registry can be considered as a database of Services and Service Description. A Service Provider can publish their services and Service Requester can find the available services. Service description actually explains the functionality of the service, the ways to reach it etc. Also the third party who already developed the reusable code (in the real time example, your friend) should be ready to provide it to you for reusing it. This willingness is ensured with the help of some policies and contracts. And some proper communication should happen between the requester and the provider. After finding the apt service, the service requester invokes the service to make use of it. Some of the services like weather forecast report, currency converters etc are commonly used. Many of the sites show the weather report in their site and it may not be actually developed by their own team. Here the requester does not have to know the implementation details of the service. He has to just know regarding the input and output while considering the service. To explain it simply, consider a service Sum which adds two numbers and gives the sum as the result (I too know that no service is needed for adding 2 numbers, but imagine just for the purpose of understanding). The requester does not have to know how the service is implemented while using it. He just has to know that he should give two numbers to the service and it will return a number as the result. Thus the actual complexity is hidden from the user. Advantages SOA allows you to develop a complex product by integrating different products from different vendors independent of the platform and technology. Thus it helps to manage complexity involved. And making effective use of SOA concepts, client can be competent enough as the time needed for the development is considerably reduced because of the reuse. It allows an organization to leverage existing assets, rather than building a new product from scratch without making use of existing ones. This also reduces the software development cycle and cost involved, thus a faster time-to-market is made possible. Disadvantages SOA Architecture would not be suitable for applications with GUI functionalities. Those applications would become more complex if they use SOA architecture which requires heavy data exchange. Also application requiring asynchronous communication cant make use of SOA. Also in case of standalone and short lived applications implementations, SOA will become an added burden. So a wise choice is to be made before selecting the architecture for any software application. SOA as a strategic solution can be opted in long term perspective. Thus make the best use of Service Oriented Architecture in your software development process.

2)What are the approaches to categorize the existing services in a company? ------How do we prepare a service portfolio before implementing SOA?

Implementing a service-oriented architecture (SOA) is among the few corporate decisions that may impact an organization for 20 years or more. Because of this, understanding your IT environment before you take the leap into SOA is crucial. The first important fact to recognize

regarding SOA is that it's a way of life - an architectural model - not a development project. Thus, it may take several years for your organization to fully implement its SOA vision. From a big-picture perspective, SOA offers the following business benefits:

It enables "plug-and-play" application integration to reduce costs and time-to-market. It provides a foundation for "composite application development" (e.g., application construction vs. coding) to reduce costs and time-to-market. It offers a basis for "business-process orchestration" - aligning IT with business processes - for increased competitiveness and the ability to realize more sales opportunities.

Organizations are moving to SOA for a variety of reasons, among them the need for agile IT systems that can adapt to changes and consolidate technologies. For example, most legacy systems have monolithic architectures with all functionality in one centralized location. Making a change in one part of the application may impact other areas. With SOA, functionality is compartmentalized, so making a change in one area won't affect application functionality in another.

Look Before You Leap

Because of SOA's enticing benefits, many organizations are tempted to jump into this enormous undertaking before fully considering the implications to their existing systems. Before moving toward SOA, develop a plan and strategy that includes a reasonable implementation timeframe. Such a plan should include a definition of your IT architecture and a topology and road map for implementation. It should then proceed with a selection of hardware and software suppliers based on the needs of your organization. You also need to understand your current IT environment to see which components can be used in the newly defined SOA strategy. This is perhaps the most critical part of the plan, and far too many organizations skip or gloss over it only to pay the price later in lost time and resources.

Plan Steps Should Include:

Make a complete inventory to eliminate surprises - To determine those components of your current IT infrastructure that will be used in your SOA environment, take a complete inventory. Understanding tools and application-portfolio management (APM) tools can provide you with a comprehensive list of databases, programs, files and third-party software products and how they interact with one another. The process of understanding your current environment may be performed in parallel to define how the move toward SOA will be accomplished. This understanding process is critical regardless of whether your organization will be undertaking in-house development, licensing new package solutions, redeveloping your applications, reusing existing systems or pursuing any combination of these modernization options. The first important fact to recognize regarding SOA is that it's a way of life-an architectural model-not a development project.

New development - If you decide to implement new services, it's critical that you obtain an understanding of existing applications. Be sure to document current applications to avoid the loss of functionality when the new applications are written. Many organizations have legacy applications written in the 1970s. Trying to re-implement an older system poses great risks unless the documentation is up-to-date. Several available tools provide application diagrams of existing systems, flow charts and reports that list the artifacts and their inter-relationships. Conducting this research up front will help to define the requirements and timelines for implementation. Package solutions - Most package solutions won't provide 100 percent of the required functionality and/or integrate easily with existing systems. Thus, you should perform a gap analysis to determine the extent of missing functionality. Using tools to define the gap will greatly increase the chances for a successful implementation. The first step should be documenting the features of the existing system. The results of this understanding exercise can then be used to define the gap that exists with the packaged solution. In some cases, you may need to leave pieces of your existing system behind if the package solution is not a one-to-one replacement. The packaged solution may need to interface with your existing system. Once again, use tools to define these interfaces. You may also need to determine the data-access points of the existing application to ensure functionality. Following that, determine if the data must be migrated into the new system. Redevelopment - Redevelopment can be defined as the use of an existing system as a functional specification to re-engineer/re-architect a new system. This solution is ideal for companies that want to leverage years of investment in their large applications. Redevelopment provides the ability to modernize an application so that all business functionality is reused and unneeded code is left behind. As with the other modernization options, begin with a set of understanding tools that can document your current applications and extract the needed business rules. To enhance the efficiency of development, choose a tool that can generate the application code from the extracted business rules. Generated code provides quick, efficient and consistent redevelopment and allows you to enforce coding standards. Re-use of existing systems - If your existing system architecture has been designed to expose your applications as Web services, you may only need to generate an interface. Understanding tools can be used to define the interfaces in the existing system. Many tools on the market provide the ability to wrap online applications with a Web-client interface or transactions with Web services. This is a low risk/quick ROI method for exposing an existing system for your SOA strategy. Refresh/forward fit - No matter which of these SOA schemas is used, every solution must have the ability to track changes to the existing system as the new system is being implemented. That's because existing systems don't remain static. The good news is that APM tools report and analyze changes as they occur. All changes must be analyzed for viability to determine if they're needed in the new system. For example, if a column is added in an existing database but is overlooked in the new system, the application will have a functional deficit. If this change isn't

recorded, it could be very difficult to diagnose and correct. This process must continue until the new system is fully implemented. Work in stages - The best place to begin the implementation of an SOA strategy is with a proof of concept (POC) on a low-risk application, one that won't negatively impact your business objectives. It's likely you'll need to use software and services from several vendors. Employ a low-risk start to validate tools and vendors, making sure each solution, service and/or product meets your expectations. This first step is a good time to bring all parties to the table to ensure that compatibility is possible. After a successful POC, you will be in a better position to move forward, having gained positive momentum and proven ROI.

Once You've Looked - Leap Into SOA

SOA is the vision for the future of legacy systems, but it will take some time to get there. One of the biggest mistakes organizations make is to move toward SOA without understanding their IT infrastructures. The best approach is to make a complete inventory, get an in-depth knowledge of existing applications, re-use or redevelop the legacy applications to forward fit them and then choose a POC project to test out the project. Take these steps and you'll have a much stronger chance of enjoying SOA's promise of strong ROI and business agility.