Thanks Sean, (01)
Your addition below is something I have not yet attempted, as is
number 5 from Leo's list. I would like to find someone interested in
doing this since I certainly don't have the time to work out the
details of wrapping large existing legacy systems in such a way that
preserves existing datastructure and data model and extracts the
information (name-value pairs) for semantic processing separate from
the application/system. (02)
Failing to extract the information means the results of large legacy
systems can only be used from within those systems or extracted
"manually." However, I believe it is possible within those wrapped
legacy systems to have data sent to smaller applications within that
system (like plain text, comma delimited lists). So reprocessing that
information is possible even if it is a messy kludge or is that
'sludge?' (03)
Cheers,
Rex (04)
At 10:55 AM +0000 11/19/07, Barker, Sean (UK) wrote:
>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.
>
> Sean Barker
>Bristol, UK
>
>
>> 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.
>
>May I add
>
>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.
>
>********************************************************************
>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.
>********************************************************************
>
>
>_________________________________________________________________
>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
> (05)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670 (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)
|