SOA – Enterprise Service Bus

SOA – Enterprise Service Bus ”; Previous Next Description The Enterprise Service Bus (ESB) is a software architecture which connects all the services together over a bus like infrastructure. It acts as communication center in the SOA by allowing linking multiple systems, applications and data and connects multiple systems with no disruption. ESB Basics The above picture depicts the communication between software applications in a service-oriented architecture via ESB. Bus is a communication system that transfers data between computers and interconnects the hard disk drives, CD ROM, graphics adapters and other chips. ESB as Transaction Manager As shown in the above figure, the ESB can synchronize with transactions to communicate with multiple services. Instead of notifying the web applications to coordinate with transaction, the ESB can synchronize with transaction when multiple distributed applications get involved in a transaction. ESB as Security Manager The authentication and authorization mechanisms are very important parts of security check which are incorporated under ESB. The ESB provides these security mechanisms to inter connect between the web applications. ESB as Service Proxy The SOA uses proxy which interprets the service calls between two different client service protocols. For instance, consider you need to access a service which can be accessible only through the Java”s RMI (Remote Method Invocation) and this service can be accessed using the web service interface (SOAP). To resolve this, you can use the service proxy which accepts the SOAP calls and render them according to Java RMI service. ESB as Gateway to the World ESB uses the gateway (acts as entrance to another network) through which it can connect to the different services running in the other networks. The gateway manages the data communication which is routed internally or externally from the network. If user wants to access service of an outside network, then user passes data packet to the gateway, which then connect to the requested service destination. Print Page Previous Next Advertisements ”;

SOA – SOA and User Interfaces

SOA – SOA and User Interfaces ”; Previous Next Description Service-oriented applications mostly focus on the interaction between machines. However, in applications, the interaction between user and machine also plays an important role. A user can act as a service provider so that he can set SOA User Interface(SOAUI) design into an overall system design where the user interaction workflow is a part of system workflow. The SOA User Interface follows MVC (Model View Controller) architectural pattern. SOA applications provide the model layer, and User Interfaces occupy the view layer. The environments hosting components in the SOA approach are abstracted as containers that provides infrastructure services. From a User Interface view, below are the containers for hosting client-side UI components: Basic Web browser. Web browser augmented with Java™Script and dynamic HTML. IBM Workplace™ Client Technology™ — the Eclipse-rich client plus native IBM WebSphere® Application Server client support. By supporting technologies like servlets, JavaServer Pages (JSP), JSP Tags etc, the above containers can be expanded. The user that interacts with a business process consists of initiating and awaiting the result of a process. It is important for a human to involve in a process cycle where processes rarely run completely and automatically. In such environment, WS-Human Task can fulfil this requirement. A standardize API can be used to fill a mailbox with tasks that was defined for a workflow service. For example, during a process cycle, if input of addtional data is required, the process establishes correct actor and places the task in their mailbox through the task service. This process resumes its work in the background and the users recieve the entries in their mailbox by processing the pending tasks sequentailly. Print Page Previous Next Advertisements ”;

SOA – Overview

SOA – Overview ”; Previous Next What is Service Oriented Architecture (SOA)? The Service Oriented Architecture is an architectural design which includes collection of services in a network which communicate with each other. The complication of each service is not noticeable to other service. The service is a kind of operation which is well defined, self contained that provides separate functionality such as checking customer account details, printing bank statements etc and does not depend on the sate of other services. History The first report published on SOA by the analysts Roy W.Schulte and Yefim V.Natis in 1996. Why to use SOA? SOA is widely used in market which responds quickly and makes effective changes according to market situations. The SOA keep secret the implementation details of the subsystems. It allows interaction of new channels with customers, partners and suppliers. It authorizes the companies to select software or hardware of their choice as it acts as platform independence. Features SOA uses interfaces which solves the difficult integration problems in large systems. SOA communicates customers, providers and suppliers with messages by using the XML schema. It uses the message monitoring to improve the performance measurement and detects the security attacks. As it reuses the service, there will be lower software development and management costs. Advantages SOA allows reuse the service of an existing system alternately building the new system. It allows plugging in new services or upgrading existing services to place the new business requirements. It can enhance the performance, functionality of a service and easily makes the system upgrade. SOA has capability to adjust or modify the different external environments and large applications can be managed easily. The companies can develop applications without replacing the existing applications. It provides reliable applications in which you can test and debug the independent services easily as compared to large number of code. Disadvantages SOA requires high investment cost (means large investment on technology, development and human resource). There is greater overhead when a service interacts with another service which increases the response time and machine load while validating the input parameters. SOA is not suitable for GUI (graphical user interface) applications which will become more complex when the SOA requires the heavy data exchange. Print Page Previous Next Advertisements ”;

SOA – Blueprint

SOA – Blueprint ”; Previous Next Description The SOA blueprint contains some following goals: Requirements of design principles Specific tasks of design principles Interaction of services Details of integration scenario Templates for the specific tasks SOA Blueprints Concepts The following figure shows SOA blueprint with different concpets: Considerations in SOA There are some considerations must be covered in SOA: Infrastructure Accessible of requirements Performance requirements Platform for system Architecture Models of domain and service Organization of services Process of integrating the structure Quality of the service Message exchange patterns Development Design guidelines for project development Required tools for project Validation and modification required things Handling errors Security for service access Administration Managing and building Testing and deploying the project Location of data stored and registering the application The following figure shows SOA blueprint with different classes: SOA contains the main functions of blueprint which are called as Programs and BAM. Programs The programs are associated with departmental issues which manages the development, monitoring and operation of the SOA. The programs include some areas such as managing services, operation and implementation of service domains, roles of SOA project, conversion between roles and tasks. Business Activity Monitoring(BAM) The business activity monitoring functionality can be used by the products to display the runtime details in the graphical system. The BAM products includes adapters or sensors which are used to access the data using the Java, PL/SQL and other languages. View Layer The view layer provides two types of applications; one is RichClient application and another one is WebClient application. The rich client application processes the data on the client side and contains some locally installed programs little network resources dependance. The web client is a client server side component which contains applications running on user”s computer and connected to server. Application Server The application server includes some functionalities such as workflow, rules, registry, CEP, ESB, services and systems. Workflow The workflow is used when there is an interaction between human and implementation which is done through the XPDL (XML Process Definition Language). The BPEL (Business Process Execution Language) was used for runnable processes. When there is an upgrade in human interaction feature by using the WS-HumanTask and WS-BPEL4People specifications, results in blur boundaries of automated service calls. Rules The rules can be modified or changed commonly at run time when they are not incorporated in the system. You can define the rules which are based on the system or natural language, before becoming accessible by using the interfaces such as Java, Web service etc. The products contains rules like JBoss rules, WebSphere ILOG rules, Visual rules and Oracle business rules. CEP The CEP stands for Complex Event Processing which allows to browse event streams based on the certain pattern which can be uncorrelated in time or content. The Continuous Query Language (CQL) language contains SQL-style query language which attaches the elements for organizing the data streams to the SQL language constructs. ESB The ESB stands for Enterprise Service Bus which gives patterns that are liable for the tasks and ranges from routing to reachability, allow the interaction between message and protocol transformation and manages the SOA environment. The ESB is placed between service provider and consumer which is used for service virtualization. The services and systems are attached to the ESB. Print Page Previous Next Advertisements ”;