Hi Ken, (01)
I guess this is what I get for posting half-completed thoughts... :) (02)
Thanks very much for your comments. I've tried to make some
clarifications below. Your perspective is very interesting. (03)
Anyone who doesn't really care about this can stop reading now. It's
only going to get weirder... (04)
On Sat, 2006-04-08 at 19:15, Ken Laskey wrote:
> Your information oriented approach seems to go back to OO roots in
> that the data object (and specific instances of it) is the thing and
> its associated methods are actions you can do with it. (05)
This statement really intrigues me, because I don't see what I was
talking about as objects at all. Of course, maybe it makes more sense
in my head than it did when it was written down. (06)
In what I was talking about, I was leveraging the four HTTP verbs
(methods): GET, PUT, POST & DELETE. The thing about a uniform
interface is that it's easy to understand and implement. Yes, your
behavior is somewhat context dependent, which can cause other problems,
but at least you have the basic connectivity and operations sorted with
just those. (07)
> So from an SOA standpoint, we need to do several things. First, we
> need to provide a way to have more functions to do things with the
> data than just its associated methods. (08)
I guess I would ask a clarification question here: do we need to do
more things *to* the data or *with* the data? This is why I don't see
it as an object. The way I'm starting to see this (as part of my "what
moves?" epiphany) is that an entity makes data available. It is just
there, raw and in the flesh, so to speak. It is nothing without
operations to use it, but those operations aren't supplied by the entity
providing the data. (09)
What really matters to the community is that there are meaningful
operations that can be developed which process the information and
generate more information which is to the benefit of the community. How
this happens isn't really the focus. Instead the focus (and test of the
legitimacy of the actor/service) is if the operations increased the
value of the information to the community by either augmenting it or
using it to create new information. (010)
If this is true, you have two kinds of "citizens" in your community: (011)
1) information (012)
2) operations (013)
But the key is that the operations are not tied to the data. They may
even be one-off things (think shell scripts or shell scripts 2.0:
service mash-ups), but if they provide value to the community or its
members, that's ok. Certainly if the data is expressed in a private
vocabulary, you'll need the ontolog(y|ies) at this stage to increase its
usefulness to other operations, but from a movement point of view, the
operations "move" to the data rather than in a traditional system
(messaging, SOA or even OO) where (more often than not) the data "moves"
to the operations/service. (014)
This concept is manifested most prominently in physical messaging
systems like MQSeries, JMS and even how most people think of the Web.
You GET the data on the web page and you POST it to somewhere else. The
POST case is a bit fuzzy, but you could really argue that you didn't
need to POST the whole resource, just a reference to one that you'd
already PUT somewhere. However, the GET case is somewhat easier. What
really happens when you GET a URI? You transfer a representation of
that URI from where it lives to your system. However, that resource
still exists where you got it from--that's why GET is supposed to be
idempotent. In fact, if you're doing proper content negotiation, you
may not even be GETting the actual resource, you may only be getting
what you asked for: PDF vs. HTML vs. Atom feed. (015)
> The data object is very much "owned" by someone and the private
> methods are what the owner can do that the public cannot. And if the
> owner doesn't give you the ability to manipulate the data in some way,
> you are out of luck. The data steward approach requires the
> functional flexibility of SOA. (016)
You're right about the data ownership, and this is the crux of what I'm
talking about. Ok, I guess I'm going to use HTTP a lot because it's
easiest and most people can relate to it, but it doesn't have to be
HTTP. (017)
I 100% agree with you: flexibility is the key aspect here. I would
challenge you to think about which is the most flexible: (018)
A list of product descriptions, prices, pictures, availability, etc.
published at a known location, e.g. http://seller.com/catalog/ and which
could be retrieved using exactly the same operation (019)
GET http://seller.com/catalog/ HTTP/1.1
Accept: text/html (020)
==> The human-facing web catalog with all the photos, banner ads and
chrome (021)
GET http://seller.com/catalog/ HTTP/1.1
Accept: application/atom+xml (022)
==> The Atom feed of the same information that you can process with an
application, view in a news aggregator or whatever. (023)
This information could also be automatically retrieved using information
in the above case (point your favorite aggregator at my blog's home page
and it will automatically pick the right feed type--or it should). (024)
GET http://seller.com/catalog/ HTTP/1.1
Accept: application/pdf (025)
==> The full-color, glossy, print-ready catalog (026)
The list is effectively endless. You're just asking for what you can
understand based on somehow knowing that a product catalog is located at
http://seller.com/catalog/ (027)
Or, the alternative RMI/SOAP/Whatever method equivalent of: (028)
List products = Seller.getCatalog(); (029)
I know from past experience that it's always easier to build the latter
based on something like the former than to try and extend the semantics
of a method call across any number of platforms. The mechanics have
been solved many times with many technologies, but I think the reason we
keep refining the basic concept is that we're trying to solve the wrong
problem. (030)
Ultimately, you need to know which one of the 10 billion possible
methods, technologies and assumptions were made by the programmer
implementing the Seller interface will give you what you want. You've
got to perform the mapping in your code (or code called by your code),
meaning you've instantly bound some part to the remote party and
assumptions about what you need right now. Sure, there are ways around
this, but these add even more complexity. (031)
In this case, your focus is on the mechanics because that's what is hard
and that's what you code. In the first case, your focus is on what you
want: the information, e.g. the product list. How you get it is not
complicated (or it doesn't have to be). (032)
Another of the main problems is that not many people build applications
this way, so, right now, these things aren't as easy as they could be.
Still, if I can go to any location and attempt to retrieve the
information there in a consistent manner, I can focus on finding and
processing the information rather than what I need to do to get it. (033)
Maybe I'm not making much sense.... (034)
However, you are right. It is "my" information and I can choose to make
it available or not. Still, a service interface doesn't help you here
either because it's still "my" service and I can show it to you or not.
I'm just saying that if I show you "my" information that matters to me
in some way, you can choose to interpret, use, aggregate or whatever
that information as you see fit. I don't have to do anything special to
allow you to compute the average price, figure out how many are blue,
compare my highest price to that of my competitors. I am enriching the
community by providing you access to my information. (035)
Of course, you need to factor in the legitimacy issues here: what you
can/can't access based on levels of trust, identification, contractual
agreements, etc. These are easily controlled in either the way I
represent the information to you because I know who you are, or what I
choose to let you access based on who you are. If I don't like you, I'm
not going to let you POST bids to my auction. There's nothing you can
do about it. But if I do, you can do it in a consistent way for bids
for products, messages to bulletin boards, annotations to product
catalogs or whatever. (036)
Think about how useful pipes & filters are in a UNIX environment. This
sort of thing is the power of a standardized interface. Yes, sometimes
it's a pain, but that may mean you just need another filter. (037)
> And while information is critical, having information is not enough.
> The question getting the most attention right now is what are you
> trying to accomplish and how can you do it. Part of the answer is
> knowing what information exists and how to get hold of it.
> Information by itself has limited use -- it is how you find it and
> combine it that is the dominant challenge (at least today). (038)
I'm not saying the information is useful on its own (at least I don't
think I did). It is only useful when it's used, but it can't be used if
it isn't available. You're right though, the "how do you find it?" is a
real problem--in any of these systems, otherwise LDAP, UDDI, ebXML RR or
Google wouldn't exist. (039)
I said before I didn't have all the answers. I'm certainly not claiming
to now either... :) (040)
>
> Your thoughts on semantics are where my initial engagement with the
> group left off. For all the talk of Communities of Interest (COIs)
> and common vocabularies, groups have their own vocabularies (i.e.
> jargon) to suit the needs of communicating in the group and for the
> purposes that the group exists. I have long advocated the need for a
> Mediation/Semantic Negotiation/(pick a name) service that helps
> connect vocabularies. A broker is a prime example of the user of such
> a service. Your buyer should be able to make requests in its
> vocabulary and have answers come back in its vocabulary. The seller
> should be able to get requests from any buyer in the *seller's*
> vocabulary because how else can the seller best understand what the
> buyer wants. I want my seller to concentrate on their business of
> supplying value through products and business services and I want the
> buyer to concentrate on getting things that will enable them to supply
> value through their products and business services. The broker needs
> to be able to deal with buyers and sellers using a variety of
> vocabularies and to combine results from a number of sources to give a
> meaningful answer. None of these should have to deal with the
> esoteric details of translating vocabularies and deriving meaning. (041)
Exactly, but I think the information-centric approach facilitates this
through essentially being selfish on the part of each participant. For
example, they might say: (042)
"I'm going to tell you what I want or what I have, however I want to do
it. I'm hoping you can make use of it. If I need it urgently, well, I
guess I can interact with you and/or go looking, but otherwise, it's
your problem, not mine." (043)
>
> As an aside, while it is very appealing to say, "Let's just all agree
> on what we call things," (and this should be used whenever it can be
> successful), the basic process of doing this doesn't scale. My
> diagram for attempts at doing this is the following (I hope the paste
> shows up at your end) (044)
Image came through fine. Yeah, we've seen this sort of thing with my
current project. I think we've done pretty well, but there's a project
in the pipeline which will have major issues with communication of core
concepts. However, I think it really is a business problem on some
level. The selfish approach mentioned above only works to a point. If
everyone is only looking out for themselves, there's no benefit to the
community. People must make some sort of effort, so maybe a better
approach would be to say it's a "lazy" approach rather than "selfish". (045)
Why I say it is a business problem though is that if without IT systems
two organizations need to communicate and they can't agree on or explain
the information they are providing and expecting someone else to use,
this is not in the interests of the community. We're back to both
participants lose, get frustrated or are at best unproductive. Some of
it isn't really solvable with the most magic ontology in the world--it's
a human problem. (046)
> Yes, the Semantic Web has a focus for capturing and transmitting
> meaning and ontology work (of which OWL, the Web Ontology Language is
> a part) deals with formalism for representing knowledge and inferring
> additional knowledge from the stuff explicitly captured by the
> representation. Advances here should surface as (to use SOA-RM
> concepts and wording) the underlying capabilities to which services
> will provide access. In other words, this is where your mediation
> services come from. (047)
I guess I see two things. The services are really loose things which
are only meaningful when applied to information (all or in parts), and
the information and its availability are the most important things
because this is what enables useful services. (048)
I'm probably not saying this very well because you've essentially the
same bits, but you and I are seeing it from different perspectives. I
do think the perspective alters the implications and the problems,
though. (049)
> One last thought (again from SOA-RM): in SOA, services are the
> mechanisms by which needs (e.g. your buyer) and capabilities (e.g your
> seller) are brought together. (Adding the intermediary of the broker
> doesn't add anything but an entity with both needs and capabilities.)
> SOA does not provide any domain elements of a solution that do not
> exist without SOA. I like to say that SOA provides the business
> service of connectivity. (050)
I'm not sure that I follow this completely. I think Cory's introduction
of the community aspect of SOA (introduction to me at least, maybe not
everyone else) is really important because that's really what you end up
with. I know that if I think about it this way, that's really what
we've created around our SOA in Ireland. It may not be obvious to
people in the way they view it, however. (051)
> Well, this has gone on linger than I anticipated. I hope it provides
> some value. (052)
Absolutely! Thanks very much for taking the time to respond. Maybe
I've lost my mind, but I hope at least some of my response fills in some
of the blanks. At worst it is just a "pot-A-toe"/"po-TA-toe" thing and
it's not important. At best, it does really matter and it may solve
some of the issues (or at least helps someone with a bigger brain solve
them). Then we just need to worry about which problem we've promoted to
#1. (053)
ast (054)
> Ken
> On Apr 8, 2006, at 12:27 PM, Andrew S. Townley wrote:
> >
> > All,
> >
> > I've been pulling some various threads of thought together over the
> > last
> > couple of days, and I've written some of them down. They're
> > relevant to
> > some of the more further afield discussions we've been having, so I
> > don't want to drop it all into a mail. Our main focus should be
> > about
> > the demo.
> >
> > However, I would appreciate the thoughts of the collective brain
> > power
> > here as we've all been part of the same discussions. You can feel
> > free
> > to send comments to me directly, add them to the blog or whatever
> > you
> > see fit. I am very interested in any feedback you may have.
> >
> > The post is here:
> > http://atownley.org/2006/04/information-oriented-architecture-ioa/
> >
> > Cheers,
> >
> > ast
> > --
> > Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking
> > at
> > InfoSeCon 2006. For more information, see www.infosecon.org.
> >
> >
>***************************************************************************************************
> > The information in this email is confidential and may be legally
> > privileged. Access to this email by anyone other than the intended
> > addressee is unauthorized. If you are not the intended recipient of
> > this message, any review, disclosure, copying, distribution,
> > retention, or any action taken or omitted to be taken in reliance on
> > it is prohibited and may be unlawful. If you are not the intended
> > recipient, please reply to or forward a copy of this message to the
> > sender and delete the message, any attachments, and any copies
> > thereof from your system.
> >
>***************************************************************************************************
> > _________________________________________________________________
> > Subscribe/Unsubscribe/Config:
> > http://colab.cim3.net/mailman/listinfo/soa-forum/
> > Shared Files: http://colab.cim3.net/file/work/soa/
> > Community Portal: http://colab.cim3.net/
> > Community Wiki:
> > http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
>
> ---
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-983-7934
> 7515 Colshire Drive fax: 703-983-1379
> McLean VA 22102-7508
>
>
>
>
> ______________________________________________________________________
> _________________________________________________________________
> Subscribe/Unsubscribe/Config:
>http://colab.cim3.net/mailman/listinfo/soa-forum/
> Shared Files: http://colab.cim3.net/file/work/soa/
> Community Portal: http://colab.cim3.net/
> Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
--
Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
InfoSeCon 2006. For more information, see www.infosecon.org. (055)
***************************************************************************************************
The information in this email is confidential and may be legally privileged.
Access to this email by anyone other than the intended addressee is
unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If
you are not the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments, and any copies
thereof from your system.
***************************************************************************************************
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (056)
|