Service-oriented software engineering
SOSE stands for Service Oriented Software Engineering. The SOA is an Architecture of system design with some structural parameters about software, but SOSE is a Software Engineering system that collects new kind of software engineering methodology with new and effective conceptual contents under SOA Architecture.
SOAs build applications out of software services. Services comprise intrinsically unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, viewing an online bank-statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, they use defined protocols that describe how one or more services can "talk" to each other.
A software developer, software engineer, or business process expert associates individual SOA objects by using orchestration. In the process of orchestration, a software engineer or process engineer associates relatively large chunks of software functionality (services) in a non-hierarchical arrangement (in contrast to a class hierarchy) by using a special software tool that contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices that the designer can manage and the software system can consume and use at run-time.
It is new approach to traditional SOA with cost effective methodology,there is not any service bus because of its transactional bottlenecks.
Requirements
In order to efficiently use a SOA, one must[citation needed] meet the following requirements:
- Interoperability between different systems and programming languages provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication is based on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol.
- Desire to create a federation of resources. Establish and maintain data flow to a federated data warehouse. This allows new functionality developed to reference a common business format for each data element.
Principles
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA[1]:
- Reuse, granularity, modularity, composability, componentization and interoperability
- Standards compliance (both common and industry-specific)
- Services identification and categorization, provisioning and delivery, and monitoring and tracking
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:
- Service encapsulation – Many web services are consolidated to be used under the SOA. Often such services were not planned to be under SOA.
- Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
- Service contract – Services adhere to a communications agreement, as defined collectively by one or more service description documents
- Service abstraction – Beyond what is described 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 composability – Collections of services can be coordinated and assembled to form composite services
- Service autonomy – Services have control over the logic they encapsulate
- Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
- Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms[2]
- Service Relevance – Functionality is presented at a granularity recognized by the user as a meaningful service
The following references provide additional considerations for defining a SOA implementation:
- SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.[3]
- Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.
In addition, one might take the following factors into account when defining a SOA implementation:
- efficient use of system resources
- service maturity and performance
- EAI Enterprise Application Integration
- ^ Yvonne Balzer Improve your SOA project plans, IBM, 16 July 2004
- ^ Thomas Erl Serviceorientation.org – About the Principles, 2005-2006
- ^ SOA Practitioners Guide Part 2: SOA Reference Architecture