Hi Ken, (01)
A couple of things in-line. (02)
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. (03)
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. :) (04)
> 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. (05)
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. (06)
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. (07)
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. (08)
> I need to reread WSA but I don't remember the separation I propose to
> be in conflict. (09)
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: (010)
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. (011)
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. (012)
Concrete (Technology) Service: a specific implementation of the
Abstract (Technology) Service using products, programming languages, and
other specific technologies. (013)
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. (014)
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. (015)
> 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 (016)
_________________________________________________________________
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 (017)
|