In one of our current customer SOA projects we’re using Oracle Enterprise Service Bus (ESB) to implement and expose services. One of these services involves transformation of inbound data and persisting this data in a database. We’re using XSL to transform the inbound data and Oracle Application Server’s database adapter to persist data into a relational database. JDeveloper, Oracle’s IDE, provides wizards to configure database adapters. TopLink (an object-relational mapping framework) mappings are generated as a result of this configuration. These mappings are XML files containing metadata such as the structure and format of the database tables. In our ESB flow data is transformed into nested XML format, which is persisted in multiple master-detail tables.
This week -after a modification to the database adapter configuration- data was still persisted, but lots of database records that were previously populated, were suddenly empty. The ESB console indicated all instances were valid and debugging the ESB flows showed that the input XML consumed by the database adapter was unchanged. After some more investigation it turned out that the order of tables in some of the generated TopLink mapping files (OurService_table.xsd, OurService_toplink_mappings.xml and OurService.RootTable.ClassDescriptor.xml) had altered; e.g. instead of table 1, table 2, table 3, the order of tables was table 1, table 3, table 2. The transformation activity still generated input XML data as table 1, table 2, table 3. Synching the order of tables in the transformation and mappings files resolved this issue. This means that runtime, the database adapter strictly follows the order of tables indicated in the TopLink mappings. You can argue whether this is too strict or not, especially since the same tools are very “tolerant” of other faults, omissions, validation, etc. Well, at least you would like to see some kind of error when the XML input format does not conform to the TopLink mapping definition.
Anyway, this was a tricky issue since the input XML seemed valid, the ESB console indicated all instances were valid, no error was logged and some data (but not all!) was persisted in the database.
Monday, February 11, 2008
Friday, February 8, 2008
Events and SOA
In my opinion events are just as important in a SOA as services. I think it’s not possible to achieve a “real” SOA without addressing events separately, just as we do for services. It can be somewhat confusing that events have there own acronym emphasizing their importance, namely Event Driven Architecture (EDA). Some coin this as the upgraded version of SOA, or SOA 2. How we love 3 (or 4 or 5) letter acronyms :-) Most of these different acronyms only add to the confusion, so I prefer sticking to SOA and emphasize events as integral part of it.
So why are events important?
A service-oriented approach should result in business-value (ROI), otherwise SOA only introduces technical complexity through additional middleware. One of the ways to achieve this is through business-IT alignment. Events play a major role in both of these worlds (business and IT).
Business
Businesses deal with (and are causing) events all the time: a customer moving to a different address, a new purchase order, receiving an invoice from a supplier, sending a bill to a partner, and so on. Entities in a business’ ecosystem such as employees, partners, suppliers and customers all react to these events. They initiate new processes, perform activities, propagate events, and so on. It is therefore logical to incorporate events when modeling business processes, which are at the heart of SOA. Just as in all modellng practices, one wants to model and focus on important aspects. In case of SOA this includes processes, services and events.
IT
From a technical point of view events can achieve asynchronicity and de-coupling. By using publish/subscribe and queueing mechanisms, software components are not required to know of each others existence. They simply subscribe to a topic and act based on received (and subscribed to) events. The other way around, if components have some (intermediate) result or state, they can share this with the rest of the world by publishing an event and then forget about it. These components don’t need to know what other components are interested in this information. Of course you’ll need some glue (i.e. middleware) to implement this.
So what does this mean concretely in a SOA-project? For one thing, besides trying to identify what types of services you have (business services, composite technical services, etc.), also investigate what types of events can be identified. There should be an event-registry besides a service-registry. This does not need to be a full-blown tool at first but can simply be documented using Excel in the beginning. Also define the relationship between processes, services and events. What services publish what type of events? What processes are initiated by what events? What running processes are influenced by what events?
So why are events important?
A service-oriented approach should result in business-value (ROI), otherwise SOA only introduces technical complexity through additional middleware. One of the ways to achieve this is through business-IT alignment. Events play a major role in both of these worlds (business and IT).
Business
Businesses deal with (and are causing) events all the time: a customer moving to a different address, a new purchase order, receiving an invoice from a supplier, sending a bill to a partner, and so on. Entities in a business’ ecosystem such as employees, partners, suppliers and customers all react to these events. They initiate new processes, perform activities, propagate events, and so on. It is therefore logical to incorporate events when modeling business processes, which are at the heart of SOA. Just as in all modellng practices, one wants to model and focus on important aspects. In case of SOA this includes processes, services and events.
IT
From a technical point of view events can achieve asynchronicity and de-coupling. By using publish/subscribe and queueing mechanisms, software components are not required to know of each others existence. They simply subscribe to a topic and act based on received (and subscribed to) events. The other way around, if components have some (intermediate) result or state, they can share this with the rest of the world by publishing an event and then forget about it. These components don’t need to know what other components are interested in this information. Of course you’ll need some glue (i.e. middleware) to implement this.
So what does this mean concretely in a SOA-project? For one thing, besides trying to identify what types of services you have (business services, composite technical services, etc.), also investigate what types of events can be identified. There should be an event-registry besides a service-registry. This does not need to be a full-blown tool at first but can simply be documented using Excel in the beginning. Also define the relationship between processes, services and events. What services publish what type of events? What processes are initiated by what events? What running processes are influenced by what events?
Subscribe to:
Posts (Atom)