Service-Oriented Architecture

Description : Service-Oriented architecture (SOA) is an architectural style that formally separates services,which are the functionality that a system can provide, from service consumers, which are systems that need that functionality.

Description

• This separation is accomplished by a mechanism known as a service contract, coupled with a mechanism for providers to publish contracts and consumers to locate the contracts that provide the service that they desire(diinginkan).

• Rather than coupling (penggabungan) the consumer with the service in terms of technical aspects of invoking the service,

• SOA separates the contract from the component or implementation of that contract.

Description

• This separation produces an architecture in which the coupling between the consumer of the service and the modules that produce the work is extremely loose and easily reconfigured.

Benefits of an SOA

• SOA can be of enormous (maha besar) benefit to the modern enterprise. – It provides an important new avenue for

integration of applications. – Creating new applications under an SOA

offers a significant increase in the qualities of availability, interoperability, maintainability, and reliability for those applications.

Benefits of an SOA

• SOA benefits flow primarily from breaking applications into modules with a well-defined interface contract that leads to very loose coupling between services and applications.

• Loose coupling between consumer and provider benefits the consumer because consumer applications are effectively protected from changes in service provider implementations and the consumer has a greater choice of providers.

Benefits of an SOA

• It benefits the provider because from an implementation of loosely coupled systems come applications that map much more closely to the business processes that represent a company's value proposition.

• In addition, these applications increase the enterprises' competitiveness because they are easier to modify to satisfy changing business conditions.

• In addition, applications and work processes assembled using an SOA are cheaper to maintain.

Benefits of an SOA

• Organizations that adopt a service-oriented philosophy of development will be able to handle change more quickly and cheaply.

• SOA can provide a major increase in the value of the data and application resources of a company by enabling a major new mode of integration of these assets.

Benefits of an SOA

• Decreased application development costs• Decreased maintenance costs• Increased corporate agility• Increasing overall reliability by producing

systems that are more resistant to application and equipment failure and disruption.

• Providing an application upgrade path that is considerably cheaper and less disruptive than the total application replacement that is the norm using monolithic applications.

Application development costs are reduced for the following reasons:

• Code reuse is extensive.• Most of the code has been thoroughly

tested.• The presentation layer is the only layer

requiring customization for different clients.

• RAD development via automated code generation becomes a possibility.

Characteristics of an SOA In general, SOAs have the following

characteristics:• Services have well-defined interfaces (contract)

and policies.• Services usually represent a business function or

domain.• Services have a modular design.• Services are loosely coupled.• Services are discoverable and support

introspection.• The location of services is transparent to the

client.• Services are transport independent.• Services are platform independent.

Services Have Well-Defined Interfaces and Policies

• Well-defined interfaces (contract) are a central concept for SOAs. All services publish a contract.

• This contract encapsulates the agreement between the client of the service and the service.

• Contracts are what the consumer peruses when searching for a service.

• The contract contains all the information necessary to create an application that is capable of accessing the service. Using the information in the contract to access and utilize the service is called binding.

Services Have Well-Defined Interfaces and Policies

• Contracts are a new concept to many IT professionals. The old paradigm, carried over from procedural programming days from object-oriented development (OOD), is that applications are a set of classes that provide the desired functionality.

• Classes are organized into inheritance hierarchies with subclasses inheriting both data members and functionality from their chain of parent classes.

• Applications are built from a collection of classes that interact with each other via their functions. These functions consist of a hopefully) descriptive name and a function signature. The function signature states what data type the class will return and what data it requires as input. Function signatures imply synchronous, tightly coupled,procedures called interactions.

• Classes provide a type to which to bind during the compile.

Services Have Well-Defined Interfaces and Policies

• This system of classes and subclasses has several limitations. Tight(ketat) coupling introduces rigidity and makes future enhancements harder to implement, which is undesirable in a software system of any size. If changes are made in the parent, it can affect the functionality of the children.

