Level: Introductory Editorial staff (dwinfo@us.ibm.com), developerWorks, IBM
21 Feb 2006 IBM luminaries provide personal insight into advancing the practice of IT architecture to help you become a better architect.
Introduction: Turning SOA theory into practice
You may be convinced that Service-Oriented Architecture (SOA) is right for your IT system -- or you may not be. But let’s say for the sake of argument that you have decided to start the design and implementation of your own SOA system. The first question you will probably ask yourself is, "Where do I begin?"
SOA methodologists inside and out of IBM have defined four levels of SOA adoption, the first of which is:
- Implement individual Web services
You need to create individual software-based services -- tasks or sets of tasks, written as software components, that provide services to other applications over the network through published and discoverable interfaces. These services can be software-based tasks you develop from scratch, or they can be tasks you need to convert to services from existing non-SOA applications. (I’d suggest that you read about all four levels of Service-oriented architecture adoption, just to be sure you are in going in the right direction.)
Sounds easy in theory, right? All you have to do is write components that contain these services or you can simply "componentize" your existing large applications according to defined SOA interfaces. "Easier said than done," you might be thinking. As a colleague of mine from Rational® software once said, "In theory, theory and practice are the same, but in practice, they aren't."
As easy as level 1 of SOA adoption sounds, you're probably still left asking questions like the following:
- In practical terms, how do I really know how to get started with SOA?
- How do I know what will make a good service?
- Can I use code that I have already written, or do I need to start all over?
- What do I do with my existing code to turn it into a service?
To help you answer these important SOA adoption questions, we asked our IBM panel of architecture experts the following question:
If I'm just starting to adopt SOA, what types of software features are the best candidates for implementation as services, and what is the first step to starting the implementation process?
As usual, the experts have a lot to say, and we hope their ideas help you turn SOA theory into practice. Let us know if you have additional questions or comments on this topic by sending me an e-mail at pdreyfus@us.ibm.com and contributing to the
IT architecture discussion forum. We'll do the best we can to help.
Paul Dreyfus
developerWorks SOA and Web services
pdreyfus@us.ibm.com
p.s. The developerWorks SOA zone at
www.ibm.com/developer/soa provides you with detailed guidance about this and other important topics in SOA adoption. In addition to reading our panelists' ideas, take a look at the New to SOA, as well as the SOATechnical Library.
Service-oriented modeling and architecture
The process of determining which services to expose in your SOA is called service identification. Find out more about this process, which consists of three complementary techniques, and is described in the developerWorks article titled, "Service-oriented modeling and architecture (SOMA) methodology."
First, you need to clearly and carefully define the scope for the transformation: Why are you service-enabling in the first place? After you have that scope, you apply goal-service modeling, process decomposition, and existing asset analysis to arrive at a portfolio of candidate services. These categorized sets of candidate services are part of your service model.
During the next phase of your work, you will specify and design each individual service. You need to make service exposure decisions: From the comparatively large amount of services, which ones do I actually expose? The answer to that comes when you apply a set of gating criteria called service litmus tests to your initial list of candidate services. These include tests to measure the "goodness" or appropriateness of a service based, for example, on its alignment with business needs.
This filtered list contains the services that you should start designing and happens in the specification phase of SOMA. During this step, many of the detailed characteristics of a service are specified in detail which will feed the implementation process.
The implementation is done in the realization phase of the SOMA process, where services are provisioned, sourced, or realized through a set of architectural and sourcing decisions. The results of this part of the process are statements like the following:
- I will use this package to implement this component realizing this service.
- I will build this one from scratch.
- I will wrap these two legacy transactions.
- I'll realize the third service or some of its operations using those transactions.
Points of intersection
An anti-pattern for identifying services -- whether they're pure Web services or more generic kinds of services -- is to look at your existing system and wrap a service around the major interfaces you've already got.
The reason that this is usually a Very Bad Idea is that these interfaces -- which represent the edges of the fault lines of a system -- are probably pretty ugly, having bubbled up from the primordial ooze over years of use, and are thus manifest accidentally, not intentionally. This is also an example of a technology-first solution.
A better pattern for identifying good services involves defining crisp abstractions. Throw some essential usage scenarios against your system. Focus on the points of intersection where the success of multiple scenarios all depend on a narrow set of software. Within striking distance of those intersects, you will find the place to dig for services, at the granularity suggested by the nature of those scenarios. Whether you wrap these services as pure Web services or something else requires yet another decision-making path, however.
Various entry points
An SOA strategy should not be a big-bang replacement of an existing IT environment; rather, it should be a progressive and evolutionary roadmap. An overall replacement is impossible because enterprises typically have complex, operational environments. Therefore, the roadmap should reflect an iterative process.
Based on my experience with several client engagements, there is no "one-size-fits-all," perfect approach to building an SOA solution. However, there are various entry points for adopting SOA. They can be broadly categorized as the following:
Initial adoption. This is typically for the risk averse who want to just dip their toes into this space. The architectural effort is typically constrained to a scaffolded environment, and the exercises range from proofs-of-concept to early pilots. Once the initial effort demonstrates business and technical value, the spectrum is expanded to a wider adoption.
Line-of-business adoption. A progressive line-of-business (LOB) executive with a flair for technology might recognize the value of SOA. This process begins by identifying the agility/flexibility requirements for a set of business processes and functions, defining a solution outline with associated critical success factors and result metrics, and finally, implementing the solution architecture. Service modeling and analysis techniques are sometimes used to formalize the service identification, specification, and realization steps. IBM consultants prefer to use the SOMA methodology for this process.
Enterprise adoption. This happens when an enlightened CIO decides to embark on a broad and incremental transformation of the entire enterprise. This typically involves business analysis and modeling to create a prioritized enterprise component map. To draw this map, IBM consultants use Component Business Modeling (CBM) methodology. Each business component in the map that needs IT refactoring is now decomposed using service modeling techniques (such as SOMA), leading to the eventual realization of reusable, value-driven services:
 | | Enterprise adoption happens when an enlightened CIO decides to embark on a broad and incremental transformation of the entire enterprise. |
