By encapsulating a business application behind capability-based interfaces, the service model allows controlled access to mission -critical applications, and creates the opportunity for continuous improvement of the implementation behind that interface.
Service orientation protects investments from the swirl of change. To the business analyst, service orientation is a means of bringing information technology investments more in line with business strategy. By mapping employees, external capability providers and automation systems into a single model, the analyst can better understand the cost tradeoffs associated with investments in people, systems and sourcing. To Microsoft, service orientation is a crucial prerequisite to creating applications that leverage the network to link the actors and systems that drive business processes.
This application model transcends any single device , crossing boundaries respectfully, and rejecting the restrictions of synchronicity. SOA-enabled solutions pull together a constellation of services and devices to more effectively meet your business challenges than the disconnected applications of the past.
Basic Principles of Service-Oriented Architecture SOA [7] Explicit boundaries: The concept of explicit boundaries in SOA means that you can deploy the service anywhere, and this service should be easily accessible by other services, regardless of the platform or programming language of the other service. This enables the programmers to develop highly flexible services that are easy to implement and deploy across multiple platforms. Autonomous services: The principle of autonomous services in SOA states that each service should be independent of other services.
Each service should be properly managed and versioned, so that it does not affect other services in the process. Each service should be built to handle changes easily without affecting the current system where it exists. For instance, you have an online store that uses two services - Order Processing and Order Delivery. These services should be independent of each other. For example, if the Order Delivery service is not available, then it should not affect the Order Processing service.
Every precaution should be taken to make sure that service should survive even if its dependent service is not available. These policies exist in the form of machine-readable language.
If the services need to interact again in future, then the services should check the policy again. These policies enable the developers to move the service from one platform to another without changing the behavior of the service.
Shared schemas and contracts: A schema usually represents the data that a service passes. The contract represents the behaviour of the service, and contains information regarding the structure of the message. To enable a loosely coupled system, services pass schemas and contracts instead of classes and objects.
Loosely coupled systems can be defined as systems in which the executing environment of a service does not affect another services. The information passed by these services is completely platform-independent. Better Return on Investment: The creation of a robust service layer has the benefit of a better return on the investment made in the creation of the software.
Services map to distinct business domains. For example, a company might create an inventory service that has all of the methods necessary to manage the inventory for the company.
By putting the logic into a separate layer, the layer can exist well beyond the lifetime of any system it is composed into. For example, if your organization needs to create a credit card authorization service, there are basically two options. Developers will either develop the functionality as part of the application that needs it, or they will develop it as a separate component.
If credit card authorization is developed as a separate component and used as a service, then it is likely to outlive the original application. Code Mobility: Since location transparency is a property of a service-oriented architecture, code mobility becomes a reality. The lookup and dynamic binding to a service means that the client does not care where the service is located.
Therefore, an organization has the flexibility to move services to different machines, or to move a service to an external provider.
Focused Developer Roles: A service-oriented architecture will force an application to have multiple layers. Each layer has a set of specific roles for developers. For instance, the service layer needs developers that have experience in data formats, business logic, persistence mechanisms, transaction control , etc.
Each layer requires a complex set of skills. To the extent that developers can specialize, they will excel at their craft in a particular layer of the application. Companies will also benefit by not having to rely on highly experienced generalists for application development. They may use less experienced developers for focused development efforts.
The creation of a service layer by definition means that developers have created an additional network interface that can be used by multiple applications. When systems were built using monolithic or client- server methods, security was normally handled on the front-end. Companies often did not even implement database security because it is too hard to maintain multiple security lists. Services on the other hand are used by multiple applications, so they have their own security mechanisms.
An application will therefore have multi-level authentication at both the client level and at the service level. Developers can use tools such as JUnit for creating test suites. These test suites can be run to validate the service independently from any application that uses the service. It is also a good practice to run the unit tests during an automated build process. There is no reason for a QA tester to test an application if the unit tests did not complete successfully. More and better testing usually means fewer defects and a higher overall level of quality.
Support for Multiple Client Types: As a benefit of a service-oriented architecture, companies may use multiple clients and multiple client types to access a service.
Since the layers are split into client and service layers, different client types are easier to implement. Service Assembly: The services that developers create will evolve into a catalog of reusable services. Customers will come to understand this catalog as a set of reusable assets that can be combined in ways not conceived by their originators.
Everyone will benefit from new applications being developed more quickly as a result of this catalog of reusable services. Better Maintainability: Software archaeology is the task of locating and correcting defects in code. By focusing on the service layer as the location for your business logic, maintainability increases because developers can more easily locate and correct defects. The answer depends on who you ask. Both architectures center around the concept of decomposing business problems into services.
This makes the two styles seem similar, but if you dig a little deeper, there are critical differences. Services share as much information as possible. They share software components to maintain consistency and reduce development effort. Microservice-based systems are hopefully built with the concept of the bounded context. We covered bounded context earlier in a post about domain driven design.
First, bounded contexts are meant to contain complexity. In other words, we can create a bounded context for some specific complex business logic. The bounded context connects to other contexts through adapters. And, those adapters protect against change. Emphasis added. Bounded contexts exist to contain complexity. They protect services outside the context from change.
The relationships between services and clients are explicitly defined. At the same time, services communicate with each other as little as possible. Services rarely, if ever, share components in a microservice architecture. This difference goes beyond design. Microservices manage collaboration between development teams by isolating concerns.
SOA does it by exposing them. If you design an enterprise system that shares data between departments, you need it. Microservices avoid this with the bounded context. Development teams can work within their defined interfaces, without centralized control. Service-oriented architecture is about solving business problems with services. So, imagine a vast e-commerce store. It sells several product lines consisting of thousands of products each. Twenty years ago, you might build it as a single application server.
The application server would connect to a relational database. Then, you would place most of the business logic in stored procedures in that database.
You would deploy it on clusters for reliability. Any changes to the system would mean updating the servers, the databases, or both. Applications servers are rigid and need a lot of hardware. There might be different inventory services for each product line.
But, there is a significant opportunity for code reuse. The point-of-sale service might be a composite service. It might have a web server for communicating with clients. It could also have a specialized interface for taking phone orders. Instead of using expensive clustering, you run more than one instance of each service.
So far, this sounds a lot like how you would solve this problem with microservices. But, there is a big difference. The services communicate with each other over an enterprise service bus ESB. The bus implements the Boundaryless Information Flow. So, in our example, the POS service talks to fulfillment and payment processing systems during a sale.
The fulfillment system communicates with the inventory and shipping services, and so forth. This requires coordination.
The services have to agree on how to represent products, sales, and clients. This is where the strong governance comes in. Or does it? A message bus is an effective decoupling mechanism. Coordinating messages between services is still better than tightly coupled or monolithic services. Service developers write to the agreed message formats. Does this need strong governance? As mentioned above, a message bus supports fault tolerance.
You can run more than one instance of each service and use orchestration to share the load. Or, if it suits your application model better, you can run the services in a hot standby mode.
Service-oriented architecture has survived for a long time for good reason.
0コメント