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)
|