New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Boris Lublinsky on Sep 01, 2010
One of the requirements for a successful SOA implementation is semantic interoperability of the service’s messages. This typically requires basing service messaging/interfaces on the industry-specific Common Information Model (CIM). Because the CIM is abstract, in the majority of cases this CIM has to be extended for various reasons from necessity to include additional data elements for integration reasons to adding elements required for carrying out business logics by the Service component. A new DeveloperWorks article by Gandhi Sivakumar introduces 3 typical CIM layers and describes the property of each one.
According to authors the foundation is a core CIM layer, which
... comprises of the raw industry published models such as the TeleManagement Forum's Shared Information Data model (SID) in telecommunication industry and the IBM financial services model names the IFW in finance industry which contains the abstract entities with attributes and relationships.
This layer is typically predefined, but can be slightly customized to add missing data definitions, relationships and unique name identifiers. This layer is usually contained in its own namespace(s) to allow service specification generation tools to maintain it as a separate base layer decoupled from additional CIM layers.
The core CIM layer is extended by a weaker CIM layer, which:
... encompasses the extended CIM entities which convey pure business meaning for existence ... the modeler needs to always visualize the manifestation of these elements in the Service interface and not include unless otherwise warranted from business perspective, further represent them through a well abstracted terminology.
The weaker CIM is an extension of the core CIM layer providing additional attributes, objects, relationships and interfaces. This layer contains the majority of business specific entities required for service implementation but missing in the core CIM. This layer is typically the most dynamic one and keeps growing as more functionality is added to services
Finally, the weakest CIM layer
... includes objects, attributes, interfaces, and methods which are required purely for integration purposes. For example the message header related entities, entities which are required for controlling the results, connecting the service operations and the weaker/core CIM layers. Note that this final layer must always co-exists with the lower weaker and core CIM layers, but are connected through the service operations.
The purpose of this layer is purely to support entities required for the implementation of integration and control functionality.
The article provides a very well defined multi-layered approach to adopting industry specific CIM models to SOA implementations. Proposed clear separation of core, service specific and integration specific extensions promotes a better overall maintainability of the semantic SOA model.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
1 comment
Watch Thread Reply