Service oriented Architecture
Service Oriented Architecture is new paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments.
Services are autonomous, platform-independent computational entities that can be used in a platform independent way. Services can be described, published, discovered, and dynamically assembled for developing massively distributed, interoperable, evolvable systems. Services perform functions that can range from answering simple requests to executing sophisticated business processes requiring peer-to-peer relationships between possibly multiple layers of service consumers and providers. Any piece of code and any application component deployed on a system can be reused and transformed into a network-available service. Services reflect a "service-oriented" approach to programming, based on the idea of composing applications by discovering and invoking network-available services rather than building new applications or by invoking available applications to accomplish some task. Services are most often built in a way that is independent of the context in which they are used. This means that the service provider and the consumers are loosely coupled.
This "service-oriented" approach is independent of specific programming languages or operating systems. It allows organizations to expose their core competencies programmatically over the Internet or a variety of networks, e.g., cable, UMTS, XDSL, Bluetooth, etc., using standard (XML-based) languages and protocols, and implementing a self-describing interface. Web Services are the current most promising technology based on the concept of Service Oriented Computing. Web services provide the basis for the development and execution of business processes that are distributed over the network and available via standard interfaces and protocols. Web services may use the Internet as the communication medium (as well as other transport protocols) and open Internet-based standards, such as the Simple Object Access Protocol (SOAP) as transmission medium, the Web Services Description Language (WSDL) for service definition and the Business Process Execution Language (BPEL) for orchestrating services.
Why SOA ?
Modern businesses need functionality that is both distributed and centralized. Existing systems of record, such as ERP, CRM, SCM, and so on, serve the needs of key segments of the organization. But at the same time, a need for many new processes has arisen that requires a flow that moves from one system of record to another, with the context for the process kept outside of any of the existing systems. The traditional way of building enterprise software is not well-suited to these new requirements and does not take full advantage of the new world of pervasive networks, reusable services, and distributed data. Treating an application as a self-contained world no longer meets the need of business.
An important economic benefit of the Service Oriented Computing paradigm is that it enables application developers to dynamically grow application portfolios more quickly than ever before, by creating compound application solutions that use internally existing organizational software assets which they appropriately combine with external components possibly residing in remote networks. Previously isolated Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), Human Resource Management (HRM), financial, and other legacy systems can now be converted to service enabled architectures and integrated more effectively than when relying on custom, point to- point coding or proprietary Enterprise Application Integration technology. The end result is that it is then easier to create new composite applications that use pieces of application logic and/or data that reside in the existing systems. This represents a fundamental change to the socio-economic fabric of the software developer community that improves the effectiveness and productivity in software development activities and enables enterprises to bring new products and services to the market more rapidly SOA is a logical way of designing a software system to provide services to either end-user applications or to other services distributed in a network, via published and discoverable interfaces. A well constructed, standards-based Service Oriented Architecture can empower a business environment with a flexible infrastructure and processing process and systems functions as services and providing a robust and secure foundation for leveraging these services. Efficiencies in the design, implementation, and operation of SOA-based systems can allow organizations to adapt far more readily to a changing environment.
SOA stacks:
The SOA stacks serves as a unified model for UIs, processes, and information, with a clear separation of duties for each layer.
User Interface |
Process orchestration |
Services |
Business objects |
Distributed Persistence |
User Interface:
The goal is to reuse configurable components and adjustable patterns to reduce the complexity of building and using UIs for enterprise applications.
Process orchestration:
The goal is to make process orchestration easier to build and modify so that applications cab be changed quickly, cheaply, and by a wider group of people than is now possible.
Services:
Services are the callable entities or application functionalities accessed via the exchange of messages that supports the business process. For example : Enterprise services live in the enterprise services repository that stores data that describes the services interfaces, how the services would be used in model-driven development tools and how the services fit into models that describe business processes.
Business objects:
Business objects are the collections of related data and functionality inside a service provider. Business objects also can be units of modeling, a description from a modeling perspective of related functionality. In the purest form of ESA, enterprise services are extensions of business objects.
Distributed Persistence:
The core assumption of single database that was so central to the mainframe/client/server architecture is no longer valid. The ESA stacks assume not only a distributed repository, but also certain levels of redundancy. Distributed database transaction mechanisms also allow many repositories to be updated in a consistent manner.
Service Oriented Computing Research
The architectural layers in the Services Research Roadmap, which are depicted in Figure 1, describe a logical separation of functionality in such a way that each layer defines a set of constructs, roles and responsibilities and leans on constructs of its preceeding layer to accomplish its mission. The logical separation of functionality is based on the need to separate basic service capabilities provided by a services middleware infrastructure and conventional SOA from more advanced service functionality needed for dynamically composing (integrating) services and the need to distinguish between the functionality for composing services from that of the management of services and their underlying infrastructure. As shown in Figure 1, the Services Research Roadmap has three planes with the bottom plane utilizing the basic service middleware and architectural constructs and functionality for describing, publishing and discovering services, while the service composition and management planes are layered on top of it. The perpendicular axis indicates service characteristics that cut across all three planes. These include semantics, non-functional service properties and Quality of Service (QoS).
Figure 1 The research planes in the Services Oriented Architecture
State of Art | Challanges | |||
Service foundations | Enterprise service Bus | -Open standards nased message backbone -Implementation, deployment, management - Set of infrastructure capabilities implemented by middle ware technology -Implemenatation backbone for SOA (application as service) | Dynamic (re)configurable run time architectures. -Dynamic connectivity capabilities -End to End security Solution -Infrastructure support for application integration -Infrastructure support for data integration. -Infrastructure support of service integration -service discovery | |
Service composition | Orchestration | -Service interaction at message level -Perspective and control of single end point -Executable business process | -Automatic composition of services -QoS aware service composition -business driven automated composition | |
Service management | Web services Distributed management (WSDM) Management Using web services (MEWS) Management of web services | -Self configuring services -Self healing Services -Self optimizing services -self protecting Services | ||
Service design and Development( Service Engineering) | -port existing component using wrappers -component based Development, OOAD -Do not address key elements: services, composition, component realizing services -Only address part of requirement | Design principles for engineering service application Associating a service desing methodology with standard software Development and Business process modeling techniques -Flexible gap analysis techniques -Self governance | ||
Table 1 Overview of state of the art and grand challenges in Services Research.
No comments:
Post a Comment