Understanding and implementing SOA in a middleware environment
16 September, 2008
Metadata is at the heart of effective SOA
From this we can see that the effective use of SOA is highly dependent on metadata and its effective exchange between quite disparate IT environments.
Perhaps more importantly, the metadata itself needs to be in a form that facilitates the automatic discovery - and incorporation - of new types of data formats within a given IT process.
In our airline example given above, this means that, if a new travel facility (e.g. Eurostar) is grafted on to a bookings system, then the booking systems will recognise that Eurostar is a rail transport system and process the data accordingly - without the need for full-blown human programmer intervention.
And, from a programming viewpoint, this is where the effective use of SOA modelling engenders a number of business efficiencies, including the development of a common data model between systems.
Despite the nebulous concept of SOA modelling, it's perfectly possible to adopt traditional programming techniques, such as the development of a common data model.
Using a common data model approach allows developers to view data as a part of the architecture and, in doing so, couple the data to the services in the SOA model.
The slightly bad news is that it's only possible to loosely couple to the data to services. The best approach is to start with the services and work back to the data - redesigning and redefining the service after you define the data layer.
It's also important to realise that the resultant abstracted - or common model - must be tested like any other program component.
A good service-oriented model takes a holistic view of the analysis, design and architecture or all the software entities on a company IT resource and views those entities as service-oriented assets, which are collectively known as services.
From this we can see that the effective use of SOA is highly dependent on metadata and its effective exchange between quite disparate IT environments.
Perhaps more importantly, the metadata itself needs to be in a form that facilitates the automatic discovery - and incorporation - of new types of data formats within a given IT process.
In our airline example given above, this means that, if a new travel facility (e.g. Eurostar) is grafted on to a bookings system, then the booking systems will recognise that Eurostar is a rail transport system and process the data accordingly - without the need for full-blown human programmer intervention.
And, from a programming viewpoint, this is where the effective use of SOA modelling engenders a number of business efficiencies, including the development of a common data model between systems.
Despite the nebulous concept of SOA modelling, it's perfectly possible to adopt traditional programming techniques, such as the development of a common data model.
Using a common data model approach allows developers to view data as a part of the architecture and, in doing so, couple the data to the services in the SOA model.
The slightly bad news is that it's only possible to loosely couple to the data to services. The best approach is to start with the services and work back to the data - redesigning and redefining the service after you define the data layer.
It's also important to realise that the resultant abstracted - or common model - must be tested like any other program component.
A good service-oriented model takes a holistic view of the analysis, design and architecture or all the software entities on a company IT resource and views those entities as service-oriented assets, which are collectively known as services.
Recommended Articles
blog comments powered by Disqus
