http://www.zdnetasia.com/insight/business/0,39044868,61952144,00.htm
10+ things you should know about SOA
By Brian Schaffner, Special to ZDNet Asia
Friday , September 22 2006 10:54 AM
#1: SOA is not a purely technical approach
It's important to understand that service oriented architecture, when practiced successfully, is not just a technology architecture. The SOA paradigm is really about modeling the business processes, which are not always supported directly by technology components. Ultimately, services may be implemented by technology components, but the business processes themselves are more important than the services that support them.
SOA as a technology is an enabler. The technology doesn't provide direct value. It's not necessarily less expensive to develop services on a line-of-code basis as compared to EJBs or .NET components. Instead, SOA technology should be seen as an enabler of other benefits, such as improved and broader reuse, better responsiveness to changing business processes, and better alignment with business processes.
#2: SOA doesn't have to mean Web services
A lot of technologists have trouble understanding that SOA doesn't necessarily mean Web services. Web services can definitely be part of an SOA strategy but are not required. Service definitions can be based on other standard protocols besides HTTP. It's more important to focus on the needs of the business processes and the services than on the technology that's used to implement them. Usually, the context of the service will help determine how it's implemented.
For example, for services that involve critical business transactions, using a Web service may be detrimental since guaranteeing transactionality across a SOAP/HTTP protocol is difficult. Also, many services may need to operate asynchronously. In these cases, messaging systems based on queues and channels may be a better candidate to implement the service transport. Payloads and interfaces can, of course, still be defined using XML.
#3: SOA can be built using existing infrastructure
Many organizations are surprised to find that they can build SOA using existing infrastructure. For example, both the .NET and J2EE platforms provide support for developing Web services, for parsing and generating XML, and for communicating with messaging systems such as MSMQ and JMS.
What's usually missing in the SOA stack is the process management or automation layer. However, many companies have existing investments in enterprise application integration (EAI) tools. Many of the EAI tools can function as the process automation and management layer, which can access services from existing applications or those built on .NET and J2EE platforms.
#4: SOA is an evolutionary approach (from components, objects, etc....)
Service oriented architecture is not a brand new solution that came out of left field. Rather, SOA is a natural evolution of both architecture and technology. Systems architecture has been on a constant progression to become more aligned with the business. Architects and businesses have long understood the value of aligning technology and business processes, including better use and justification of technology resources and better support of the business.
SOA technology is partly evolved from enterprise architecture theory that has been in place for some time. Enterprise architecture basically evaluates technology, but more important, it looks across the enterprise and across the business and processes and provides a context in which technology decisions can be made. The SOA tools have evolved from a mixture that includes Internet technologies, such as HTTP and XML, and integration technologies, such as message busses, translation technologies, and connectivity.
#5: Process automation is a key virtue of SOA
A lot of organizations and technologists mistakenly focus on the service enablement and delivery within the services architecture. Unfortunately, that misses the point. The real value of SOA is as a business automation tool. Ultimately, software and systems are about creating business or organizational efficiencies, which can be defined in terms of the processes or activities the organization performs. The focus for SOA should not be on the services, but rather on the processes and how to improve them.
The services are, of course, necessary to help support the processes. But they're secondary to the goal of creating efficiencies and improvements. Services for services' sake have limited value.
#6: SOA architectures can be highly complex
From a certain perspective, SOA architecture can be fairly simplistic. For example, developing a business process flow and identifying the required services is somewhat logical and straightforward. However, leveraging the data and services in a way that is meaningful can be much more complex.
For example, let's take a scenario in which an order service allows the user to create an order in the system. This is fairly simple. But what if you want to correlate order data with data from other services? If all the services share a common data source, you can bypass the services layer, perhaps, and generate reports. However, if some data is in homegrown services, some data is in a legacy mainframe system, and still other data is in commercial applications (such as SAP), bringing all the data together can be significantly more complex.
#7: SOA requires a keen understanding of business data
Because SOA is focused on business processes, it's important to understand the data that's relevant to those processes. For instance, an ordering process has several key data artifacts, such as the order, the customer, the shipping information, the invoice, the payment, and the receipt. What's even more important is being able to describe these artifacts in a standard way so that each service that participates in the process can understand the data equally.
For organizations with an existing information architecture, this may not be a big issue. However, for large organizations with limited or nonexistent information architecture, this issue can be a show-stopper when it comes to implementation. Because large organizations have such a variety of data, it is usually recommended to take an evolutionary approach to defining the information architecture, as opposed to a big-bang approach. This means that instead of spending four years defining the ultimate data model, it's better to spend a small amount of time during service development to define just the data that's relevant to that service. As each service or process is implemented, the associated information architecture can be evolved to include the necessary data artifacts.
#8: Services can be simple or compound
Defining a service can be a difficult task. In some instances, it's obvious and clear what services are needed. In many cases, the service is reasonably simple--for example, a service to locate a customer might take some criteria that it will use to find the customer and provide a standardized customer record to the service consumer.
However, services can also be compound. This means that "super-services" may provide a standard interface, like the one that our locate customer service provides. But our previous example implied that all of the customers were in a single repository, making it easy for the service to search. What if some customers are in a mainframe, some were in SAP, some are in another application, and some are in an Oracle database? And let's assume that we already built service interfaces for locating a customer in each of these systems. In other words, we have a locate customer service for the mainframe, for SAP, for our application, and for the Oracle database. Our new locate customer service can use all of those existing services to locate the customer. Now, because our service is calling other services, it becomes a compound service. Compound services can also be created when an automated process model is itself exposed as a service.
#9: There can be multiple layers of automation in SOA
An often-overlooked characteristic of service architectures is that automation can happen in different layers. Many SOA infrastructures mistakenly look at only one layer for automation; however, automation is usually applied to at least two key areas in an SOA solution.
The first and most obvious area is in the business process layer. When processes are designed, the steps within them are linked together to create the automation. Because these processes are often based on day-to-day business dealings, they tend to involve human interaction. Having automation in human interaction processes is one of the key automation layers.
The next most important automation layer is in the nonhuman interaction, or system interaction. Integration tools have been applied to this realm for the past several years. By automating the tasks that occur between systems, you generally increase the overall efficiency of the process.
Having different tools for these layers is also important. Different considerations must be made for interactions with a human than for interactions with another application or system.
#10: Services should agree on interface standards (both protocol and data)
It's important for services to have standardized methods of communicating. In the SOA world, communication is made up of two components. The first is the network protocol that the services use to communicate. A good analogy is the communication medium that people use every day. For example, if you're going to communicate with your boss, it's best to know if your boss is expecting a phone call or an e-mail.
The second component is the data or language of the communication. Once you agree that HTTP or JMS is the communication mechanism, you have to agree on the language you are speaking. For example, if your boss is speaking French and you are speaking English, there's a good chance you will have difficulty communicating. In the services world, the language is generally XML, but that's not enough information. The data that the service is expecting has to be clearly defined and agreed upon so that both service providers and service consumers can communicate effectively.
#11: Services can be outsourced
Another virtue of services is that they don't have to be bought as complete components and managed in house, and they don't have to be developed from scratch. Instead, services can be outsourced. This means that when you need a service to handle submission of regulatory compliance documents to a government authority, you might not need to build it yourself. A variety of companies provide services for nearly every industry. By leveraging outsourced services, you can focus your SOA strategy around what's most important--your processes.
One downside to outsourcing is that you might lose some competitive advantage against a competitor that uses the same service. Another major consideration is performance. Depending on a variety of factors, primarily network connectivity, availability, and latency, performance of services from an external network can be degenerative to your business processes.
#12: Services can be built from existing legacy systems and applications
Many organizations mistakenly think that SOA approaches leave little consideration for legacy systems, such as mainframe applications. Actually, one of SOA's strongest values is that it allows an organization to reuse mainframe and other legacy assets. This is extremely important because core business logic and core business data are often locked away in proprietary legacy systems. By enabling services that access the core business logic and data, those assets can immediately be reused in automated process models.
Of course, mainframes aren't the only legacy data source. Minicomputer systems, such as AS/400, VAX, and HP3000, can all be service enabled in one way or another. Various tools can help communicate with these proprietary systems and deliver them as standardized services.
#13: Performance is a key concern in SOA systems
Although SOA does provide a lot of benefits for an organization, including alignment of technology with the business and increased agility, it can have significant performance implications. Because applications are highly segmented in a typical SOA environment, correlating data between applications is often slow. This can be a particular concern in decision support and reporting systems, which historically rely on a small number of data sources.
The key to maximizing performance is understanding where application and system performance are important to the business. There's little value in building a high-performance system to support a business process that doesn't require it. Once the critical processes are identified, you can focus on enhancement and performance improvements only in the areas where they're necessary.
#14: SOA delivery is built on four components
here are four main components of a successful SOA delivery plan. The first component is to define the business processes, what services are required to support them, and what data is relevant across them. This is the business analytics of SOA. The next component is the SOA architecture and patterns. This is a set of rules that describe how services are defined and implemented, specifies common delivery and usage patterns, and lays out the principles and standards that are adhered to when developing services.
The third component is the SOA infrastructure. This includes the networking, servers, storage, messaging tools, integration tools, and process automation tools, and so on, which support the development and delivery of services and business processes. The fourth component is the SOA development program. This program determines the priority for service development and process implementation and guides the projects that result in new services and new processes.
#15: The jump to SOA can be difficult
Despite being an evolutionary technology, and despite the wealth of knowledge now available about SOA, the move to a services architecture can still be difficult for a variety of reasons. The most immediate reason is that a change to SOA is like any other change: It requires a high level of communication and socialization to prepare the organization for the change.
Once the dynamics of change have been overcome, there may be additional technology issues. This includes building appropriate service delivery and consumption patterns, training the development teams on the technology, and potentially changing the organization structure to support an SOA development model. Although SOA technology components can be tested and proven in an isolated instance, SOA is still an enterprise-wide approach and therefore requires much more diligence in planning the governance and management of the services architecture.
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
EAI/SOA讨论区 → 『 EAI/SOA基础与技术 』 → (英)你应该知道的关于SOA的十几件事[转帖]
(订阅本版)
2006/9/22 15:11:00
新浪微博
(英)你应该知道的关于SOA的十几件事[转帖]
