SOA: five shortcomings to be improved

Source: Internet
Author: User
Tags software ag
The increasingly mature Web service standards make SOA more practical. Should you deploy it now? After these standards are rectified? When media and vendors are advocating the benefits brought by SOA, can you clearly see the shortcomings of SOA?


The concept of Service-Oriented Architecture (SOA) continues to attract the IT industry. However, it is unclear whether SOA can implement universal application integration, which puzzles those who carefully study it. It is not difficult to find that SOA still has serious defects in reliability, security, preparation, legacy system support and semantics.

Peter Underwood, vice president of software development at brokerage Wall Street Access, said his team had carefully considered it before planning SOA integration.

"We started to think that SOA is just a common technology. In other words, it is a framework, "Underwood said. Although SOA is developed because of the maturity of Web service standards, there is still a considerable gap between the potential of Web Services and existing functions.

Enterprise Directors are willing to use Web services to meet simple requirements, such as sending information to Web-based portals. However, complicated key task transactions are another matter. They may need some Web service standards that are still under development. Therefore, when is it wise to choose an SOA strategy that uses Web Services? When is normal Enterprise Application Integration (EAI) better? This depends entirely on what you want to do and what shortcomings you will encounter in Web service functions.

One drawback: Reliability

I am afraid that the customer's demand for highly reliable asynchronous message transmission is the most difficult to meet, at least in the short term. Aiaz Kazi, managing director of enterprise integration at Tibco, The EAI giant, believes that such message transmission is "crucial to the integration of enterprise applications ."

Sam Boonin, vice president of marketing at Blue Titan, a Web service infrastructure vendor, said the demand for reliability is similar to what we often discuss in other computing examples, SOA is not completely the highest reliability of transactions-nonrepudiation, messages will be transmitted only once (once-and-only-once delivery) and rollback, but it is only a matter of time when standards and implementation technologies are mature enough to meet this demand."

In fact, several draft specifications on Web services can solve the problems encountered by key tasks and long running processes. For example, WS-ReliableMessaging is designed to ensure that SOAP messages reach their destination. WS-AtomicTransaction and WS-Eventing) and several other proposed specifications will define methods for handling complex, stateful, and long-running business transactions. However, unlike many security-related protocols, such reliability standards have not yet been widely used.

Thomson Prometric is a vendor that provides computer-based testing and evaluation services. Chris Crowhurst, vice president of corporate architecture, said before that, "reliable message transmission is a huge burden for Web Services, however, in the end, the application only needs to be built around it, "because the compatibility of Web Services has many advantages.

Currently, building around it is to develop application software to anticipate and handle errors in advance. This also serves to support point-to-point SOAP relationships by using intermediary products that provide standardized abstraction layers (such as Web Service Management Agents. These products are provided by independent software developers such as Actional, AmberPoint, and Blue Titan, so that management personnel can provide fail-over to the software endpoint and upgrade to the software endpoint, production Systems suffer minimal interference (practical Web service management should be able to work across many platforms, which can explain why major vendors such as BEA, IBM, and Microsoft lack similar solutions .)

On the other hand, as Dan Foody, CTO of Actional, a Web Service Management vendor, said, "Not every problem requires the same reliability ." It is essential to ensure reliability of asynchronous transactions that have many relationships and run for a long time, such as complex financial transactions. For less demanding transactions, SOAP on HTTP is quite reliable, especially for simple synchronous transactions.

Rajan Jena is the architect of Oncology Therapeutics Network, a subsidiary of Baishi meiguibao. He has used traditional middleware and Web Services for message transmission in the company's integrated infrastructure. He said that if the number of transactions is large and batch transmission is performed, the message transfer solution is not often suitable. On the other hand, if the number of transactions is small but must be completely real-time, the Web Service is very suitable.

Defect 2: Security

For IT administrators, authorization, verification, and encryption requirements are particularly important if they want to consider using Web service-based integration.

In the past, access control only required logon and verification. In a distributed Web service environment, the components of an application software can easily communicate with other components in different domains, therefore, it is much more complicated to ensure the security between different and interconnected systems.

Like reliable message transmission, the industry has developed a number of standards for Web service interaction. Two standards are particularly important and widely implemented: WS-Security) and Security Assertion Markup Language (SAML ). The former describes a highly scalable framework that lists in detail all aspects of system security functions. The latter defines the standard method for transmitting security assertions, Which Is Single Sign On (Single Sign On, SSO for short) This Authentication mode provides convenience.

For Enterprise SOA, analysts mentioned the third but immature proposal: WS-Policy. WS-Policy will provide a means for different systems to declare which security mechanism is needed before they recognize the connection. Without the WS-Policy standard, the function of loose coupling across domains will be severely restricted.

Although none of the proposed standards can independently address the security challenges of Web Services, they can be combined to provide assurance for routine security policy planning. Indeed, the Web Service compatibility Organization (WS-I) recently recognized part of Web Service Security as a Basic Security Profile, a series of best Security policies designed to ensure compatibility. It is expected that the organization will support SAML and other standards in the near future.