|
The book, SOA Compass, Business Value, Planning, and Enterprise Roadmap, which I coauthored, navigates you through the essential elements of SOA adoption -- the tools, techniques, and approaches. The article, "SOA Project Planning Aspects," (WebSphere® Journal; January 2006) gives a brief snapshot of the book.
Connect organizations: Look for coarse-grained services
This is a good question. There are many types of services, which others have identified. I will confine myself to answering the questions regarding "best candidates" and "first steps." I will also slightly change the questions. SOA, because of the A, is an architectural model that has many benefits. Many other articles explain the benefits, and I won't repeat them here.
Web services are a set of standards that enable interoperability for SOA. WS-Interop provides runtime interoperability and WSDL/WS-Policy provides interoperability between tools. For example, WS-Interop supports .NET and WebSphere runtime communication. Programmers exchange WSDL/WS-Policy between Rational Application Developer/WebSphere Integration Developer and Visual Studio to develop the collaborating applications. Vendors support optimizations, for example SOAP (an XML-based messaging protocol) over JMS/MQ and Java™ interfaces for SCA.
| | Starting with coarse-grained services ensures that the first foray into Web services is unlikely to experience performance or reliability problems. |
|
Having said this, I think the best candidates are:
- Services that are published by one organization and consumed by another. That is, start with SOA to bridge organization boundaries.
- Very coarse-grained services. The programmers should look for services, even if remote procedure calls, that look like document exchanges with significant processing on the sender and caller.
Implementing services of the first type typically solves a pressing business need; for example, integration between enterprises or within an enterprise between LOBs. Web services that realize SOA provide a common model for integrating disparate infrastructures and application interfaces. This is a good use of Web services and often solves a pressing business problem while allowing autonomy within the different organizations.
Starting with coarse-grained services ensures that the first foray into Web services is unlikely to experience performance or reliability problems. This approach also enables some of the benefits of SOA, such as loose coupling, message routing, and message audit.
You may already be using SOA
If you are just starting to adopt SOA, perhaps the best thing to do first is to use the IBM SOA Self Assessment tool, available at no charge. Based on the results of the assessment, you can determine your current level of maturity and gain a better understanding of the next steps you can take to pursue SOA solutions. You may also want to read the "SOA compliance" white paper, which describes the initial steps that you can take in what will be a long journey.
After reviewing all the material, you might be pleasantly surprised to find you have been using SOA for a while. For example, Rational Application Developer has had Web services support since Version 4. (The current product is Version 6). You may already have been using its wizards to turn simple Java objects, stored procedures, SQL commands, and stateless session beans into services with a Web Services Description Language (WSDL) interface. The new add-ons such as WebSphere Integration Developer allow you to assemble these services into business processes using standards, such as Business Process Execution Language (BPEL).
A combination of approaches
Service identification obviously occurs toward the beginning of the SOA life-cycle and many times lays the groundwork for the success of the entire project. Service identification normally is a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modeling. The top-down view often provides the specification for the business services defined by the business use cases. This consists of the decomposition of the existing domain into its functional areas and subsystems using the business use cases.
In the bottom-up approach, existing systems are analyzed and selected as viable candidates for implementation. For example, one might analyze the existing functionality of an IBM CICS® legacy environment for potential SOA transformation. Determining whether the presentation components and business components are tightly coupled determine whether the applications can be easily service enabled.
| | Service identification normally is a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modeling. |
|
The middle-out approach consists of goal-service modeling to unearth services not really captured in the use cases (top-down) or existing system (bottom-up) approach. Services composed of fine-grained components and services are the best candidates for implementation as services. Once services are identified, you can begin the service categorization and classification phase. This step will definitely help alleviate the service proliferation problem when deploying thousands of fine-grain components that tend to cause performance, scalability, and management issues when proper governance is not applied.
Commonly used services
A "meet-in-the-middle" approach works really well to ensure fewer disconnects. Do a top-down business process analysis to identify the business processes at the highest levels, and break them down into more granular services. At the same time, take a bottom-up look at the applications and infrastructure that already exist in the organization to best enable reuse.
So among the first services to consider are those most commonly used across multiple applications -- you may find them implemented in multiple ways in different applications! This enables quick cost saving and shows immediate value. One of the key aspects to consider is designing the interfaces well in order to make the service effectively reusable. Also, you will want to weigh the costs and benefits of implementing a new application or reusing an existing one by wrapping it in the appropriate interfaces.
Implement infrastructure services first
There are three types of services that can be exposed across the enterprise as shared or reusable services, as follows:
- Common infrastructure services: Services that are necessary for all applications or systems at an operational level. By operational, I mean tasks that are necessary to support the runtime environment of the system or application itself -- such as directory/LDAP services, security services, discovery services, and service management.
- Common enterprise services: Services that can be provided across the enterprise as building blocks to compose new services or application function, such as collaboration services, messaging services, and content services.
- Domain-specific services: Services that provide a specific business function. Domain services are usually an extension of existing business applications across the enterprise, such as addCustomer, getEmployee, or submitOrder. I recommend that an enterprise agree upon an initial set of domain services that are supported by the common infrastructure and enterprise services.
With this distinction in mind, the first service type to be implemented would be infrastructure services followed by those common enterprise services needed to support the initial domain services. Domain services could then be developed by leveraging the infrastructure and common enterprise services as building blocks to extend the existing business applications. Selecting the right domain services to compose is a matter of evaluating potential reuse and composability across the IT portfolio.
Data encapsulation, legacy systems
One answer you're likely to hear from us is to use the IBM SOA Self Assessment tool, which is really more about determining how ready your organization is for SOA. Another standard answer for a good place to get some quick services ideas is the white paper, "Five SOA projects that can pay for themselves in six months." Those notwithstanding, let's look at the kind of technical situations that tend to lend themselves to becoming services: encapsulation of data and legacy functionality.
Services tend to be a good way to access behavior that is highly data-dependent. The service encapsulates the data, simplifies the client interaction, and can make the data and behavior remotely accessible, if necessary -- especially helpful when the data is difficult to duplicate because it changes rapidly or is highly sensitive. Credit card verification is a good example of this; a service can validate charges while keeping the credit card database secure. Another good example is a stock quote service, where current data changes frequently and historical data is very voluminous.
Services can also be a good way to wrap legacy systems to make their functionality more easily accessible and reusable. Rather than duplicate a piece of functionality in a new application, the application can delegate to an existing application that already has the functionality. If the existing application does not make the functionality easy to invoke in this way, wrap it with code that exposes the functionality as a service. Let's say your mainframe order-processing system already knows the status of an order; to expose that on your Web site, implement that query as a service that uses the mainframe. Likewise, if that system provides a way to create, modify, or cancel an order, expose those tasks as services that the Web site can also use.
| | Let's say your mainframe order-processing system already knows the status of an order; to expose that on your Web site, implement that query as a service that uses the mainframe. |
|
What should the services for wrapping a database or mainframe look like? They should look like your use cases. By use cases, I mean the answer to the question, How do clients plan to use the data or functionality? Focus on what clients want the service to do, not how it'll be implemented using the database or mainframe. Focusing on use cases make sure that the services are not just technically possible, but that they're actually useful.
About the experts
Ali Arsanjani
Ali Arsanjani, Ph.D., is Chief Architect for the SOA and Web Services Center of Excellence within IBM Global Services, specializing in harvesting and developing best practices for the modeling, analysis, design and implementation of SOA and Web services. He leads the internal IBM worldwide SOA and Web Services Community of Practice (4000 members) and is the principal author of the (Service-Oriented Modeling and Architecture) SOMA method for SOA. He is currently focusing on SOA Tooling with support for Modeling (SOMA), Assessments, Strategy and Planning, Governance, Architecture and Realization and their practical application to engagements inside and outside of IBM. Read his blog, Best Practices in Service-Oriented Architecture.
Grady Booch
Grady is an IBM Fellow who has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable. Grady is the author of six best-selling books and has published several hundred articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. Read his blog, Software architecture, software engineering, and Renaissance Jazz.
Sanjay Bose
Sanjay Bose works for the IBM Software Strategy division and leads the Enterprise Integration Design Center to identify IBM Software portfolio requirements, and develops solution components and assets by engaging enterprise clients and IBM Software product development laboratories. He has more than 12 years of IT industry experience, primarily focused on creating product architecture and design, articulating technical strategy, and designing enterprise application systems using distributed technologies. His areas of expertise include SOA, Enterprise Service Bus (ESB), Web services, Java™ 2 Platform, Enterprise Edition (J2EE), and e-business technologies. He has coauthored the book, SOA Compass, and has published articles on IBM developerWorks and Systems Journal. He lives and works in Pittsburgh, Pennsylvania, and his spare time is spent with philosophical ramblings, books, movies and his Sony PlayStation. Read his blog, SOA, ESB, and beyond.
Donald F. Ferguson
Donald Ferguson is one of 53 IBM Fellows (IBM's highest technical position) in IBM's 200,000 employee technical team. Don is also Chief Architect for IBM Software Group. Don chairs the SWG Architecture Board, which oversees the architecture and integration of WebSphere, DB2®, Lotus®, Tivoli®, and Rational® products. Don was the original Chief Architect for the WebSphere family of products. He joined IBM Research in 1985. His interests include raising and playing with his children, distributed systems, simplifying application development, systems management, Web services, transaction processing, performance and karate. Read his blog, Middleware and tools.
Christina Lau
Christina Lau is an architect on the On Demand Development team. Her current projects include creating Pattern Solutions using Rational Software Architect and piloting business innovation and optimization functions. Christina is a Senior Technical Staff Member and a member of the IBM Academy of Technology. She is also a coauthor of a new book: Introduction to IBM Rational Application Developer.
Calvin Lawrence
Calvin Lawrence is an executive architect on the IBM Software Group Emerging Technology team. His responsibilities include advancing strategic IBM architectures, technologies and products in support of key strategic initiatives and ensuring the success of customer implementations using IBM technologies. He is former Chair of IBM Software Group Worldwide Technical Leadership Council.
Sridhar Sudarsan
A staff member of the IBM Austin Center for Advanced Studies, Sridhar Sudarsan is a senior IT architect on the IBM Software Services for WebSphere team. Currently he is working on model-driven-architecture-based solutions for the banking industry.
Andras Robert Szakal
Andras Robert Szakal is Chief Architect for the IBM Federal Software Group and is an IBM Distinguished Engineer and Senior Certified IT Architect. He is also serves on The Open Group Board of Directors.
Bobby Woolf
Bobby Woolf is a member of IBM Software Services for WebSphere, consultants who help customers achieve success with WebSphere products. He is a coauthor of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion. Read more at Bobby's blog on developerWorks.
Resources
About the author
Rate this page
| 
