This mail is publicly posted to a distribution list as part of a process
of public discussion, any automatically generated statements to the
contrary non-withstanding. It is the opinion of the author, and does not
represent an official company view. (01)
Sean Barker
Bristol, UK (02)
> Some of us advocate:
> 1) Unbundling/decomposing your existing systems over time
> into services. This is hard work and will be going on for a LONG time.
> 2) When new systems/applications are considered, design them
> as services, i.e., reusable discrete (as much as possible)
> components which can be composed to create new systems/applications.
> 3) Build services which are described semantically. This
> description can be initially a purely natural language
> description (implicit model), or an ontology (explicit
> model). In either case, you will need grounding in natural
> language descriptions: that need does not go away with the
> development of a logical model (you still need to describe in
> natural language what you mean by the logical expression, so
> humans can inspect both and gauge conformance of the logical
> description with the natural language description).
> 4) For existing (legacy) systems, you need to plan their
> evolution toward your semantic/SOA paradigm. All systems have
> a maintenance cycle. Transforming legacy systems to a new
> paradigm incurs such huge costs that you cannot typically do
> that. Instead, you must rely on the next bullet:
> 5) Abstracting functional/procedural calls into the legacy
> system (assuming you can do so, i.e., if the API is rich
> enough to support this; if it isn't and you just call the
> monolithic system and get its final results, this effort will
> not work). Create wrappers for these calls into the legacy
> systems. They become rudimentary services. But most legacy
> systems are not amenable to this, so you must focus on the
> next bullet:
> 6) For standalone, monolithic legacy systems (which you
> cannot create functionally distinct calls into), then you
> must wrap the whole system, i.e., treat the whole system as a
> single service and try to create a semantic model (ontology)
> for what that system is doing. The system may or may not use
> a distinct database. (03)
May I add (04)
7) Encapsulate multiple legacy systems, using some form of "active
encapsulation", such that a service request is fulfilled by taking
information/functionality from multiple legacy systems. Here, the active
encapsulation agent has the role of decomposing a service request into
calls to each legacy system and composing the response. (05)
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
******************************************************************** (06)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (07)
|