Designing Data has been, for ages, the cornerstone for all applications. It relates to all information needed and shared between the applications. This is no different when we look at the SOA world. Actually it starts to get even more important. First of all, for what data is a Service responsible? And secondly what information is shared between the Services.
The first part is all about the definition of a data model, as (mostly) used in a database. This definition is used for storing the information and assuring validity. The second part is about the definition of XML documents, as used in the definition of Services boundaries, this data is more fluid floating around between services.
Now what makes a good Data Designer? In the Database world it took us a while to learn how to define a thorough data model. It is not only about WHAT data is needed but also HOW the data is used. What type of queries are to be expected. What are the quantities of the data per functionality. How is the data related to one another, etc. A lot of 'old fashioned' techniques, like NIAM, helped is us in the past in defining a good data model.
When I look at the XML world, to my surprise, a lot of the 'good old designing tricks' are forgotten. In projects I come across XML definitions (coming from standard organizations), which are bound to fail in practice. Yes, all the data needed for the functionality is there (the WHAT question). The HOW question, however, most of the times, is completely forgotten. In theory it looks very beautiful creating an XML tree containing all functionality needed in the world. In practice this means, most of the time, that the ratio 'actual needed data' to 'Total data send' is less the 5%. This puts a burden on performance and network load.
It is excellent that one XML Document can contain all the information needed to share across all the services, but in practice this means that when you change one part of it, all services need to be changed.
With the ever increasing need for exchanging data it becomes essential that we should aim for a methodology for designing XML documents. In the meantime, let's first use the KISS (Keep it Simple Stupid) principle, and see if the XML design really works in practice, on both a functional and usage level. Only after that start looking at reuse.....
Abonneren op:
Reacties posten (Atom)
Labels
11G
ADF
Architceture
Architecture
BAM
birdwatching
BPMN
Business Process Management
Business Rules
Capgemini
Case Management
CEP
Coherence
CORA
cradle to cradle
crane
Data Grid
Data Refinery
Design
EDA
Event
Forms
Green label
IT
Modernization
Open Source
Open Standards
Oracle
Power grid of applications
Process
Revitalize
Risk
roadmap
SBA
SCA
SOA
Software Archeology
Software Engineering
Stability Based Architecture
Strategy
Sun
Sustainable society
unen
Vendor Based Technology
XML
About me
Link
- www.elzmiro.com
Geen opmerkingen:
Een reactie posten