The Basic Elements of SO Architecture

What does one need to do SOA? Let's elaborate on this from an IT Archicture point of view.

For a very basic and easy SOA-Architecture you honestly don't need that much, not even an ESB or any other infrastructure. You may just build Services (preferably published as WSLD) and let them communicate with SOAP over http. That's all.
But if you would like to get all the advantages of SOA (i.e. agility, flexibility, substantial cost savings, abstraction of complexity, standardization) you should think about a clearly structured and standardized SOA-Architecture.

First you should therefore think about how you'd like to reduce and standardize the today available communication protocolls between your systems. This is a very important step towards SOA since a standardized infrastructure helps in saving development and deployment costs. I suggest that you choose three different protocols for the three basic communication patterns: asynchronous (e.g. jms), synchronous (e.g. http(s)) and bulk transfer (e.g. (s)ftp). To achieve this you may build your own infrastructure framework by for example building adapters that can be pluged into your applications. Or you may buy an ESB that is sold on the market by many different vendors.

Second you need a software to manage your services. By doing so you avoid an unmanaged service cloud. This is just as you would manage any other assets of your company. In the SOA context such a management tool is called Service Repository.

Third don't forget to think about security. Most infrastructures and repositories offer basic components such as service authorisation or provider/consumer authentication. But you still need to make sure this components comply with your security model.

Forum Geschäftsprozesse Wien, 29. - 30. Mai 2006

Im Rahmen meiner Tätigkeit als SOA-Evangelist/Architect wurde ich eingeladen am Forum Geschäftsprozesse in Wien zu referieren. Gerne nehme ich natürlich diese Gelegenheit war. Folgende Themen möchte ich im Vortrag behandeln:

Erfolgreiches Umsetzen von SOA und tatsächliche
Potenziale für Ihr Unternehmen
• Management-Attention - Erfolgsvoraussetzungen für die SOA-Umsetzung
• Organisatorische Anforderungen und Aufbau von SOA Know-how-Trägern zum
Unterstützen der Umsetzungs-Projekte
• Potenziale finden und realisieren
• Einsatz von ESB (insbesondere Service Repository) und Services zum Optimieren
der Prozesse
• Einsparungspotenziale in Entwicklung und im Betrieb
• Think Big, Start Small: Einfluss auf die gesamte IT und deren Verwendung
• Richtiges Gestalten der SOAUmsetzung im Unternehmen

SOA Domain Model White Paper from BEA

Have you ever thought about making a Domain Model for your SOA-Architecture that lines up with your meta data model? No? Here is a good White Paper from BEA. Go ahead and check it out.
SOA Domain Model White Paper

IBM Podcasts

IBM Germany offers some free interesting podcasts; check it out.

http://www-5.ibm.com/de/podcast/

What is a Service?

This is a questions I hear very often - not only from the Management but also from Architects and Developers.
Let's try to find an answer....

First, you should understand the Term 'Service' because this is the most important part of any Service Oriented Architecture.

The term 'Service' indicates that IT is moving towards the Business Layers and therefore offering its functions as Services.

A Service has the following characteristics:

• a Service is, from a business perspective, a reusable component
• a Service has a standardized interface that abstracts the implementation details and technology of the underlying system. It is therefore loosly coupled.
• a Service always has a contracts that specifies the terms of use and the policies applied.

To make it more clear what Services are we can differentiate between three types of Services:

• Business Services; offer a Business Functionality that is needed in a certain Business Process Step.
• Intermediary Services; handle technology gaps, offer routing, transformation and security capabilities.
• Basic Services; implement the needed Business Logic and handle the data.

Service Repository

Managing Services will be as managing any other asset within your company. Therefore you might need a COTS-Products that assists you in doing that.
There are - besides the also very good and performant Gnu-Software such as JUDDI - two main products available.

1. Systinet
2. Infravio X-Registry

From a architecture point of view the Infravion X-Registry is much more sophisticated since its architecture is highly component based. Neverless the distribution of the functions and the underlying different data bases (1 for registry, 1 for repository) are completely transparent to the user. Hence, the user does not have to care whether he want's to use a function of the registry or the repository. It's just all there right at your fingertips.

The advantages of the COTS-Products compared to Gnu-Software (e.g. JUDDI) are in fact that you will get not only a registry (UDDI) but also a repository (eb).