A service is a piece of code that can exist independently. It's usually identified independently for composition with other services and is called independently for execution. Therefore, it's not essential for a service to be a Web service, which is only one type of service. Web services are among the most commonly used forms of application services because there are many tools that exist to build them, and they satisfy all the properties of a service. Common Object Request Broker Architecture (CORBA) or Component Object Model (COM) component code can also be designated as a service depending on the scenario and their functionality. Furthermore, multiple pieces of code can exist for the same service depending on the requirements, such as concurrency, scalability, message exchange patterns, and response time. Services can be formed at all layers of the architecture: the infrastructure layer, UI layer, and data layer. Many people think that services should be used only in the middle tier to fulfill the business functionality, but that's not necessarily the case.
Identify your SOA business drivers
Every scenario has its own business drivers for why an SOA should be adopted. Don't start SOA development for its own sake; start it for some specific business gains for which you can apply an SOA as a solution. You should identify these business drivers clearly for each instance.
SOA requirements should also be identified from the business drivers. The different requirements aren't always provided by a single product or even a suite of products from a single vendor. Most of the product vendors cater to a limited set of requirements and might not be suited for each scenario. Therefore, the selection of the product vendors for your SOA solution should be determined by the needs of the SOA solution. Also, don't let a product vendor drive your SOA initiative. Potential differences between your situation and the expertise offered by the vendor is likely to cause confusion and maybe even failure. This might sound elementary, but the industry is inundated with cases of SOA failure for this reason.
The rest of this article covers the variety of possible SOA requirements and what to focus on to meet these requirements rather than choosing a product from a vendor without concentrating on what features it can provide. Think of the SOA features as patterns instead of products. This helps you focus on the product features you need to suit your solution rather than being dazzled by the product features themselves. There are a variety of features necessary for an effective SOA. Avoid letting the features available in known products drive your SOA initiative. This can also lead to failure.
A service contract is an important aspect that helps determine an initiative's success. You must identify the elements that should be represented in the service contract for your SOA initiative, as different SOA initiatives need different attributes to ensure success. The service contract is the foundation of your SOA initiative, so choose the attributes carefully. Some of the important information you might find in a service contract are described below in the next few subsections.
The description of a service is designated by the detailed explanation of the functionality of the service. This is generally not a machine-consumable item; it's usually a human-consumable item.
A service description is useful when a consumer is looking at the service catalog to identify the right service to call for a particular scenario. Note that this is not used for dynamic binding of the services, but for static binding. Therefore, the description should attempt to describe aspects about the service that can't be determined from the input and output parameters of the service. For example, the description might cover all the side effects that the service might have. It might also mention information that's relevant for it to be used in a transaction.
The service pedigree helps to determine the importance of the service in context of all the services provided. In other words, the service pedigree identifies services based on how core they are to the SOA solution. This might dictate the deployment strategy for the service. The service pedigree can also indicate whether a service is currently in its testing phase or production phase.
The security mechanism is crucial in identifying the access mechanism for the service. This might help in deciding which infrastructure services you should use to bind and consume this service.
Message Exchange Pattern (MEP)
The Message Exchange Pattern of a service is a communication pattern used by the service provider and service consumer for their communication. A service can have many types of MEPs: one-way, publish-subscribe, or request-response. This can be important while using one protocol versus another. For example, in using the HL7 protocol, HL7V2.X can work with one-way messages with acknowledgement alone while HL7V3.0 mandates the use of a request-response type of MEP.
It's important to determine how many calls of a particular service are expected to be executed concurrently. The implementation has to take care of this, and the user of the service has to agree with the parameter specified so that the service doesn't behave erroneously.
Response time is critical when this service is used in a composition scenario and some service level agreements (SLAs) have to be met for the resulting service. It's also useful when used in isolation for the SLA. Response time might be derived from the nonfunctional requirements (NFRs) specified for the functionality of the service.
The payment model is essential when an SOA is used to cater to Software as a Service (SaaS) scenarios or scenarios in which usage of the service is going to be charged to the consumer of the service. You can also use the payment model to measure forms of cost other than the monetary costs.
The ESB is considered to be the backbone of an SOA initiative. However, the needs from the ESB change drastically from one scenario to another. Therefore, it's best to identify your need and go for the ESB that suits your need. In some scenarios, a piece of hardware can suffice for the ESB, and many successful SOA initiatives use them. So as mentioned earlier, you should think of the ESB as a pattern to fulfill your SOA needs. Some of the important aspects you might need to look for in an ESB product are described below.
Normally, the consumer of a service isn't interested in the location of the provider. This lets you change the service location depending on the business need without having to break the system. This is generally essential for the ESB and is mostly an essential aspect that an ESB product should support.
It's often essential to find out whether an ESB product supports the usage of a registry service product in conjunction with itself. This provides for needs like identifying the service to bind with when building an SOA or even location independence as mentioned earlier. Sometimes while connecting with a partner’s systems, you need to have a federated registry service to be able to locate the service and its binding details. The ESB should be able to cater to the level of sophistication you need for your SOA initiative. In some cases, when going across various organizations, you might need to create different namespaces for the services to avoid conflict with names. This can be largely solved by using ESB namespace registry.
More often than not, an ESB is expected to convert the protocols at various layers to ease communication between the provider and the consumer. For example, the provider might provide the service using HTTP, whereas the consumer might expect the data in SOAP format. Another example is the need to convert application layer protocols from something like HL7V2.X to HL7V3.0. This might not be an essential feature, but it's one of the most desirable features because this makes the same services consumable in different scenarios. Many times even the specific protocols the ESB supports and interoperates with are important to establish whether a particular product can be used in a particular scenario.
MEPs are essential, because an ESB is typically able to host almost any kind of MEP. Most often in an SOA initiative, support for more than one type of MEP is mandatory. When integrating various applications, some may need to work in the event-processing mode, which might mandate support for a publish-subscribe style of message exchange. At the same time, other applications might need to work in request-response mode to handle other requirements.
Your SOA initiative might be built on different types of technologies, such as proprietary technology, Java™ 2 Platform, enterprise Edition (J2EE)-based technology, or even Microsoft® .NET based technology. Another way of categorizing technologies can be Web services, CORBA, or COM. Or you can categorize them based on whether they're Enterprise JavaBeans (EJB)-based, container-based, or Spring framework-based.
The ESB should be able to interoperate across the services using all these technologies. As mentioned earlier, this might not mean working with J2EE- and .NET-based Web services alone because your services can be more than just Web services. So it's crucial to identify the service technology needs and product's technology interoperability capability while identifying the best ESB product for your scenario.
Depending on your SOA initiative, you might want thousands or millions of services to be processed by your ESB. So it's essential to find the ESB product that most uniquely caters to your SOA initiative. Often the ESB is such a heavy component that it might introduce a lot of overhead, limiting the amount of scalability it can support. You have to clearly identify whether the ESB scalability can cater to the scenario in which the product would be used.
Your ESB should not introduce more than a necessary response-time overhead. You should carefully study and evaluate this before choosing the ESB, as this is closely related to the ESB's scalability requirements.
Unless your SOA initiative has some requirement that forces you to lock with one vendor, you should have a thought process incorporated into your ESB selection process allowing you to change vendor when your SOA requirements change. Your SOA solution should be extendable when there's a need for it. It helps to think about the future while identifying the needs of the ESB product, because the ESB serves as the backbone for your architecture. The success and failure of the SOA initiative depends a lot on the selection of the ESB product, if not solely on it.
Policy compliance is an essential part of any enterprise. All the enterprise architectures based on your SOA need to support adequate mechanisms to ensure policy compliance and early detection of violations. Sometimes policy is confused with security and testability of an SOA initiative. Though certain aspects of security and testability can be modeled as policies, not all can. Furthermore, policies generally mean corporate policies, which are very different from the security and testability needs. Also, not all corporate policies can be encoded as metadata. Therefore, like all the other requirements, your governance requirements should also be addressed based on need.
Policies are generally declarative specifications for the rules and regulations that a system needs to adhere to. You can also think of such rules as the characteristics of the system. Policies of a system can describe the system's process, functionality, performance, or robustness. It can also include the specifics of the system's security at times. Though some specifics of security can be part of the policy, not all the security requirements need to be part of the policy. Sometimes it might be more effective to code the security of a system through policies, but policies are generally different from security-specific and testing-specific policies.
A typical governance product should:
- Allow configuration of policies that might be needed for compliance to a particular standard, such as Sarbanes-Oxley (SOX) or the Federal Financial Institutions Examination Council (FFIEC).
- Allow monitoring of policy violations and logging them when such cases are noted. It should also allow logging of enough detail of the violations that these cases can be corrected in the future.
- Allow automatic provisioning of the policies, including changes to the policies.
IBM® has a range of products in governance, including:
- IBM WebSphere® Business Monitor: Boosts productivity with new visualization features that improve the dashboard experience for business users. This is one of the advanced features of governance that can lead a business into innovations it couldn't envisage without the tool.
- IBM Tivoli® Service Level Advisor: Provides predictive service-level management capabilities. This product belongs to the IBM Tivoli IT Service Management portfolio of products, which provides intelligent management software to help businesses increase operational agility by aligning IT operations to business priorities.
- IBM Tivoli Change and Configuration Management Database: Helps to align the ongoing management of IT infrastructure with business priorities by integrating, automating, and optimizing data, workflows, and policies.
- IBM Rational® Asset Manager: Helps to create, modify, govern, find, and reuse any type of development assets, including SOA and systems development assets.
- IBM Rational Portfolio Manager: Allows monitoring of process and functionality and helps businesses align their IT and system investments with business priorities.
Other than the IBM products listed above, AmberPoint is also a well-known governance product.
Generally, the governance product should also be able to support the business agility needs and monitoring needs of your SOA initiative. The extent of your monitoring ability and reporting can also be limited by your choice of governance product. Thus, carefully choosing your governance product is essential to the success of your SOA initiative.
Many times architects decide on building the security infrastructure from scratch. While it might be a good idea in some cases, it's not always. The choice of your security solution depends on the following needs.
This is related to whether your SOA initiative needs to reach across various trust boundaries, either within the same enterprise or across various partner organizations. Does the trustworthiness change among users in various departments of your organization, or does it only change when it concerns users across different organizations?
This is essential when you have a variety of servers that need to talk to one another. In this case, you need to establish a seamless security framework. One example of this is providing an access mechanism for partner organizations within one organization. Because the employees and roles of the partner organizations are controlled by the partner organization, it's best to keep the federated security model.
When multiple applications are available with different authentication mechanisms, SSO becomes essential. SSO can also be useful for seamlessly integrating applications when context setting needs to be performed for applications where users log in via the SSO mechanism.
Authentication and authorization
Authentication and authorization mechanisms are also possible in multiple ways. Some SOA initiatives might need to mix and match multiple authentication and authorization mechanisms. Think this through carefully before choosing the security solution.
Testability is important for an SOA because testing sometimes has to be performed on production systems. Only production systems can bring in the test conditions for the concurrency and scalability requirements. Also, all upgrades have to be provided in the production systems only. So you must identify the infrastructure that can meet all the testability requirements of your SOA initiative. Without the testability requirements, the full SOA initiative might collapse, because the system would cease to work properly.
What do you gain from thinking along these lines? You can achieve a lot by using this approach for your SOA initiative, as described next.
Your SOA initiative's success should depend on the business benefits its built around, not on a single-vendor product suite used to implement it. You choose the vendor according to your SOA needs, which lets you change the vendor as your SOA needs change.
Protect your SOA solution from mergers and acquisitions
Many SOA vendors merge with others depending on their business focus, and many get acquired by other vendors for the same reasons. The business focus of SOA vendors is almost always different from your SOA initiative's business focus, so if you're heavily dependent on a vendor that goes through a merger or acquisition, it might pose a problem for your SOA initiative. The methodology described in this article can help you deal with these situations.
Focus on the needs of the solution
Some vendors' product features might be too limited to meet your SOA needs. This can lead to your SOA product becoming part of the problem set rather than part of the solution set—adding yet another issue for which you need a solution. Follow the approach outlined in this article to avoid this pitfall.
Product vendors often provide a lot of features you don't need in your SOA solution. Use the approach outlined here to identify the right SOA product for your needs so that you invest only what's required in your SOA solution and so that you realize an early and better return on your investment.
When starting an SOA initiative, remember the most critical takeaway from this article: Focus closely on the expected results. This helps you avoid getting distracted by the deluge of products, vendors, and technologies in the industry and increases your chances of success considerably.
Learn
- Get details on how to use
Cogito.
- The
SOA and Web services zone
on IBM developerWorks hosts hundreds of informative articles and
introductory, intermediate, and advanced tutorials on how to develop Web
services applications.
- Play in the
IBM SOA Sandbox!
Increase your SOA skills through practical, hands-on experience with the
IBM SOA entry points.
- The
IBM SOA Web site
offers an overview of SOA and how IBM can help you get there.
- Stay current with
developerWorks technical events and webcasts.
- Browse for books on these and other
technical topics at the
Safari bookstore.
- Check out a quick
Web services on demand demo.
Get products and technologies
- Download a free
trial version of
WebSphere Application Server V6.0.
- Get
Cogito and
the Linux kernel source.
- Order the
no-charge SEK for Linux,
a two-DVD set containing the latest IBM trial software for Linux from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
- Participate in the discussion forum.
- Visit
KernelNewbies.org for lots of
resources for people who are new to hacking the kernel.
- Get involved in the developerWorks
community by participating in
developerWorks blogs.
Shantanu has extensive experience in the design, architecture, and system integration of software applications for the retail and healthcare industries. He also has experience developing networking software (SNMP-based and TCP/IP stack), security software, File Systems (India's first supercomputer), and Real Time Software (for the Indian Missile Program). He has several article publications to his credit and he is a reviewer for ACM Computing Surveys. Shantanu is currently working as technology head for Siemens Information Systems Limited in Bangalore and carries the designation of Chief Consultant.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
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
