ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] The Open Group SOA Ontology

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Thu, 17 Jul 2008 14:31:41 -0400
Message-id: <487F900D.5060401@xxxxxxxx>
Toby Considine wrote:    (01)

> The observable facts that every new concept is turned into a buzzword, and
> that every new buzzword can be grafted onto this years shipping part numbers
> (can you say Enterprise Service Bus?)  does not mean that there are no new
> concepts, and that new approaches do not, can not deliver actual new value.    (02)

I agree with this.  In fact, sometimes just resurrecting an old approach 
can deliver actual new value.  The problem with IT in general is that 
the well-worked approaches are not seen as an "establshed element of the 
engineering domain" that is taught to all "information/software 
engineering" students (erroneously called "computer scientists").  It is 
not the only engineering domain in which the practice is dominated by 
fad, but it is the only one in which the "established base" doesn't 
exist, because it is discarded every 10 years.    (03)

> Every technology I have worked with started out solid, became hyped as the
> next new thing, was over marketed as the only new thing, was then discarded
> as over-hyped, and, finally, was then discovered to be useful and
> controllable, in the proper place.    (04)

That is true of my experience in electronics, but not true of my 
experience in information technology.  Most information technologies 
started out as engineering concepts that were a bit before their time 
(in terms of the requirements on the supporting hardware/software 
environment, or in terms of the demands and tolerance of the 
marketplace), and were initially unreliable and even somewhat 
mis-engineered.  They became solid as the experience and the environment 
matured (and in some cases drove the environmental improvement).  They 
were then adopted by major customers (which allowed the originators to 
recoup the engineering cost), and their proper place and use were thus 
discovered.  But then they were reliably built by several smaller firms, 
which drove down the price.    (05)

The last caused the major software (and in some cases hardware) 
providers to find a new (or more often rework an old) technology and 
hype it as a replacement for the "obsolescent" technology, in which they 
could no longer dominate the market.    (06)

How many "computer science" students, I wonder, realize that the amount 
of information of all kinds flowing thru relational databases with SQL 
interfaces is thousands of times the amount of information flowing in 
XML?  Or that 90% of G8 manufacturers do a significant part of the their 
supply-chain work using EDI/EDIFACT messages?  Those technologies have 
found their proper place, and have reliable implementations.    (07)

> SOA at some level is nothing more than OO writ big (nothing new there!)
> except with agent concepts (Agents are objects that are autonomous) except
> somehow, from all the small quantitative changes, something new has emerged,
> in the hands of careful practitioners, separated from the hype.    (08)

The problem is to identify first what "SOA" is.  Others have said 
correctly that SOA is a business architecture and a technical 
architecture, and it is not clear how they are related.    (09)

Taking the technical architecture only, we can say it is a "new" 
architecture for "dynamic distributed information systems", and then we 
must identify exactly what is the "new" element of distributed systems 
design that has emerged in SOA.    (010)

The basic concept of "webservices" is "remote procedure calls", which 
had its first implementations in the late 1970s.  What "object 
orientation" did to that around 1990 was to formalize the idea of 
"encapsulation" -- you may never have spoken to the guy who provided the 
service implementation and you don't need to know what it looks like 
inside; you only need to know the functions it performs and the 
interfaces that activate those functions.  (That it took the CORBA folk 
until 1995 to standardize the network interface and thus make 
encapsulation possible was not ignorance; it was market management -- 
compatibility breeds commodity, and CORBA had a high engineering cost.)    (011)

The OO contribution to distributed systems also included:
- the idea of "instantiation": that the same functions/interfaces could 
have multiple realizations, that a set of behaviors is a "class", and a 
  provider that exhibits that set of behaviors is an "instance" of that 
class.  So a client could be built to use a "class" of "service" and the 
provider "instance" could be supplied at deployment time (or even later).
- the idea of "interface reuse and extension" (mis-identified as 
"inheritance"): that the interface to one set of behaviors could be used 
as the interface to another set of behaviors that had technically 
different or enhanced functionality, and could be extended to provide 
additional interface elements to support the enhancements.    (012)

The idea of instantiation, in particular, led to a need for a client to 
"find" the agents/providers who were instances of a service/interface 
class.  The first vogue solution was the "broker" -- the source of all 
connections, to whom the client was wired.  The second vogue solution 
was the "directory service" -- the source of knowledge about instances 
-- and the "dynamic connection protocol", which was patterned on 
"Internet services" that were developed for the ARPAnet about 1980.    (013)