In the short term, there is a relatively practical method to protect the security of Web services, that is, the technology used to protect Web-based standard application security: Transport Layer mechanism, such as SSL.

One advantage of SSL is that it supports two-way authentication through client/server certificates. However, if the number of clients is large, daily maintenance of the certificate infrastructure will become a challenge. An existing supplementary solution is to use common firewall (Representative vendors include DataPower, Forum Systems AND Reactivity) that can understand XML and XML digital certificates to provide another protection measure for Web service network traffic.

After the distributed security architecture is put in place, IT management personnel should be able to breathe a sigh of relief. In the past, routine maintenance of application security often fell on the shoulders of programmers-but as a result, they were unable to perform their operations and leave security risks at the same time. With Web service-based security management, it is much more reasonable for authorized operators to take charge of this task.

Oncology Therapeutics Network's Jena claims that when his company switched to SOA, this security method is very important to its CRM and order management systems. "This means that we can implement security management from a policy perspective, rather than developers actually include security functions in application software. We think this is a great advantage. This method actually improves the security of application software ."

Defect 3: Preparation

Unified coordination of distributed software components to build meaningful business processes is the most complex, but it is also the most suitable for service-oriented integration, for obvious reasons, applications built on SOA can be designed as services that can be split and reassembled as needed.

As the core of the current business process management (BPM) solution, the preparation function (orchestration) enables IT administrators to use the features of deployed packages or self-developed application software, connect the new meta-application.

Blue Titan's Boonin says this feature is important to many users adopting SOA integration strategies. Boonin said: "They built Composite Application Software on the SOA infrastructure and compiled services into reusable business processes ." At first glance, assembling these parts and guiding the flow of Business Affairs is a simple task. After all, the main stumbling block of BPM solutions has always been the lack of flexibility in software. On the other hand, web services can divide software into multiple components, each of which is related to a certain business function.

In fact, the biggest challenge is not to build modular application software, but to change the methods in which these systems represent the processed data. Thomson Prometric's Crowhurst recommends that "the business core model should be validated" instead of designing processes around isolated individual systems and data records .", In other words, it is best to regard the results of the Business Process as a document, which contains the answers to every important question encountered. As a basic element of Web Services, XML can make this concept a reality.

The industry has put forward several standards for preparation and BPM. One of them is the Business Process Execution Language (BPEL), which is widely supported by the industry and even appears in many BPM products. However, we all agree that the stable BEPL 2.0 version will be completed in about 15 months. As a supplement to BPEL, the main purpose of Web Service atomic transactions and Web Service Composite Application Framework (WS-CAF) is to facilitate complex transactions that constitute long-time operational and stateful business processes.

BPM professional companies, traditional EAI companies, and major platform vendors all believe that using this standard-based New BPM to implement process visualization, execution, and monitoring is of great commercial value, SAP, Oracle, and other enterprise application software vendors are also included. Last year, Oracle acquired the BPM professional-Collaxa; SAP adopted a very different approach-re-designing the software to integrate its own version of the BPM-Oriented Middleware NetWeaver. Finally, the XML-centered database designed specifically for SOA will become an increasingly important aspect of the business process model, these products include Data ctor of Blue Titan and Tamino OF Software AG,

Defect 4: Legacy System Support

An excellent legacy system adapter works like a well-designed Web service: it provides an abstraction layer that isolates the rest of the application infrastructure from various tricky issues.

Software programs used to connect applications and legacy systems are no different from the Toolkit in the suitcases of people traveling around. Just like a proper type of power adapter that allows American tourists to plug the power cord of a portable computer into a wall outlet after arriving in Greece, dedicated application adapters also allow one system to obtain data from another system.

For example, each country has its own power outlet standard, and each legacy system needs its own adapter. Over the years, EAI vendors have been emphasizing that their own series of legacy application adapters are the key factors to distinguish services from good or bad, and of course they are also an important source of revenue.

Fortunately, as Web Services and other standards are increasingly dominant in terms of compatibility, the cost of simple connections has declined. At the same time, third-party application adapter companies such as Attunity and iWay have increased competition, greatly increasing the number of existing connection solutions.

One benefit of legacy application adapters is sometimes overlooked, that is, they shield the complexity and obscure nature of many patent APIs. An excellent adapter works like a well-designed Web service: it provides an abstraction layer that isolates the rest of the application infrastructure from various tricky issues. Software AG and other vendors specifically integrate the legacy application Software into the XML-based integration architecture.

Software packages for Oracle, SAP, and other companies provide more or less support for standard-based connections. Generally, they all use SOAP interfaces to generate patented APIs (such as SAP Business APIs) package. As application software vendors are using Web Services and adding middleware-like features to their respective products, the standard method for integrating application software packages will gradually reflect the best SOA strategy.

