is SOA or rest the best fit for large data applications?

As with all enterprise data, large data can only be used to project users through applications. For architects who design or redesign http://www.aliyun.com/zixun/aggregation/8213.html "> Large data applications, a key question is whether to use object-oriented architecture (SOA) or restful The API connects large data components and services to other parts of the application. Start with an interface that is exposed by a large data product and then define a large data interface on the application side. Next, consider security and governance, and finally, be careful to separate management and access services regardless of the API you choose.

A major problem with large data applications is the nature of the exchange with the larger data container itself. This relationship includes the traditional level of abstraction that is most appropriate for the application, the required transaction and state control, and the necessary security.

Large data tools often mix APIs, some restful, and some SOA-like APIs. This combination can lead to a chaotic scene, unless the large data interface is abstracted as a service or resource rather than directly exposed to the application. In this case, only one component needs to make changes-large data adapter flow-If the big data tools change radically.

Large data applications, when to use SOA, when to use rest

At the interface between large data adapters and other components, see how large data is used to guide the selection API. SOA is suitable for publishing a set of specific capabilities with application bindings to things like large data containers. This model can be highly abstract, meaning that applications using large data can be completely isolated from the technology and distribution of the data itself.

The application is expected to use large data more in the context of the results of a particular analysis or protocol process, in which case SOA makes sense. The restful interface might be more appropriate if the application needs to know the large data as a resource set and does not want to abstract it into a high-level service.

An application review at this altitude is essential not to fall into the trap of assuming that large data applications should be developed using an existing restful API such as Apache Webhdfs. In general, the best approach is to connect large data processes or facilities with applications through existing interfaces, rather than those used for direct file system level operations. The latter type of interface produces considerable incremental development work, and if it is written at this level, it is almost impossible to migrate applications from one large data service or facility to another.

Context, state, and transactional behavior

A transaction is the context of a work, a logical sequence that generates process steps from the business perspective. When determining whether SOA or rest is most appropriate for large data applications, the first question is if transactional work is contained within large data components, or whether large data references are propagated across multiple components in a transaction. In the first case, the RESTful interface can be easily deployed. In the second case, if you want to use rest, you need some kind of transaction state control mechanism. And SOA is easy to handle in both cases.

Security and governance are also important points in making SOA and rest decisions for large data. SOA security, Access logging, and control are explicit and highly integrated with user directory and application control. Rest security and access control mechanisms may be externally applied. This could be a powerful reason to wrap large data access into SOA, even when rest is used at the level of large data products. If the restful model is adopted, it must be clear how to build large data security through formal governance reviews. Most users absorb VPN or SSL-level security, but are also enhanced through network-level application access security.

Finally, be careful not to expose excess. In most cases, large data services can be divided into two categories-the actual data access service and the data Service platform management and control services. All modern large data architectures support both, but because platform management and control is often seen as a technical process rather than an application process, support often involves low-level functional access through a simple rest interface. Large data management services should be exposed to application developers or users as little as possible because of the risk of significant errors.

When you need platform management tools to prepare for large data use, it is best to implement these features within a large data adapter component, to build an easier interface for application developers, and to ensure that the necessary platform management steps are always experienced before large data analysis begins.

It is necessary to reserve access to the platform management APIs for architects and large data experts, so that they can be used in day-to-day data warehousing maintenance tasks. Some users recommend abstraction of low-level platform management APIs so that even platform management practices can be applied across multiple implementations, but experience has taught us that it is difficult to build useful generic practices at this level. It may be best to let experts and architects adopt a specific platform management API as needed.

Once the large data soa/rest review is complete, always remember to contrast the results of these two distinct API styles with the general policy. When a tool is created, it is not just established API baseline support, but also different practices that anticipate higher levels of risk. Ensure that the risk is evaluated before it goes ahead.