• Incorporating functionality from more than one superclass involves multiple inheritance, which introduced even more fragility.

• Some object-oriented (OO) languages, Java being one of them, do not support multiple inheritance.

Web Services

• Web services have been chosen for in-depth discussion because they are a well known and extremely important example of an SOA implementation.

• Many enterprises have already started to implement Web services, and most others have plans to implement them in the future.

Web Services• Web services are an example of an SOA. One

very important thing that Web services have over most other SOA implementations is that they ad here to open standards.

• The open standards that form the basis of Web services theoretically allow any Web service to interact with any other Web service.

• Proprietary protocols, data translation, and vendor lock-in become a thing of the past. The menu of solutions for your IT problems grows enormously (besar/berkembang).

Web Services

Following are the open standards utilized by Web services:

• The transport protocols HTTP, FTP, and SMTP• The messaging protocol SOAP (Simple Object

Access Protocol)• The interface description language WSDL(Web

Services Description Language)• Registry protocols such as UDDI (Universal

Description, Discovery, and Integration) and repositories such as ebXML

Web Services

• One of the SOA principles is that services should be independent of the means of transport. Currently, all Web services communicate using a single transport: HTTP. FTP and SMTP are listed as alternate Web services transport modalities, but they are not particularly popular because they preclude (menghalangi) carrying on a conversation between applications.

• However, HTTP will continue to be the most popular transport for Web services messages for some time to come.

Web Services

• HTTP is popular for Web services because HTTP messages can pass readily through firewalls.

• When you are contemplating connecting to a service physically located in a different enterprise, or even in a different location within the same enterprise, firewall transparency is attractive.

What is the SOA life cycle?

• The core IT assets of any organization include its data, legacy systems (current system), line-of-business applications, packaged applications, and trading partners. Each of these resources is a service provider responsible for producing numerous highly specific outputs, such as inventories and customer data.

What is the SOA life cycle?

• Service orientation ties together these disparate and autonomous sources of information, bridging a wide range of operating systems, technologies, and communication protocols.

• The process by which it does this is an iterative one of creating (“exposing”) new services, aggregating (“composing”) these services into larger composite applications, and making the outputs available for consumption by the business user.

What is the SOA life cycle?

Expose

• The expose phase of the SOA approach focuses on which services to create from the underlying applications and data. Service creation can be fine-grained (a single service that maps to a single business process) or coarse-grained (multiple services come together to perform a related set of business functions).

Expose

• The expose phase is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively (secara asli) if they already speak Web services, or can be made available as Web services though the use of an adapter.

Compose• Once services are created, they can be

combined into more complex services, applications, or cross-functional business processes. Because services exist independently of one another as well as of the underlying IT infrastructure, they can be combined and reused with maximum flexibility. And as business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications.

Consume• Once a new application or business process has

been created, that functionality must be made available for access (consumption) by either other IT systems or by end users. The goal of the consumption process is to deliver new, dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including Web portals, rich clients, Office business applications, and mobile devices.

SOA Issues• Implementing an SOA environment will cost time and

money. Some organizations have no budgetary process to finance infrastructure development. In such organizations, all information technology development projects are developed for and managed by a specific customer.

• This customer assumes all the costs associated with the development of the application. If it were decided, under this model, to develop an application for a customer using an SOA environment, the customer would have to assume the entire cost of developing the environment, as well as the cost of using it to build the application. This system of financing for IT projects punishes infrastructure development.

SOA Issues• Applications built using an SOA will not only be cheaper to develop

and have a faster time to market but will be significantly less expensive to maintain.

• Unfortunately, it is a common financial procedure in most enterprises to separate the cost of developing an application from the cost of maintaining it. It is well known to software engineers that the cost of maintaining an application is several times more than the cost of developing it. An effective method of financing application development is to have the customer pay for both development and maintenance costs. Using that financial model, what maintenance is really costing will become painfully evident to the business side of the enterprise. When cradle-to-grave financing is used, the lower maintenance costs of SOA applications will become quickly evident. Building an SOA and using it to develop applications will demonstrate a positive ROI that will more than justify the initial outlay required.

