What makes a solution service-oriented?
SOA’s approach to solution specification and implementation is such that building new solutions is less an exercise in specifying and implementing new code, and more of an exercise in assembling new solutions from existing pieces. In the context of this discussion, we refer to the solution as a “system.”
In fact, we could say we are concerned with primarily two things: The service oriented systems that provide behavior to users, and the parts out of which these systems are made.
Just to get some definitions straight, let us look at the general meaning of the two words system and part:
- System: an assemblage or combination of things (parts) forming a complex or unitary whole
- Part: a portion or division of a whole that is separate or distinct
To take this discussion further, let us look at a non-software example from the “real world”: a car is an example of a system that is made up of parts, the wheels, the engine, the chassis, the doors, and so on.
Each of these parts is distinct in its own right, and when assembled together in a certain well-defined manner they become a new entity, the car. Each part has a highly specialized role that it plays in the car. It is common for a vehicle manufacturer to use the same parts in multiple different types of cars (system). For example, the speedometer parts might be assembled into both sports cars and off-road vehicles. The reason that this is possible is that the parts were designed in such a way that they could be reused individually in multiple assembly contexts (multiple types of cars). If the speedometer and the dashboard came as one atomic part, then the chance of being able to reuse that part across different models of car would be reduced. When the parts have been assembled into a car, the fact that the new entity -- the car -- is made up of separate parts ceases to be important until one of the parts is faulty and needs replacement. Or indeed, until further parts are purchased from a shop and added to the car to extend its function -– a CD player so that the driver can listen to CDs, or a GPS that allows the driver to navigate unfamiliar roads.
In our description of this example, the word part is used in two ever-so-slightly different ways:
- a part of an existing car; or, a part of the whole, and
- a part that can be used to build a new car or add to an existing car.
Figure 1 below maps these concepts in our example above to their analogous concepts in the world of SOA. Note that although not all of the terms used here are “official” terms, they will help us talk about some interesting aspects of SOA.
Figure 1. Drawing parallels between cars and service-oriented systems
Let’s describe the words in the diagram so we understand what they are illustrating:
- Car maps to a service-oriented system (SO system). This term is used to describe a single service-oriented solution, which has been assembled from a set of parts.
- Part of a car (in the picture, a wing mirror) maps to SO system part. This term is used to describe an individual part of the service-oriented solution whole.
- Car part maps to service-oriented part. This is an individual piece of service-oriented software that can be assembled along with other service-oriented parts to create a service-oriented solution. Note that whereas an SO system part shares the same lifecycle as the SO solution that it is a part of, a service-oriented part has a lifecycle of its own.
Let us look a bit closer at service-oriented parts.
As the name would suggest, these are parts whose substance are oriented around the concept of a service. The SOA governance plug-in referred to in the Resources section provides us with a definition for service: "a service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification". The nature of this orientation is that the parts will either provide or consume services. And so we talk about two different types of service-oriented parts: service consumers and service providers.
Figure 2. The two types of service-oriented parts
A service consumer is a type of service oriented part that only consumes services — it doesn’t provide any services itself. A service consumer acts as a proxy for an entity outside of the system, such as a person or another system (please refer to the item, “Component Business Model,” which is listed in the Resources section), and is their gateway to the functionality provided by the system. An example would be a user interface in the case where this external entity is a person, or a software adaptor where it is another system. Although they don’t actually provide any services themselves, service consumers play a useful role as without them the system is cut off from the outside world.
Service providers provide one or more services and, like service consumers, may consume services as well. Service providers provide the functionality of the system. If a service “executes a repeatable task,” then the service provider is the thing that does the repeatable task. Note that a service provider can provide multiple services. This is important as there is a special truth when two services are provided by the same service provider that would not be true were they on separate service providers. This is that the implementation of services provided by the same service provider can share internal detail, most importantly internal data.
Therefore, the boundaries that we draw with our service providers are very important as they will constrain what is possible for the services they provide. Where you have two related tables managed by two services, and you want certain operations on the first service to have direct access to data in the table managed by the second, then these two services would need to be on the same service provider. If they were on separate service providers, then the implementation of the first service would only be able to access the data of the second service by going through the service itself.
As a general rule, you will always want data to be accessed using a service. However, what we are saying here is that services on the same service provider can share direct access to the same set of tables. So if you had an OrderService and an OrderLineService that are provided by the same service provider, the OrderService might be able to directly access certain information about order lines such as the number of lines on the order, without having to make a service operation call on the OrderLineService itself. In the same way, a call to the OrderLineService might return some basic order information as well, without the OrderLineService implementation having to make a call on the OrderService.
Why is an enterprise-level point of view important for SOA?
Returning to the “real world” analogy of a car, if you were designing a unique, custom-made, one-off car, you would take a different attitude to the form of its individual parts than if you were designing a series of different models of cars for a car manufacturer. Again, this is primarily because you would want to be able to reuse the same parts across multiple models of cars. We can see that this only becomes important because of the scale of the proposition –- single car versus range of cars.
In a similar way, you need to apply a different mindset to designing multiple service-oriented (SO) solutions across the enterprise as opposed to designing a single SO solution. This mindset is what we’re referring to when we talk about “taking an enterprise-level point of view”. It is important that the form given to individual service-oriented parts should allow them to be used across multiple SO solutions across the enterprise.
Below, we present four different aspects to our enterprise-level point of view: creating a business model context, standardizing architectural patterns, standardizing implementation frameworks and runtime platforms, and adopting asset-based development principles.
In Part 2 of this series we introduced Component Business Modeling (CBM). To recap: An enterprise-wide business model provides a very important context within which to frame our IT systems. IBM has a strategic method called Component Business Modeling (CBM) that produces a business architecture that divides the enterprise as a whole into a number of business components.
It produces a business model that describes the enterprise as a set of business components, where each business component is a part of the enterprise that has the potential to operate autonomously, for example, as a separate company, or as part of another company.
The detail of a business component is described in terms of:
- People: The business roles that people play in the context of the business component.
- Process: The business processes that the business component is involved in.
- Technology: The IT systems that are owned by the business component.
Figure 3 repeats the business architecture map that we showed in Part 2 of the series. Note that the business components are organized by level of responsibility (rows) and business domain (columns).
Figure 3. Business components in a business architecture map
The sort of business architecture described by a business model like this provides an invaluable context for our SO systems. The set of IT systems that exist or will exist in the enterprise can be placed in the context of the business component(s) that they support. Furthermore, the business processes for the business component should annotate exactly where in these business processes the SO systems are used.
This is an important mechanism for relating the software that IT is responsible for with the business that it supports. Considering these systems in an enterprise-wide business model context will prevent functional overlap between IT systems by looking at these systems within the context of the business components they support.
Another hugely important (and we can by no means overemphasize its importance!) thing
to model in the business domain is the business information. In other words, for each of
the business domains, what are the important “things” in the business that are part of
the everyday dealings of the people in that domain? These things can be a combination of
physical things such as products or logical things such as
orders. Having a clear view of the business information and
how it is structured across the enterprise (albeit in a logical way; for example, we’re not talking about database tables here) is very important for the IT architects responsible for identifying software services across the organization.
We recommend a tutorial available on developerWorks, Model Service-Oriented Architectures with Rational Software Architect: Part 2. Modeling the business domain (please see the Resources section for a link) which provides a detailed treatment of domain modeling. Later tutorials in this series will explain exactly how to go about deriving parts in your architecture from this domain model.
Standardize architectural patterns
Probably one of the most important ways of ensuring that the parts specified for your solutions are generally reusable across solutions is to apply a consistent set of architectural patterns across the enterprise. Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. They express a fundamental organization schema for software. In other words, they provide rules for creating the form of your SO systems and the service oriented parts from which they are assembled.
It is important that the same patterns are used across the enterprise. This will increase the likelihood that parts created for one SO system will be able to at a later date fit together with (be assembled with) other parts to form new service-oriented solutions. In this way the total percentage of software in the enterprise that is service oriented can grow incrementally over time without having to fundamentally re-architect or refactor as you go.
An example set of architectural patterns for designing SOA solutions can be found in Chapter 4 of the IBM Redbook, Building SOA Solutions using the Rational SDP, in the section ‘Reusing architecture and design experience’ (please see the Resources section for a link). These patterns codify a set of rules used to factor the functionality in a solution into a set of parts. Specific attention is given to factoring functionality into executable processes, composite services, and atomic services.
Standardize programming models
Consistent application of architectural patterns across the enterprise will only get you half-way towards the goal of creating generally reusable service-oriented parts. You can apply the same architectural patterns to create two service providers, which are then unable to be assembled into the same service-oriented solution because of incompatibilities in integration framework or runtime platform.
A standardized programming model should be introduced to avoid technology incompatibility problems. Note that we’re not talking about having to standardize on a programming language (such as Java™), an implementation framework (such as J2EE), or on binding mechanisms (such as SOAP). Instead we’re talking about a programming model such as one based on the SCA (Service Component Architecture) and SDO (Service Data Objects) standards, which focus on the integration points between service components. SCA and SDO have been specifically designed to allow for interoperability between service components in a way in which the service bindings and service implementations can be changed over time without changing the basic structure of the service component.
We provide a link to more information on SCA and SDO in the Resources section.
Creating generally reusable service-oriented parts provides maximum benefit when these parts are reused. However, just creating them doesn’t guarantee their reuse. What is required is the adoption of an organizational asset governance, and workflows that support assets through their lifecycles: specification, production, and consumption. A view of these key workflows is shown in figure 4.
Figure 4. Asset-based development activities
Service-oriented parts should be specified, produced, managed and consumed as assets. Once produced, they should be published into an asset repository along with searchable metadata that will allow these assets to be found and consumed. This practice needs to be adopted on an enterprise scale (organizational asset governance) to provide maximum benefit.
The next part in this series, Part 4, will introduce an important IBM product that supports asset lifecycles: IBM Rational® Asset Manager (RAM).
In this article you found out about what makes a solution service-oriented, and what this actually means when you look inside. You learnt about the different types of parts in a Service-Oriented Architecture. Finally you learnt more about four different aspects to taking an enterprise view to SOA: creating a business model context, standardizing architectural patterns, standardizing programming models, and adopting asset-based development principles.
In the next article we will explore the notion of system integration, and what that means in the context of SOA. In doing so we’ll learn that the concepts of integration and reuse are very closely linked in SOA –- and as a result we’ll describe some useful patterns for ensuring that we take the correct approach to reuse.
Learn
- The Rational Method Composer plug-in for SOA Governance provides us with the definition for service we've used.
- Wikipedia provides a useful definition for architectural pattern as it relates to computer science.
- The Building SOA Solutions using the Rational Software Development Platform Redbook provides a lot of further detail on modelling SOAs.
- The Model Service-Oriented Architectures with Rational Software Architect, Part 2: Modeling the business domain tutorial provides useful hands-on guidance for business domain modeling.
- Consult the OSOA Web site for further useful information on the SCA (Service Component Architecture) and SDO (Service Data Object) collaboration.
- Download the Asset-Based Development and Asset Governance Rational Method Composer (RMC) plug-ins to learn more about these topics.
- The Architecture area on developerWorks will provide you with further resources you need to advance your skills in the architecture arena.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2 ®, Lotus®, Rational®, Tivoli®, and WebSphere®,
Discuss
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.
Gregory Hodgkinson is a lead consultant at Prolifics (www.prolifics.com). Previous to that he was a founder, director, and the SOA lead at the company 7irene. He has 10 years of experience in software architecture, initially specializing in the field of component-based development (CBD), then moving seamlessly into service-oriented architecture (SOA). His extended area of expertise is the software development process, and he assists Prolifics and IBM customers in adopting RUP framework-based agile development processes and SOA methods. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods at both IBM (Rational and WebSphere) and other events and has also co-authored a Redbook on SOA solutions.
Bertrand Portier, IT Architect, is from IBM Software Group SOA Advanced Technologies (ex EIS). He works in the field on strategic SOA transformation projects and, based on these experiences, works with IBM Software Group development teams. His background is in J2EE and Web services, and he is now heavily involved with asset-based and model-driven development.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
