- From: Giovanni Tummarello <giovanni.tummarello@deri.org>
- Date: Sat, 1 Oct 2011 09:48:43 +0200
- To: Frank Carvalho <dko4342@vip.cybercity.dk>
- Cc: semantic-web@w3.org
Frank thanks a lot for the account, it is very rare at least for me to heard such interesting report dealing with actual deployments in production I know you've been around the list and so possily in love with the technology, so a devil's advocate question can be : do you feel confidently that you've explored alternatives to custom rdf development? e.g. have you explored the existing landscalpe of soa governance products before starting this custom effort ? are you aware of alternatives out there and would you still defend this choice? not hinting at anything :) just sincerely curious. thanks again. Gio On Thu, Sep 29, 2011 at 12:27 PM, Frank Carvalho <dko4342@vip.cybercity.dk> wrote: > Hi > > About 4 years ago I wrote about organising SOA using RDF. I thought that > if anyone remembers that, they might be interested in an update. > > I still work in the danish tax and customs, and our SOA development > program has now reached a mature stage, with 1000 webservice > definitions, 3000 endpoints, numerous operations environments and a > myriad of information to keep together. We also have to coordinate a > number of solution suppliers and operators, as we don't in fact build > our own solutions. This would probably never have succeeded without > resorting to semantic web technology. > > Four years ago, we used an eXist XML database as the core. This required > serialized RDF/XML to work, and was not efficient for querying. I > received many suggestions to move to a dedicated RDF database, but it > has taken a long time to do this, as the day-to-day work keeps > distracting us. > > Nevertheless, we eventually moved our metadata to a core using > OpenRDF-Sesame, and we have developed a suite of rdfizers/introspectors > based on a combination of ARQ and linux shell scripts, to feed the > metadatabase with fresh updates. > > The metadatabase is rapidly growing, but manages to tie together > information from UML, BPMN, WSDL and XSD code generation, documentation, > souorce code, service bus introspection, test suites and you name it > into an interconnected graph/database. > > With this metadatabase it is fairly easy to query questions like > > - "Which webservices from system X are failing?", > - "If I change UML Use Case UCY, which service endpoint may potentially > be affected?", or > - "If I change the datatype of XSD element Z, what is the total impact > on our webservices, documentation, source code and operation > environments?" > - "Where can I find the exact specification and documentation for > endpoint P?" > > or any other question of that sort. We have a metadata governance group > that are able to develop their own custom SPARQL queries, so that > requests of this kind from our business departments can be met. > > Metadata updating is all automatized, as manual updating is doomed to > fail! Metadata are produced as a spill-over from the specification work > that has to be done anyway. This means that the day-to-day work > automatically enriches the metadatabase. > > The move to Sesame enabled fast queries, multiple RDF backends, web > distribution, and also provides a workbench for the governance group to > develop new queries. > > I have noticed that there has always been a tremendous focus on > developing standard ontologies for this and that. I also noticed that > there was an initiative to develop a standard ontology for SOA. But in > my experience, the strength of our concept - in contrast to virtually > all metadata management products I have seen - is that we do NOT have a > fixed ontology. Each type of metainformation has its own ontology. And > this ontology is not even fixed. We make changes to the ontologies > whenever we like. If we add a new source of metainformation, we > typically also add a dedicated ontology for that type of source. > > This way we can keep the metadatabase dynamic and alive all the time, > and adapt to changing needs. I find it very hard to subscribe to fixed > ontologies, because they invariably always turn out to be a hindrance. > Of course this means that some SPARQL queries may have to be altered > too, when we decide to change something in an ontology, but this is a > very small price to pay for the ultimate flexibility. > > Best > > Frank Carvalho > Central Customs and Tax > Denmark > > > > >
Received on Saturday, 1 October 2011 07:49:32 UTC