Alexander Johannesen wrote:
> On 3/2/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>
>>There are many standard ontological layers that already exist.
>>Some are part of programming language platforms such as the Java
>>serialization implementation. There's the whole CORBA layer, that's
>>implemented by libraries available for lots of languages. There's SOAP
>>(cleans the crud off of a lot of things they tell me :-). There's
>>lots of choices.
>
> Hmm, are you sure you're referring to ontologies, and not just semantically
> rich abstraction layers? In ontologies you specify the realtionships between
> things and what they are far beyond simple structures and inheritance
> models.
I'm talking specifically about mappings from native programming objects onto
network representations that are semantically rich enough to reappear on the
other side as useful information, ready for use.
>>What features are you finding missing that you think make a generic
>>interface better?
>
> With this as everything else; it depends. We can go back to the previous
> example ;
>
> 1. buyFoodCheese() ;
>
> vs.
>
> 2. buyFood ( 'cheese' ) ;
>
> With 1, if you're a business that deals in cheese but now wants to offer
> pork, you need to extend and version that interface. With 2 you replace
> 'cheese' with 'pork' and in ontolgoy theory, everything should Just Work
> (TM).
In Java, with mobile code, I might write the following code to add Pork to the
set of foods that I sell.
public class MyService
extends PersistentJiniService,
implements BuyFoodCheese,BuyFoodPork {
... method implementations here...
}
Because I've added a new interface, I don't have to version the old interface.
Because I'm using the mobile code facilities in Java, I don't have to tell a
single old client about this change. The code they download includes a
codebase
which will cause them to find definitions of the new objects without the
application software needing to know that.
Because I've used an interface name that is richer in definition of available
activities, I don't have to have a secondary explanation somewhere on the
network, such as WSDL, to explain to the world what kinds of things my service
provides.
> Of course, reality is somewhat different but it gives you the advantage of
> dealing with the semantics of your 'types' (if you like) in a cleaner way,
> meaning your interface syntax and semantics don't change when your data
> semantics does. In some areas this is very valuable, for example in
> applications that constantly deal with new things; the ontology is governed
> by an external trusted party. Anne was talking about WS-CDL which seems to
> be a lever for this.
The implementation platform really is a factor here. As I discussed above, the
features of downloaded code in Java make #1 "Just Work". The problem with #2,
for me, is that it demands a secondary definition of the services possible
capabilities. What parameter types of 'buyFood' does your service actually
accept?
>>Are you using a language or platform that requires so much low level detail
>>manipulation that you have resorted to doing all the work because nothing
>>useful is done for you?
>
> No, but I do work in an area where there are no good business opertunities
> and hence we have to do this ourselves since no one sees any moneies in it.
> :) For some general things there are no problems, but in some specific
> critical areas of our business, we have to come up with pretty specific
> semantics. I don't want my interfaces to handle those semantics; I want a
> more general ontology level to deal with the relationships leaving me to
> worry about the business aspects of it (basically, what we need to do with
> those relationships).
One of the things that Java's mobile code does, is let you have a network
interface that is completely separate from the application interface, and
change
the network interface continuously.
Also, you might imagine that your network visible service actually exports a
interface defined such as #2 above, but that your registered services which
clients actually see are more like #1. The BuyFoodCheese service definition
would just be a smart proxy that provides a locally enumerated list of cheeses,
and uses the #2 interface to the remote service to buy cheese.
This means that you can leave your "service" alone for the general case, and
then deploy new network interfaces to that service which allow clients to find
specific subclasses/qualified types of services which they need.
>>Maybe you can talk about the specific features of your implemenation which
>>are addressed by other invocation layer implementations?
This should have said 'which are not addressed'...
> At this stage I'm not even quite sure of what you're talking about :) but
> based on my assumption that I do and from what I think you're saying, you
> already have ontology layers in place with a 80/20 interface? And that would
> be fine, but I'm not mapping from db to db, I'm already working in a Topic
> Maps environment where ontologies are a big part of data modelling, and I
> want to create interfaces that has a separation of data and the semantics.
>
> But hey, maybe what I'm doing is to far from general business reality that
> it doesn't really apply here. :0)
I'm interested in what specific features such as versioning, general client
upgrade issues etc. which drive you to not change an interface. I'm also
interested in what problems, or features fall out of your choice of
implementations.
I'd just like to understand your experiences and how they're driving your
decisions better.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
