以文本方式查看主题 - 中文XML论坛 - 专业的XML技术讨论区 (http://bbs.xml.org.cn/index.asp) -- 『 EAI/SOA基础与技术 』 (http://bbs.xml.org.cn/list.asp?boardid=73) ---- (英)你应该知道的关于SOA的十几件事[转帖] (http://bbs.xml.org.cn/dispbbs.asp?boardid=73&rootid=&id=38204) |
-- 作者:admin -- 发布时间:9/22/2006 3:11:00 PM -- (英)你应该知道的关于SOA的十几件事[转帖] http://www.zdnetasia.com/insight/business/0,39044868,61952144,00.htm 10+ things you should know about SOA 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. 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 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....) 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 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 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 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 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 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) 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 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 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 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 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 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.
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
46.875ms |