What advantages are there by using SOA in implementing the IEC61400-25

SOA can be used in many different environments. But in the case for this prototype the amount of different vendors and individual requirements in the use of the system places the scope of prototype as an enterprise. The following discussion therefore will only look at SOA for WPP as enterprise architecture.

Service 1

Logic

Service 2

Policy

Logic Contract

WPPs also has the possibility to communicate among each other

User interface Policy Contract User interface

Policy Contract

The purpose for designing a standard for controlling and monitoring WPPs is to have a common way of performing certain actions. As the designers very well know, it is hard to get a group of people with different interests to agree upon a common standard unless it is flexible enough to suit their individual needs. This not only includes what is communicated, but also how. IEC61400-25 uses web services as one of its communication mapping profiles, defined in IEC 61400-25-4. Using web services ensures that different clients and environments can be used. Each vendor can develop the service or client in there favorite programming language and host system. The system will still not be tightly bound, as long as only standard methods and data types defined in the contract is used. Each vendor is not dictated to use a specific language or platform.

Other benefits include:

• Updating: Having a loosely coupled system comprised of services rather than a tightly coupled system, provides the benefit of updating only subparts of the system. This can be done without a system-wide shut down. Only the involved services are turned off. If the system has several possible places to get a service performed, the system might not even look any different to the end user. The internal business logic can be optimized endlessly, and as long as the interface remains the same, there is no need for rebuilding or taking the whole system offline.

It is intended that a service control one or a couple of WPPs. The effect of updating in one service will not affect other WPPs.

• Maintenance: In a system comprised of several fat clients⁸, changes to the system would have to be introduced to every single machine in the system. By using rich clients⁹ the functionality only has to be changed at one place. If each WPP has its own web service it is still necessary to deploy changes to each individual WPP.

But if a service is used by several clients this would be a considerable advantage;

like a logging service used by several clients.

• Reuse: From the use of OOP we know how reuse of logic and components in a system can reduce the development time drastically. These components are often tightly coupled to other classes, or a specific environment. The contrast to this are services where ideally there exists no binding to other components in the system.

This makes the service ideal for reuse across a variety of platforms and languages.

The different WPPs are not interchangeable, because they hold their own unique data, however the logic used on each WPP can be reused on WPP with the same configuration.

• Scalability and availability One of the major problems facing a system is frequently changing demands. The number of service calls changes, and the hardware cannot handle the requirements anymore. To accommodate this, a good system should be easy to up- and down-scale to meet demands. One strategy might be to distribute services to different locations, having more machines doing the tasks of the system, thereby balancing the load. In traditional operating systems, it might not be easy to distribute the system. At least it would require that some kind of redesign be made. This of course could be a costly affaire. By using services, each service could simply be deployed on several machines. The additionally offered services then just had to be registered in a Universal Description Discovery and Integration (UDDI)¹⁰ directory. It would be possible to split the service associated to a WPP into smaller parts, where each service only is in charge of a subpart of the methods that the WPP exposes. How ever most of the methods rely on having access to current data from one specific WPP. Here it would not make sense to split the service. For logging and reporting it might be plausible, if one service could not handle all the clients.

• Cheaper to change. If the system is designed in a tightly coupled manner, changes might be very costly. Change of a supplier might not be as easy as in theory. A lot of work might be involved in either converting the existing system to the new supplier or some of the systems dependent objects might have to be redesigned and implemented again. From a business point of view, the two major reasons for not introducing new and possible better solutions to a system are the time that it would take to implement the change or alternatively that the tasks are simply demands to many resources to. The new functionality might be beneficial to both customers and the firm in general, but it is not always economically feasible to enforce the change. The total cost of the conversion must be smaller than the short or long term cost of the change, to save money. Having a system comprised of completely independent, interchangeable objects would resolve in far cheaper restructuring of a given system. This opens the possibility of testing new and possible better solutions or services to a system, making the overall value higher.

[KBS04] With the amount of players in the WPP field, using the standard opens up for the possibility that the proportion of shelf services becoming available is rising. This could be a far cheaper solution when the cost of designing and testing a component from scratch would cost.

If a SOA system is designed in the right way, it assures that the system be agile, where changes and maintenance can be done in an easy and cheap way.

It is very important for the system to be flexible, where changes can be administrated in a cheap and easy way. If the system is designed in a way where functionality is too tightly coupled, the cost of making a change might simply be too expensive to perform.

10 UDDI is a platform-independent XML-based registry for services to list themselves. UDDI is an open industry standard, sponsored by OASIS. UDDI is a directory of services there can be used by others. It can be compared to a phonebook advertising the existence of a service. UDDI is part of the Web Service Interoperability (WS-I) standard and is considered a corner stone in the web services infrastructure.

The most significant reason to use SOA for the IEC61400-25 prototype is the possibility for each vendor to choose their own platform and language for their service or client, and at the same time ensuring that other vendors can still communicate with them. This makes it a lot easier as an owner to maintain the system, and data supplied by the WPP can be compared directly. More players in the field will also benefit the cost of developing new monitoring system, due to a more competitive marked.