Once we got past broker control and moved to directory services and 
dynamic connection (late 1990s), the idea of autonomous peers became 
possible without the "middleware" architecture having to be aware of it. 
  Any agent can register service interfaces, and any agent can be a 
client of directory services and other services.    (014)

And about the time that effective directory services and dynamic 
connections were finally being deployed in the CORBA community, they 
were being deployed in parallel in the Java community.  But certain 
major vendors had no grip on that market, so "webservices" was invented 
to replace them. (The last sentence is not historically documented.)    (015)

So what is really new in SOA?    (016)

For one, concepts in "service/interface definition" in WSDL are improved 
over their counterparts in CORBA IDL and Java.  But this is a minor step 
forward.    (017)

In addition, the "directory service" concept has been expanded from "who 
has this interface?" to "who can perform this service?".  This is a 
major step forward.  It assumes, however, that the service is formally 
defined by something more than its WSDL interface.  At the moment, the 
in-place services seem to assume that the client business expert will 
use the directory service to find the service that is wanted, and the 
client's programmer will then build the tooling (using some rapid 
prototyping capability) to use that service.  To automate this process 
is academic research, just now becoming product.  Most products are just 
CORBA/Java directory services with window dressing.    (018)

The consequence of distinguishing the service from its interface is that 
the "dynamic connection" becomes more interesting -- the client needs to 
be able to bind its "conceptual interface" to the service (which is what 
the client software implements) to the explicit WSDL interface the found 
provider exhibits.  This is where the academic research really enter in. 
What (high-end) "broker" products do is to know about all the available 
interfaces to the same service, predefine the mappings and materialize 
interceptors to do the interface conversions.  (But the mappings have to 
be really simple.)    (019)

Most of the rest of the work in the SOA field is about three other concerns:
  - managing security: knowing the person/organization for whom the 
software client is the agent, passing credentials of the agent and/or 
the true client to the service provider, or to the directory service, 
and determining the validity of those credentials for the requested 
functions
  - managing quality of service: contracts, guarantees, priorities, 
response times
  - accounting for services when provided, which includes the 
possibility of payment    (020)

Initial work on the first two of these was being done in the CORBA and 
Java communities when the "webservices" hype hit.  Fortunately, the SOA 
community has attracted enough expertise to improve the work in both 
areas, with only a 3-5 year delay for getting the webservice 
implementations up and running.  The last is really new in the SOA 
community.    (021)

There is also work in the SOA community, the DMTF and other 
organizations on managing deployment and managing the health of a 
realized running SOA.  But that work is largely the continuing effort of 
a "network management" community that moved from "internet provider 
management" to "distributed systems management" about 15 years ago.  For 
them, SOA is just the current umbrella.    (022)

So I can agree with Toby that there are some new ideas emerging in SOA. 
  But most of the new ideas have not yet resulted in deployable 
technologies.  In a certain sense, we took 5 years off to reimplement 
everything we already knew about distributed systems, with some minor 
improvements, in "webservices", and then we *resumed* the research in 
these new ideas.  And IMO, that is why we are now seeing deployment of 
marginal improvements over 1998, with the addition/subtraction of 
certain major players.    (023)

What I am hoping to see out of the expert modeling activities in TOG and 
OASIS is, finally, a clear and organized presentation of the distributed 
systems design knowledge that has been accumulated in the last 30 years. 
  Such a presentation will be the textbook for an academic discipline, 
and the reference base against which future "breakthroughs" and "new" 
distributed systems technologies can be evaluated.  In that way, we will 
finally stop the recurring 5-year loss from reinventing the status quo 
with a new name and a new gimmick.    (024)

> Ontology and Services, to my mind, go hand and hand. Tell me what I am
> getting and what good it is. Tell me how to compare what you claim I am
> getting vs what the other guy claims I am getting. Give me a way to comapre
> them.    (025)

That is, "services" need "ontologies".  Yes.  But, to be really useful, 
the "ontology" must have two diverse goals:
  - it must be able to tell you, the human business expert, what you are 
getting, in a way that you can understand.
  - it must be able to tell your software that it matches the formal 
constraints on what you asked the software to look for, and in that 
case, it doesn't have to make any sense to you at all.    (026)

The real objective for the SOA technical community is the latter.  The 
current state is an approximation to the former.    (027)

-Ed    (028)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (029)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (030)

_________________________________________________________________
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    (031)

<Prev in Thread] Current Thread [Next in Thread>