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)
Rex,
I originally published a paper on a simpler version of this
problem in the August 1998 Computing & Control Engineering Journal,
published by the IEE (UK version of the IEEE) "STEP based data exchange
with legacy systems" (you can find it on-line at IEEE Explore, but it
needs a subscription). This was driven by the need to collect a coherent
package of product data from a series of different PDM and data systems.
My colleagues at Sowerby Research implemented a version of the system
for demonstration purposes, and then moved on to the next problem. (02)
Sean Barker
Bristol, UK (03)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> Rex Brooks
> Sent: 19 November 2007 14:06
> To: [ontolog-forum] ; Obrst, Leo J.
> Cc: [ontolog-forum]
> Subject: Re: [ontolog-forum] Legacy systems
>
>
> *** WARNING ***
>
> This mail has originated outside your organization, either
> from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
> Thanks Sean,
>
> 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.
>
> 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?'
>
> Cheers,
> Rex
>
> 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
> >
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
>
> _________________________________________________________________
> 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
>
>
> (04)
********************************************************************
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.
******************************************************************** (05)
_________________________________________________________________
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 (06)
|