Even so, using expensive patent application adapters is still the only solution to connect many truly outdated systems to a universal integration framework.

There is still a glimmer of hope for IT companies that use mainframes of companies such as IBM and those that have actively migrated basic Web services to old devices. Surprisingly, using SOAP shows that the APIs of these companies are far simpler than figuring out the APIs in many client/server systems.

Defect 5: Semantics

Defining the business meaning of transactions and data is the most difficult problem for IT administrators. Although semantic difficulties existed before Web services-for example, the vertical industry has been developing its own XML schema for many years, SOA has pushed semantics to the front-end.

Semantic relationships are the core elements of a well-designed SOA architecture.

No technology or software product can really solve semantic problems. Defining and implementing functions and data models for specific industries and functions is a heavy task and must ultimately be undertaken by the business and IT management personnel. However, prefabricated components and proven consulting skills can simplify many challenges.

EAI vendors believe that their rich experience in developing and integrating solutions may slow down the impact of Web service standards. Tibco's Kazi bluntly said: software integration "is a field we have been involved in many years ago. We can say that we have opened up this field ." If you look at the website of Tibco, you will find specific solutions for Telecom, medical, transportation, and many other industries.

While supporting SOA, software vendors are also promoting their experience in specific industries and business processes as capital. For example, SAP has spared no effort to emphasize its xApps program, which implements business processes based on Web Services and can span vertical and functional systems that have traditionally been isolated.

Many companies are increasingly aware of the importance of developing XML standards for the industry. For example, the financial service industry has developed FIXML, an exchange protocol for banking transactions. The accounting industry has proposed the use of the eXtensible Business Reporting Language (XBRL) to describe and review records of the General Ledger type; manufacturers in the high-tech industry continue to use RosettaNet standards derived from many XML terms to exchange product and component information in the supply chain.

In fact, many observers believe that the dynamics of the company's industry may be one of the most important driving forces when and how SOA trends emerge. Bob Sutor, IBM's WebSphere infrastructure Director, stressed that the adoption of SOA in financial services and other industries is particularly positive. In addition to vertical industry standards and other technical drivers, he specifically mentioned that a large number of merger activities are an important factor contributing to this trend. He said that wise adopters should use SOA-like technologies instead of slowly organizing information and then copying information from a company's system to another company's system, quickly "integrate business departments online" to reduce interference.

Despite the challenges mentioned above, most IT managers agree that service-oriented integrated infrastructure is a question of "when to use" rather than "whether to use. Even so, the old saying "Think Twice" still applies completely. If there is a lack of clear guidelines for business analysis and development, "the interface will be re-built in the end, which is really terrible," says Underwood of Wall Street Access.

David Sprott, CEO and chief analyst of the research company CBDi, agreed, but warned that service-oriented strategies should not be driven by technology. He said: "From the service perspective, this helps put businesses and IT in the same position. In other words, we should not simply implement services to catch up with any waves, but act according to business needs and ROI rules ."

Thomson Prometric's Crowhurst also believes that it is important to learn how to express basic business processes with services. "Changing development methods requires cultural changes. In contrast, solving technical difficulties is just an intellectual exercise," he said ."

Text

Performance: The sixth defect of SOA?

People who attack Web Services and SOA often mention that performance is an obstacle to adoption, but the standardization of technology always needs to sacrifice speed. We have already talked about some shortcomings of Web service-based SOA. These shortcomings are inherent in the loose coupling and distributed nature. But those who are skeptical often mention another problem-performance, and think it is a major weakness of SOA. This type of Skeptical View is usually aimed at two aspects: the distribution of SOA and the overhead of Web service protocols.

It is undeniable that the execution speed of any distributed system is not as high as that of a standalone system, because of network restrictions. Of course, some application software cannot tolerate the latency caused by the network, such as those applications that require high real-time performance, but we must also see that this situation does not exist only for Web Services or SOA. In practical applications, the flexibility brought by Web Services and SOA and the benefits of connecting systems closer to the job units they represent-and connecting these systems across organizations or networks-are far behind the network. the impact of latency on performance.

More closely related to this issue is that XML transactions are more complex and large compared with transactions using binary encoding. It is estimated that the difficulty of converting a SOAP request to an internal object is 10 times higher than that of using a local Method such as Remote Method Invocation. This sounds reasonable, but when you consider the experience gained from the Web, you will find that this is not the case. Like HTML, XML uses lengthy statements to describe information, but it is also this kind of accessibility and scalability that makes up for the performance loss. Over time, Moore's Law and XML accelerators will gradually eliminate the performance impact.

In the end, the winner is neither a supporter of Web services nor a critic of Web Services, but those who can use appropriate tools to handle appropriate transactions. In the future, large-capacity transactions will continue to be handled by the patented middleware solution using binary encoding; applications that require less frequent but more flexible interactions will be more and more satisfied by Web Services.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.