Les communications
Plutot que d’imbriquer le code des appels des services dans les code de chacun des services, des protocoles sont définis qui décrivent comment un ou plusieurs services peuvent communiquer entre eux. Cette architecture repose sur un expert des process métiers afin d’orchestrer toutes les interactions entre les différents composants.
La taille des composants
La tailles des composants atomique a largement évolué par rapports aux premiers essai d’architectures distribuées. Les composants sont aujourd’hui de 100 à 1000 fois plus gros qu’ils ne l’étaient dans les normes précédentes. Cela permet de réduire le poids de l’architecture dans le développement de nouvelles applications, alors qu’auparavant la multiplicité des composants devenait rapidement ingérable. Cette cohérence entre les composant est gérées par ce qu’on appelle l’orchestration. Ce process permet d’associer des “bouts” de logiciels (les services) dans un arrangement non hiérarichique (à l’opposé des classes qui sont hiérarchisées). Il est à la charge d’un ingénieur logiciel ou d’un ingénieur en process, ce dernier utilisant un logiciel d’orchestration pour recenser et classer de manière exhaustive la liste de tous ces services, leurs caractéristiques
Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can consume to dynamically configure to maintain coherence and integrity, and in a form which system designers can understand and use to manage that metadata.
The goal of SOA then is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. The larger the chunks the fewer the interface points required to implement any given set of functionality. This is at odds with very large chunks of functionality which are not granular enough to be easily reused. Since each interface brings with it some amount of processing overhead, there is a performance consideration in choosing the granularity of services. The great promise of SOA though, is that in this world, the marginal cost of creating the nth application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.
The key here is there are no interactions between the chunks which are specified within the chunks themselves, as there are where functions specify their calls to other functions, or classes’ specify ownership of their member functions as well as calls as part of the source code. By contrast, the interaction of services, all of whom are unassociated peers, is specified by humans in a relatively ad-hoc way with the intent de’jour driven by newly emergent business requirements. Again we see the need for services to be much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. The services themselves continue to be made using classical languages like Java, C#, C++, C or COBOL.
SOA services are therefore loosely coupled, in contrast, for example, to the functions a linker binds together to form an executable, a DLL, or an assembly. SOA services also run in “safe” wrappers such as the .NET environment, which manages memory allocation and reclamation, allows ad-hoc and late binding, and some degree of indeterminate data typing.
It is important to note that increasingly there are third party software companies which offer software services for a fee. Going forward, many SOA systems may be composed of services, only some of which were created in-house. This has the potential to spread costs over many customers, and customer uses, and promotes standardization both in and across industries. The travel industry in particular now has a well-defined and documented set of services, and the data they consume, sufficient to allow any reasonably competent software engineer to create travel agency software using entirely off the shelf software services. Other industries, such as the finance industry, are also making significant progress in this direction.
There is no widely agreed upon definition of SOA other than its literal translation. It is an architecture that relies on service-orientation as its fundamental design principle.[1] In an SOA environment independent services can be accessed without knowledge of their underlying platform implementation.[2] These concepts can be applied to business, software and other types of producer/consumer systems.
Post a Comment