Agree that we mostly agree. :) (01)
Apologies if I got off track a little, but it wasn't clear to me from
your first posting that you weren't talking about concrete
implementations. Again, I think we're struggling with agreement on the
meaning of words, not necessarily that the concepts we're trying to
explain are that different. I suppose this means that there's going to
be a fair bit of work to be done before there's any level of wide
agreement on any proposed ontology for SOA. (02)
Standardizing on a fixed ontology too soon may hamper people's ability
to put SOA into their own particular context, but not doing it soon
enough clearly makes it difficult for people to effectively
communicate. I'm not really sure where we are on this particular
spectrum, but it seems to me, based on the people I've talked to, that
while a lot of people are talking about SOA and trying to figure out
what it really means to them, I'm not sure there's enough consensus yet
to build an effective and widely accepted ontology based on common
understanding. Thus far the attempts of defining an ontology don't seem
to be getting enough traction, regardless of the source. Maybe the
timing isn't yet right. Again, this is essentially the argument of
"standard" vs. "specification". (03)
I realize this line of thinking doesn't advance the original topic too
much, but I think it's a point that's necessary to acknowledge. (04)
Happy Holidays, (05)
ast (06)
On Sun, 2006-12-24 at 05:45, Ken Laskey wrote:
> more inline below. I think we have a lot of agreement.
> On Dec 23, 2006, at 4:52 AM, Andrew S. Townley wrote:
> > Hi Ken,
> >
> > A couple of things in-line.
> >
> > On Fri, 2006-12-22 at 23:47, Ken Laskey wrote:
> > > Andrew,
> > >
> > > As I said, this is a draft, so I am open to what things are named.
> > >
> > > What I think is important is to separate the idea of the business
> > > services for which the underlying capabilities exist outside of
> > > SOA
> > > from the connectivity provided by SOA. There are two reasons for
> > > this:
> > >
> > > 1. I think it is important to emphasize that if one does not have
> > > a
> > > solution to a problem without SOA, it is unlikely SOA will provide
> > > a
> > > miracle. SOA provides a potentially effective connectivity
> > > mechanisms, but there needs to be things to connect and other
> > > connectivity options may be more appropriate for a given problem.
> >
> >
> > I completely agree with the notion here that SOA is not magic,
> > however I
> > personally wouldn't relegate SOA to just "effective connectivity
> > mechanisms". Connectivity is part of it, but to me it also implies
> > a
> > certain amount of re-thinking and restructuring in the way that the
> > functionality of any existing or new system is exposed within the
> > SOA.
> > Connectivity is the least important part of service design, but I
> > agree
> > it is important in actually interacting with the service. :)
>
>
> SOA certainly introduces a new paradigm but here I am concentrating on
> what the service specifically provides, not how one could use it to
> enable more flexibility in composing solutions. (The concepts
> expressing that wider use are included in the SOA-RM.) We could
> unpack what I include in connectivity but it is important to see how
> SOA makes "pieces" more usable and does not replace domain expertise
> in developing the "pieces".
>
> >
> > > 2. When we talk about SOA, we focus on what SOA is supposed to
> > > provide and do not conflate the business elements of the
> > > solution.
> > > This separation of concerns should lead to better design and
> > > development of the separate pieces.
> >
> >
> > Yes and no. I think you can be successful taking a number of
> > different
> > approaches to creating your SOA. In one approach, you have a 1:1
> > relation between a business function and a technology
> > implementation.
> > Over time, you can then alter the implementation of that technology
> > service to isolate more and more granularity into more and more
> > services, but only when it becomes needed within another context.
> > This
> > is the same approach as you'd use in iterative design and refinement
> > of
> > any complex code module, so it isn't anything new.
> >
> > The other approach is to try and identify those common things all in
> > advance and build the framework from the bottom up. While this is
> > possible if you have a strong enterprise architecture in place and a
> > really good view of your existing systems (or you're starting from
> > scratch), I think this can be harder to do. I do believe that
> > sufficient up-front design and consideration of core functions and
> > messages will give you a better result overall, but sometimes it
> > just
> > isn't possible to get agreement or it is seen as trying to eat the
> > elephant all at once. In practice, you'll probably end up with some
> > of
> > both going on and need someone to provide the governance and
> > oversight
> > to ensure it doesn't end up an incoherent mess.
> >
> > I guess overall I'm not disagreeing with you, but I think that you
> > can't
> > really separate the business elements from what you're referring to
> > as
> > "the SOA" too much. If you do, you're going to end up doing those
> > things that are the "quick wins" for "the SOA" because they're easy
> > to
> > do (in both scope and cost), but these may not really do much to
> > enable
> > the organization. I think that if you can make this link as direct
> > as
> > possible and have that awareness propagated from the CIO or the EA
> > down
> > to the individual developer, you're going to end up with better
> > services
> > and core functionality that is both defined in terms of the business
> > and
> > more aligned with the ways the business can change. I'm not saying
> > that's easy to accomplish, but I think it should be the goal.
>
>
> I think we are in basic agreement. What I see too often and am trying
> to avoid is confusing the discipline solution (having nothing to do
> with SOA) with a possibly effective implementation mechanism. I have
> seen too many instances where generating large numbers of "services"
> with questionable value is given as proof of having a SOA. This
> satisfies neither of us.
> >
> > > I need to reread WSA but I don't remember the separation I propose
> > > to
> > > be in conflict.
> >
> >
> > I wasn't trying to imply that it was in conflict exactly, but based
> > on
> > your original two-level break-down, I was just saying that I think
> > there's an important intermediate one that would be missing. Maybe
> > it's
> > all about perspective and granularity, but I would see the following
> > distinctions involved:
> >
> > Business Service: a function or capability which directly
> > contributes to
> > the operation of the organization. It may be implemented by any
> > combination of human and computer interactions, including totally
> > people-centric. Can and often does have explicit QoS requirements.
> >
> > Abstract (Technology) Service: a function or capability that is
> > specifiable in terms of the specific messages (including any
> > exceptions
> > and responses), QoS and the side effects or changes that are a
> > consequence of using it.
> >
> > Concrete (Technology) Service: a specific implementation of the
> > Abstract (Technology) Service using products, programming languages,
> > and
> > other specific technologies.
> >
> I am talking about the first two. The reference model is meant to be
> abstract and so does not deal with the third.
> > The way I would see it is that a Business Service would require 0 or
> > more Abstract (Technology) Services in order to actually work. Each
> > Abstract (Technology) Service would have (eventually) 1 or more
> > Concrete
> > (Technology) Service implementations available to the enterprise,
> > but
> > because they were all defined in terms of the Abstract (Technology)
> > Service, you could have different implementations based on
> > Vendor/technology, e.g. Java or .Net, or QoS or physical location or
> > whatever. This allows you to make some important enterprise
> > architecture and 3rd-party vendor selection decisions without
> > disrupting
> > your overall architecture.
>
>
> I don't think anything I've said conflicts with this.
> >
> > In actually trying to direct the architecture of a live SOA for two
> > years, I think the distinction between the abstract and concrete
> > technology service is an essential part of creating an SOA. There's
> > a
> > bunch of ways to accomplish it, but I just wanted to stress its
> > importance.
>
>
> The OASIS SOA-RM TC now has a subcommittee working on a reference
> architecture. I'd invite you to contribute your experience to that
> work.
> >
> > > Ken
> > >
> > > On Dec 22, 2006, at 5:23 AM, Andrew S. Townley wrote:
> > > > Hi Ken,
> > > >
> > > > With references back to Brad's granularity discussion, I still
> > > > find
> > > > the
> > > > idea of the W3C WSA's abstract and concrete services very useful
> > > > in
> > > > practice when you're trying to address the ideas of
> > > > interoperability,
> > > > QoS and functionality vs. a particular implementation of that
> > > > functionality. I'm not that big on a lot of the rest of the
> > > > document,
> > > > but I think this is very good once you are talking about
> > > > implementing a
> > > > business service as an IT deliverable.
> > > >
> > > > However, I don't think "SOA service" is the best name for what
> > > > you've
> > > > described. I'm not too sure what is at the moment, but I'll
> > > > give it
> > > > a
> > > > bit more thought. Off the top of my head, maybe "IT service" or
> > > > "technology service" or something like that. Like I said, I'll
> > > > give
> > > > it
> > > > more thought, but I don't think there's a clear enough link from
> > > > "SOA
> > > > service" to "IT artifact" based on many of the underlying
> > > > assumptions in
> > > > people's heads about what SOA means to them, based on where they
> > > > are
> > > > and
> > > > what they're trying to do with it.
> > > >
> > > > I think it's also fair to say that things like QoS metrics can
> > > > also
> > > > be
> > > > applied to people-oriented or at least interactive human/machine
> > > > business processes as well, e.g. "The turnaround for a customer
> > > > callback
> > > > after receiving a support request email must be within 1 hour",
> > > > so
> > > > I'm
> > > > not sure that's a sufficient enough differentiator either. In
> > > > the
> > > > above
> > > > case, if there's not enough people to support the volume of
> > > > calls,
> > > > you're going to add more people, not technology to improve the
> > > > QoS
> > > > of
> > > > the business service. I know you know this, but I think it's
> > > > important
> > > > to reiterate.
> > > >
> > > > However, I do agree that there needs to be a good way to
> > > > determine
> > > > where
> > > > the line is between the abstract and the concrete IT
> > > > implmentation
> > > > based
> > > > on some agreed definition. I'm just not sure that you'll get
> > > > much
> > > > traction with "SOA service".
> > > >
> > > > I haven't had a chance to look at the ontology yet, but I hope
> > > > to
> > > > get a
> > > > chance to do this over the Christmas break.
> > > >
> > > > Cheers,
> > > >
> > > > ast
> > > >
> > > > On Fri, 2006-12-22 at 00:49, Ken Laskey wrote:
> > > > > One thing not addressed in the OASIS RM is to specifically
> > > > > differentiate between a "business service" and a "SOA
> > > > > service". I
> > > > > have a draft white paper on this that I never quite get around
> > > > > to
> > > > > finishing but in general it appears useful:
> > > > >
> > > > > - to use the OASIS RM idea of a SOA service to provide access
> > > > > to a
> > > > > capability, and
> > > > > - to relate the business service with the capability to which
> > > > > the
> > > > > SOA
> > > > > service provides access.
> > > > >
> > > > > In particular,
> > > > >
> > > > > A business service is the functionality invoked in using a
> > > > > capability
> > > > > designed and implemented to address certain needs, i.e. the
> > > > > solution
> > > > > to a business problem. It implies actions. The real world
> > > > > effects of
> > > > > using a business service are changes to the public aspects
> > > > > and/or
> > > > > the
> > > > > user’s private aspects of the world in a way that has some
> > > > > positive
> > > > > impact on those needs. The user may not be aware of private
> > > > > impacts
> > > > > on others.
> > > > >
> > > > > A SOA service is an IT artifact (i.e. a thing) that makes
> > > > > possible
> > > > > the
> > > > > efficient connectivity between consumer needs and provider
> > > > > capabilities. It provides a mechanism to access the
> > > > > capability of
> > > > > a
> > > > > business service and to realize some subset of the real world
> > > > > effects
> > > > > gained by interacting with the SOA service to access the
> > > > > business
> > > > > service. As implied, the SOA service is not required to
> > > > > enable
> > > > > access
> > > > > to all of the underlying capability’s potential real world
> > > > > effects. In
> > > > > operational use, the SOA service is the entity that must
> > > > > conform
> > > > > to
> > > > > such things as quality of service (QoS) metrics and the thing
> > > > > to
> > > > > be
> > > > > fixed if these metrics are not met.
> > > > >
> > > > >
> > > > > Comments welcome.
> > > > >
> > > > > Ken
> > > > >
> > > > >
> > > > > On Dec 21, 2006, at 9:20 AM, Brad Cox, Ph.D. wrote:
> > > > > > > definitions of SOA are currently broadening to the point
> > > > > > > where
> > > > > > they
> > > > > > > are not particularly useful any more.
> > > > > >
> > > > > >
> > > > > >
> > > > > > The same debate raged in the 90's as to the 'real' meaning
> > > > > > of
> > > > > > 'object'. Of course the term is just as ambigious in
> > > > > > everyday
> > > > > > life
> > > > > > where the term originated and where it means quite different
> > > > > > things
> > > > > > at different levels of granularity (subatomic, atomic,
> > > > > > molecular,
> > > > > > biological, astronomical, etc).
> > > > > >
> > > > > > Seems to me we could add a lot of clarity by specifying what
> > > > > > level
> > > > > > of granularity "service" is being applied to. The article
> > > > > > applies it
> > > > > > at the enterprise level so service = an organizational
> > > > > > capabilitiy.
> > > > > >
> > > > > > Several levels below that is the application level, where it
> > > > > > means a
> > > > > > network-resident computer program; the meaning most
> > > > > > technical
> > > > > > folk
> > > > > > have in mind. Below that are the POJO objects from which
> > > > > > applications are usually composed these days (locally
> > > > > > accessible
> > > > > > objects that are not on the network).
> > > > > >
> > > > > > PS: I once tried to get traction on applying hardware
> > > > > > engineering
> > > > > > terminology in software but that never caught on. Gate-level
> > > > > > objects
> > > > > > = plain C functions, chip-level = C++/Java objects,
> > > > > > card-level =
> > > > > > SOA
> > > > > > services, and so forth. So it goes...
> > > > > >
> > > > > >
> > > > > >
> > > > > > Joshua Lieberman wrote:
> > > > > > > Dr. Harding,
> > > > > > > Your interest in feedback for an SOA ontology is
> > > > > > > appreciated,
> > > > > > > but
> > > > > > > taking a quick look at the definition of SOA on which it
> > > > > > > is
> > > > > > > based,
> > > > > > > I have to raise the question why it includes only two of
> > > > > > > the
> > > > > > > three
> > > > > > > legs on which service-based architecture was developed.
> > > > > > > The
> > > > > > > role
> > > > > > > of service discovery, trading, and matching is
> > > > > > > conspicuously
> > > > > > > absent. Indeed, this makes the ontology perfectly suitable
> > > > > > > for
> > > > > > > modeling any application stovepipe and fails to explain
> > > > > > > why
> > > > > > > efforts at interoperability, in fact at the
> > > > > > > information-hiding
> > > > > > > aspects of services at all, are important.
> > > > > > > It would certainly be very interesting to learn whether
> > > > > > > this
> > > > > > > omission is deliberate or represents an intermediate stage
> > > > > > > of
> > > > > > > ontology development. It might also be a good topic for
> > > > > > > SICoP
> > > > > > > discussion. There is some question whether definitions of
> > > > > > > SOA
> > > > > > > are
> > > > > > > currently broadening to the point where they are not
> > > > > > > particularly
> > > > > > > useful any more.
> > > > > > > Regards,
> > > > > > > Joshua Lieberman
> > > > > > > Principal, Traverse Technologies Inc.
> > > > > > > mailto:jlieberman@xxxxxxxxxxxxxxxxxxxxxxxx
> > > > > > > tel +1 (617) 395-7766
> > > > > > > fax: +1 (815) 717-981
> > > > > > > On Dec 21, 2006, at 5:16 AM, Chris Harding wrote:
> > > > > > > > Hello -
> > > > > > > >
> > > > > > > > The Open Group is developing a formal ontology for SOA,
> > > > > > > > and
> > > > > > > > we
> > > > > > > > have
> > > > > > > > now reached the stage where we have a draft that we
> > > > > > > > would
> > > > > > > > like
> > > > > > > > to
> > > > > > > > share with other organizations that are working on SOA,
> > > > > > > > in
> > > > > > > > order
> > > > > > > > to
> > > > > > > > obtain feedback and comment. We believe that a common
> > > > > > > > ontology
> > > > > > > > for
> > > > > > > > SOA can be a very valuable resource for everyone to use,
> > > > > > > > and
> > > > > > > > we
> > > > > > > > therefore wish to receive input from as wide a
> > > > > > > > constituency
> > > > > > > > as
> > > > > > > > possible.
> > > > > > > >
> > > > > > > > I think that this will be of interest to the SICoP as
> > > > > > > > well
> > > > > > > > as
> > > > > > > > the
> > > > > > > > SOACoP, and we would appreciate input from both groups.
> > > > > > > > This
> > > > > > > > call for
> > > > > > > > input is going to both lists, and we would appreciate
> > > > > > > > comments
> > > > > > > > from
> > > > > > > > all members of them, either directly to me
> > > > > > > > (c.harding@xxxxxxxxxxxxx)
> > > > > > > > or to one or both of the lists. (Comments to both lists
> > > > > > > > will
> > > > > > > > generate
> > > > > > > > the best debate!)
> > > > > > > >
> > > > > > > > The current draft is draft 0.6 and is available from our
> > > > > > > > web
> > > > > > > > page at
> > > > > > > > http://www.opengroup.org/projects/soa-ontology/ together
> > > > > > > > with
> > > > > > > > some
> > > > > > > > simple example ontologies that import it. Perhaps the
> > > > > > > > best
> > > > > > > > starting
> > > > > > > > point is the presentation at
> > > > > > > >
>http://www.opengroup.org/projects/soa-ontology/doc.tpl?gdid=12153
> > > > > > > > which I delivered at the recent OMG meeting. This
> > > > > > > > explains
> > > > > > > > the
> > > > > > > > ontology and how we think it will be used.
> > > > > > > >
> > > > > > > > We will produce a new draft in January, and will address
> > > > > > > > the
> > > > > > > > comments
> > > > > > > > in that draft.
> > > > > > > >
> > > > > > > > All the best for Christmas and the New Year!
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Chris
> > > > > > > > +++++
> > > > > > > >
> > > > > > > >
>========================================================================
> > > > > > > > Dr. Christopher J. Harding
> > > > > > > > Forum Director for SOA and Semantic Interoperability
> > > > > > > > THE OPEN GROUP
> > > > > > > > Thames Tower, 37-45 Station Road, Reading RG1 1LX, UK
> > > > > > > > Mailto:c.harding@xxxxxxxxxxxxx Phone (mobile): +44 774
> > > > > > > > 063
> > > > > > > > 1520
> > > > > > > > http://www.opengroup.org
> > > > > > > >
> > > > > > > > Enterprise Architecture Practitioners Conference
> > > > > > > > Marriott Mission Valley, San Diego, CA, January 29 - 31,
> > > > > > > > 2007
> > > > > > > > Member Meetings: January 29 - February 2, 2007
> > > > > > > >
><http://www.opengroup.org/sandiego2007/>http://www.opengroup.org/sandiego2007/
> > > > > > > >
>========================================================================
> > > > > > > > TOGAF is a trademark of The Open Group
> > > > > > > >
> > > > > > > >
>_________________________________________________________________
> > > > > > > > Message Archives:
> > > > > > > > http://colab.cim3.net/forum/sicop-forum/
> > > > > > > > Shared Files: http://colab.cim3.net/file/work/SICoP/
> > > > > > > > Community Portal: http://colab.cim3.net/
> > > > > > > > To Post: mailto:sicop-forum@xxxxxxxxxxxxxx
> > > > > > > > Community Wiki:
> > > > > > > > http://colab.cim3.net/cgi-bin/wiki.pl?SICoP
> > > > > > >
>------------------------------------------------------------------------
> > > > > > > _________________________________________________________________
> > > > > > > Message Archives: http://colab.cim3.net/forum/sicop-forum/
> > > > > > > Shared Files: http://colab.cim3.net/file/work/SICoP/
> > > > > > > Community Portal: http://colab.cim3.net/ To Post:
> > > > > > > mailto:sicop-forum@xxxxxxxxxxxxxx
> > > > > > > Community Wiki:
> > > > > > > http://colab.cim3.net/cgi-bin/wiki.pl?SICoP
> > > > > >
> > > > > >
> > > > > >
> > > > > > <bcox.vcf>
> > > > > > _________________________________________________________________
> > > > > > 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
> > > > --
> > > > Andrew S. Townley <ast@xxxxxxxxxxxx>
> > > > http://atownley.org
> > > >
> > > > _________________________________________________________________
> > > > 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
> > --
> > Andrew S. Townley <ast@xxxxxxxxxxxx>
> > http://atownley.org
> >
> > _________________________________________________________________
> > 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
--
Andrew S. Townley <ast@xxxxxxxxxxxx>
http://atownley.org (07)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/sicop-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/
Community Portal: http://colab.cim3.net/
To Post: mailto:sicop-forum@xxxxxxxxxxxxxx
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?SICoP (08)
|