SOA Issues

Distributed architectures such as SOA are at the other end of the spectrum when it comes to specifying and satisfying SLAs. The plus side is as follows:

• The modular, layered nature of an SOA naturally lends itself to setting up parallel,redundant athways of communication between the various components that are required for the functioning of the service. This can help make a server resistant to network problems.

SOA Issues

• The simple, modular nature of the components in the service layer lends itself to achieving stated reliability levels through clustering of servers.

• Asynchronous communication can be much more tolerant of network disruption than synchronous communications.

• Since services are located and connected to at run-time, it is possible for system architects to easily change the location of components in response to systems architecture changes.

• Distributed architectures also provide the possibility of having applications recover from the unavailability of a component by binding to an alternative component, perhaps at an alternative location.

SOA Issues

Following is the negative side:• The distributed nature of SOAs makes them very vulnerable

to network issues. Not just gross network failures that are easy to spot, but also slow, easy-to-overlook network slowdowns and intermittent congestion.

• SOAs are hosted on many machines. A seemingly innocuous change in the availability any one of a number of computers has the potential to disrupt a service.

• The complex nature of some systems built on an SOA makes it very difficult to mathematically derive SLA parameters. Unless you have an extremely thorough system to monitor the elements of your execution platform, initially any SLA numbers will be speculative.

• Yes, there are numerous ways to tune and tweak SOA systems. However, that tuning and tweaking will cost time and money.

SOA Management

• An SOA will eventually become the backbone of your business. The business case for it is too compelling for it to be otherwise. The more central your SOA becomes to your business, the more you will require an effective set of management tools. The SOA attributes of loose coupling and decentralization of service modules mandate a centralized control structure. The ideal end result is for your SOA to be loosely coupled but tightly managed.

SOA Management

Existing network management tools that are not designed for SOA management are inadequate to manage an SOA for the following reasons:

• They are usually binary in nature; they can tell if an application is up or down. Applications are now composed of interacting modules; information about the health of the modules and of their connections is what is required.

• They have no awareness of business processes.• They have no understanding of the concept of grouping

modules into functional units.• They have no way to effectively manage the security

requirements between the modules in the SOA network.

SOA ManagementSOA management is a complex issue. We suggest examining your needs around the following topics before examining SOA management solutions:

• Performance information• Monitoring and management of running services• Monitoring and management of network issues• Dynamic method for a service to find and bind to its management

agent or services• Management of SOA security issues• Management of SLAs• Management of the evolution of services and the service life cycle• Management having the capability to be extendable across

enterprise boundaries

SOA Best Practices

The following is a short and almost certainly incomplete list of SOA best practices. Feel free towrite your own in the margins.

1. Do your business architecture work first. Understand the major business processes and how they relate to each other. Map the business processes to the data and systems architectures. Use that knowledge to plan your SOA.

2. Start small: Build incrementally. Use the first project to build the component infrastructure for your SOA. Add to your SOA on an ad hoc basis, and document and share what you have learned from each SOA project.

3. When encapsulating existing legacy functionality, use the SOA.

SOA Best Practices4. Wire in what you have. Leverage the standards-based

interoperability of the SOA to allow you to integrate your application infrastructure.

5. Architecture is as important to your Web services as to your SOA. Use architectural principles to set the contracts that your services offer to consumers. Get the grain the size of the service you expose in the contract correct. The contract should expose a relatively coarse-grained contract and fulfill the contract by aggregating several fine-grained components.

6. Think agile when building services. Make the creation of services an opportunity to increase the adaptability and efficiency of your organization.

7. Maximize reuse of components by making them small and cohesive.8. Start building in your management tools early in your SOA effort. Do

not allow yourself to get in the position of being forced to retrofit a management solution, at great cost to the business, when your SOA suddenly starts behaving poorly.