Cloud！ Beyond basic SOA applications

Ten years ago, the service-oriented architecture suddenly appeared on the IT stage, and many companies had invested heavily in SOA applications. Clearly, the success of cloud computing depends on its ability to add value to existing SOA implementations. Surveys show that the corporate IT dollar spends more on applications based on SOA principles than on "monolithic" applications. It is not clear that SOA may be the ideal partner of the cloud, making it larger than the sum of all its parts.

Applications in an SOA system are different from those based on modularity and choreography, and they are built on modular elements that are grouped by the special workflow requirements of users and even individual workers. This is usually done through the workflow engine, sometimes called a message or service bus.

SOA application design is hosted on multitasking operating systems, and most of today's services or message bus technologies will support service clusters. Therefore, in the Enterprise SOA data Center, "cloud computing" has been in effect this is the fact that each SOA system component is a "service" element. Making SOA applications truly cloud compatible, especially with mixed clouds, is about the trade-off between what SOA can do and what the cloud needs.

Preventing failure based on SOA cloud

The biggest problem with creating SOA in the cloud is that most companies want dynamic load balancing in hybrid cloud applications, especially for core, mission-critical SOA applications. There are two elements that drive load balancing: Create additional component instances when needed, and balance application traffic in these components as the load changes or fails.

If load balancing has changed in the use of the datacenter, it is possible to create cloud instances after these changes, making them look like extensions in the data. This allows you to continue using the existing load-balancing strategy. However, if the power of the data center disappears, the change in load balancing disappears and the failover in the cloud fails. If load balancing is implemented as a cloud or network service, it can support the implementation of a hybrid cloud SOA-even if the data fails.

Sometimes an SOA service bus or "workflow engine" will dynamically generate additional instances of application components on multiple hosts to improve performance or respond to failures. In this case, negotiate with the cloud service provider to ensure that the service bus interface is compatible with the public cloud service. If you cannot connect the service Bus application instance process directly to the cloud management interface and start the cloud components, you may have to use development scripts or DevOps tools to speed up the necessary public cloud resources and then let the service bus use them.

It is important to evaluate the impact of vendor deferred applications when using any cloud service to create a flexible, expanded private SOA resource pool. Whether the public cloud resources are activated directly through the workflow engine or through DevOps, there is an activation phase where resources are not available, which can affect productivity. Latency has less impact on workload overflow applications because you can simply adjust the level of demand for new resource requirements. However, such adjustments may lead to accelerated public cloud resources that are not needed because of reduced demand. Preparing a standby service or having a ready-made service level agreement (SLA) to reduce the time available for cloud resources may be the best solution.

Choose a public cloud vendor that is compatible with SOA

Depending on the operating system and middleware that is used locally to run your SOA application, you can have a variety of options for public cloud hosting components. Companies like HP, IBM, Microsoft and Oracle have a platform as a service (PaaS) choice, compatible with their server and middleware tools. So if you use SOA software from these vendors, the first thing is to evaluate the benefits and costs of using cloud services from the same company.

If that is not possible or you want to explore a wider range of options, then the underlying device, the service (IaaS), may be a good direction. Remember that for the IaaS public cloud to handle your current SOA component, the IAAS device must include the operating system and middleware you use. Make sure your IaaS cloud provider can support your operating system and middleware and ensure a compatible license for use with the public cloud.

In general, administrators need to recognize that SOA and "RESTful" or "web interfaces" are different things. Most SOA applications include choreography and workflows, and security and compliance elements that are absent from basic Web services. Most cloud applications are now more based on restful interfaces than SOA, so it is risky to assume the former lessons. Explore this problem seriously and try to run tests thoroughly before making a commitment to production.