nah... we're still awake... all y'all are doin' jes fine! No sense
kibbitzin' when things are workin' ;-) (01)
LJ (02)
> -----Original Message-----
> From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
> bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> Sent: Wednesday, March 29, 2006 1:06 PM
> To: Service-Oriented Architecture CoP
> Subject: RE: [soa-forum] Business Need for SOA (Was SOA Semantic Variation
> )
>
>
> Cory,
>
> :)
>
> Thanks for the response. I'll give it some more thought. Except for
> Paul, I think we put everyone else to sleep....
>
> I'm also not quite sure where to go from here. I think it was very
> useful, but where does that leave us?
>
> Cheers,
>
> ast
>
> On Wed, 2006-03-29 at 18:49, Cory Casanave wrote:
> > Andrew,
> > Thanks for your comprehensive response, we are certainly attempting to
> > realize the same goals, perhaps with slightly different terminology and
> a
> > few different conclusions. I'm going to pick out a couple of your
> > statements to reply to directly...
> > >
>
> > > SOA is not about distributed objects.
> > >
> > Absolutely and violently agree. It actually disturbs me that you think
> I
> > think it is, I will have to look back on the prior communications to see
> > where this came from.
> > >
>
> > > Just to clarify some of these key differences a bit more. The way I
> see
> > > SOA is the environment in which a service exists. This service can be
> > > big or small, but it provides the same sort of granularity, regardless
> > > of the business process being achieved--it is a business service.
> > >
> > Absolutely agree - SOA is the business architecture (where the business
> is
> > understood as providing and using business services). This business
> > architecture MAY be realized with distributed objects or with an event
> > service or with paper flowing between in/out baskets.
> > We MAY map the business interactions to one of these technologies.
> People
> > who DO think if architecture in terms of technology services are looking
> for
> > something like an Corba-IDL or WSDL interface - to map business
> interactions
> > to this paradigm we talk about "service interfaces" as the way these
> > paradigms MAY be used to REALIZE the SOA architecture.
>
> > >
> > > For example, you (the requester) are hungry. Not knowing any better,
> > > you pull through the drive-up at McDonald's (the provider) and order a
> > >
> > Don't agree - the requester/provider mindset if to low-level for
> business
> > interactions - it really comes from the OO think we are both trying to
> rise
> > above. Business interactions are inherently bi-directional,
> asynchronous
> > (as you have said) and long-lived. Information flow may be initiated
> from
> > either side, within the constraints of the choreography of that
> interaction.
> > They are frequently complex and composed of finer grain interactions.
> There
> > are roles in these interactions and you can frequently identify one as
> the
> > "initiator", but expecting a request/reply paradigm is not business
> centric.
> > As said above, we may MAP the business centric interaction to one or
> more
> > request/reply service interfaces.
>
> >
>
> > Since you took the time to write down some great definitions I have
> provided
> > some corrections (since you said they were my definitions).
> > >
>
> > > community -- a pair of roles interacting for some purpose
> > >
>
> > community -- a set of roles interacting for some purpose
> >
>
> > > role -- a task or responsibility within a community
> > >
>
> > role -- a logical grouping of a set of responsibilities within a
> community
> >
>
> > > interaction -- the means of communication between a role
> > >
>
> > interaction -- the means of communication between actors playing roles
> >
>
> > > community contract -- the constraints and manner of interaction
> between
> > > a pair of roles using specified service interfaces
> > community contract -- the purpose, constraints and manner of
> interactions
> > within a community
> >
>
> > > Specification -- codification of a given community contract
> > Specification -- codification of a given contract
> >
>
> > >
>
> > > SOA -- an architecture consisting of the following core elements:
> > > - people and organizations
> > > - roles and responsibilities
> > > - interactions between roles
> > > - community contract
> > >
>
> > >
>
> > SOA -- an architectural style for achieving collaborative work that can
> be
> > specified using a community contract containing the following core
> elements:
> > - roles and responsibilities
> > - interactions between roles
> > - business rules and constraints
> > - a model (or ontology) of the domain
> >
>
> > > service interface -- a set of methods exposed by a distributed object
> > > (as exemplified by middleware technologies like RMI/IIOP, CORBA, DCOM,
> > > .NET remoting and SOAP)
> >
>
> > This is ok, but is a possible derivative of the SOA, not the subject of
> the
> > SOA.
> >
>
> > >
>
> > > collaboration -- interactions between roles to realize a business
> > > process
> > >
>
> > > integration -- the combination of all of the elements defined by the
> SOA
> > > (above) to enable a collaboration
> > >
>
> > > interoperability -- the level to which a role and service interface
> > > conform to the interaction contract of the community within a
> > > collaboration (implying some sort of shared context between the two
> > > roles)
> >
>
> > Interoperability - the ability for business units, people or systems to
> > exchange information in support of a common purpose.
> >
>
> > >
>
> > > There are also a few terms that I'm not sure I understand from your
> > > usage.
> > >
>
> > > agility -- this is a term which has a number of different meanings,
> > > depending on your context. Can you explain to me what you mean by:
> "how
> > > things work together for a common purpose while retaining _agility_"?
> >
>
> > Agility - the ability for new objectives, whether driven by business,
> > mission or technology, to be realized quickly and inexpensively.
> >
>
> > >
>
> > > architecture -- I think it's the environment in which all of the above
> > > interactions take place, but I'm not really 100% sure from your usage.
> > >
> > Architecture - the design of systems; where systems may be
> organizational,
> > legal, physical, processes or processing systems.
> >
>
> > -----------
> > So, now it is clear we are BOTH crazy! I wonder if anyone else is still
> > listening?
> >
>
> > -Cory
> >
>
> > > -----Original Message-----
> > > From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
> > > bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> > > Sent: Tuesday, March 28, 2006 8:21 PM
> > > To: Service-Oriented Architecture CoP
> > > Subject: Re: [soa-forum] Business Need for SOA (Was SOA Semantic
> > > Variation )
> > >
>
> > >
>
> > > Hi Cory,
> > >
>
> > > After spending considerably more time on this today than I planned
> (when
> > > it wasn't interrupted by "real" work and meetings), I honestly think
> > > we're trying to accomplish the same goals. However, I think there are
> > > currently two things which are possibly preventing clearer
> > > communication.
> > >
>
> > > First, I think we have a bit of a terminology impedance which is
> > > actually caused by the second: different starting points to SOA which
> > > may have resulted in different perspectives. I believe that we can
> get
> > > around these issues. What I will do is walk through some of the
> points
> > > from the conversations over the last few days and then see if I
> managed
> > > to catch the correct babel fish. However, there are still some things
> I
> > > don't understand. Please forgive me if I'm just being thick.
> > >
>
> > > Based on your past published work [1,2,3], it is quite clear that
> you've
> > > put a lot of thinking into where you are now. It's also pretty clear
> > > that you've an extensive background with CORBA, UML and MDA.
> > >
>
> > > >From what you've said, I think that this has had a distinct impact on
> > > how you view SOA. As you also said, you have seen and been a part of
> > > several SOA solutions implemented in CORBA.
> > >
>
> > > If I understand what you've been saying over the last few emails, I
> > > understand you to have the following definitions. I'm trying to nail
> > > these down so that I'm sure what you mean, and I don't make the wrong
> > > assumptions. I realize you may think I'm silly, but I really think
> it's
> > > important to get straight.
> > >
>
> > > community -- a pair of roles interacting for some purpose
> > >
>
> > > role -- a task or responsibility within a community
> > >
>
> > > interaction -- the means of communication between a role
> > >
>
> > > community contract -- the constraints and manner of interaction
> between
> > > a pair of roles using specified service interfaces
> > >
>
> > > specification -- codification of a given community contract
> > >
>
> > > SOA -- an architecture consisting of the following core elements:
> > > - people and organizations
> > > - roles and responsibilities
> > > - interactions between roles
> > > - community contract
> > >
>
> > > service interface -- a set of methods exposed by a distributed object
> > > (as exemplified by middleware technologies like RMI/IIOP, CORBA, DCOM,
> > > .NET remoting and SOAP)
> > >
>
> > > collaboration -- interactions between roles to realize a business
> > > process
> > >
>
> > > integration -- the combination of all of the elements defined by the
> SOA
> > > (above) to enable a collaboration
> > >
>
> > > interoperability -- the level to which a role and service interface
> > > conform to the interaction contract of the community within a
> > > collaboration (implying some sort of shared context between the two
> > > roles)
> > >
>
> > > There are also a few terms that I'm not sure I understand from your
> > > usage.
> > >
>
> > > agility -- this is a term which has a number of different meanings,
> > > depending on your context. Can you explain to me what you mean by:
> "how
> > > things work together for a common purpose while retaining _agility_"?
> > >
>
> > > architecture -- I think it's the environment in which all of the above
> > > interactions take place, but I'm not really 100% sure from your usage.
> > >
>
> > >
>
> > > If the above are right, or even close, I am now starting to see why
> > > we've not been effectively communicating. :(
> > >
>
> > > I have done a few distributed computing projects as well, including
> some
> > > with J2EE, CORBA, DCOM, .NET remoting and even some simple PDO things
> > > under NEXTSTEP, XML-RPC and basic SOAP/1.1. So I am pretty well
> versed
> > > with the paradigm.
> > >
>
> > > However, for the last 18 months, I've been implementing part of an
> > > on-going SOA project based nearly exclusively on asynchronous
> > > messaging. Based on this experience, and from reading everything I
> > > could find about Web services, loose coupling, messaging, ESB and SOA,
> > > I've come to the distinct conclusion:
> > >
>
> > > SOA is not about distributed objects.
> > >
>
> > > This is a pretty fundamental notion on which we seem to differ, but
> I'll
> > > get to this in more detail as I go.
> > >
>
> > > Even though I'm not in 100% agreement with all it says, the W3C Web
> > > Services Architecture [4], along with the W3C Web Services Glossary
> [5],
> > > provide some useful, public definitions of terms. Like design
> patterns
> > > enable communication of architectural design concepts between software
> > > architects and developers, it is useful to have a baseline vocabulary
> > > when discussing these things. And for everyone in the wings with a
> > > semantics & ontology background, in case you were wondering, I haven't
> > > missed the irony of that last sentence. :) I have tried to make the
> > > terminology I use consistent with these definitions.
> > >
>
> > > I'll not go into all of them, but, to me, SOA is about "business"
> > > services, but, like most things, what a "business" service actually is
> > > depends on your point of view. If you're part of the process that
> > > implements or is responsible for the desired outcome, you probably see
> > > all of the little steps required to carry it out. If you are not part
> > > of the process, you see the entire process as the service. This is
> just
> > > natural human abstraction when they don't know or don't really care
> > > about the details.
> > >
>
> > > For example, you (the requester) are hungry. Not knowing any better,
> > > you pull through the drive-up at McDonald's (the provider) and order a
> > > value meal, pay your money (send a complex message), pull up to the
> next
> > > window and wait. Eventually, someone appears at the window with your
> > > cholesterol bomb (receipt of a complex message), and you drive away
> > > happy.
> > >
>
> > > This example seems to map to your definitions as the following:
> > >
>
> > > you (the requestor) -> role #1
> > > McD's (the provider) -> role #2
> > > you + McD's -> the community
> > > hanging out your car window and talking -> the interaction
> > > giving your order (including the money) + receipt of food -> community
> > > contract
> > > McD's window + your order + money + bag o food -> service interface
> > > you ordering food from McD's -> collaboration
> > > all of the above -> SOA
> > >
>
> > > Using this simple scenario again, here's how I would define the
> various
> > > bits (more-or-less from the WSA/WSG):
> > >
>
> > > you -> the requestor
> > > McD's -> the provider
> > > ordering food -> the service
> > > hanging out your car window and talking -> the transport
> > > your order + money -> request
> > > food -> response
> > > send (any order for food + money); receive (food) -> service interface
> > > roads + traffic laws + houses + shops + fast food places -> SOA
> > >
>
> > > Just to clarify some of these key differences a bit more. The way I
> see
> > > SOA is the environment in which a service exists. This service can be
> > > big or small, but it provides the same sort of granularity, regardless
> > > of the business process being achieved--it is a business service.
> > >
>
> > > Also, services can be complex or simple. If we were in the pub, and I
> > > asked you to go get me a burger, I'd give you my order plus some money
> > > and get a burger back from you. I wouldn't care if you needed to go
> to
> > > three different places to find what I wanted (except that it might be
> > > cold).
> > >
>
> > > In this case, this would be a complex service (degenerate
> > > case--specifically an intermediary) because you needed to do things on
> > > my behalf. Later, I might also want to go to McD's directly, or I
> could
> > > ask you again. If life was really good, I could use the same data in
> > > both cases, e.g. both you and McD's would provide the same service
> > > interface--enabling interoperability between service providers.
> > >
>
> > > The SOA part kicks in when I can drive from McD's, to BK, to Wendy's
> to
> > > Arby's, or wherever, and send the same message and expect the same
> > > response. In W3C-speak, ordering food is the abstract service and
> each
> > > of the fast food places is a concrete implementation of that service
> (an
> > > agent). The SOA tells me how I can get from point to point, what
> rules
> > > I must follow, and maybe even gives me directions. It may also allow
> me
> > > to get fuel, buy a candy bar or even a newspaper--if those messages
> > > existed and there was an agent implementing a service providing them.
> > >
>
> > > The way I understand Web services and SOA is that they provide these
> > > higher-level interfaces to business services, the invocation mechanism
> > > and the messages exchanged. You get the interoperability because you
> > > *can* place the same order at all those places and expect, with minor
> > > variations, to get the same thing back. If you don't, they don't
> > > implement the same service interface.
> > >
>
> > > I know these things sound very similar to what I suspect you
> understand,
> > > but to me, they are very different. Messages are not parameters to
> > > remote methods, and WSDL is not IDL. While you can use them that way,
> > > this doesn't buy you anything over any other type of distributed
> objects
> > > except unmolested access through port 80/443.
> > >
>
> > > The business processes are the interactions between the requester and
> > > provider (through their agents implemented in software), if they're
> > > RPC-style interactions, one-way interactions, or a complex, long
> running
> > > choreography involving messages going from A -> B -> C -> D -> A as a
> > > directed graph. The business processes can be modeled on any
> meaningful
> > > level, but the type of centralized architectural view via MDA as I now
> > > understand it (after today's research) isn't really there.
> > >
>
> > > Yes, you have auditing and governance as part of the architecture, but
> > > it's as a peer to peer set of interactions between organizational
> > > entities. Only the provider *needs* to have a service interface,
> > > because the requester can send the request and then ask for the
> > > asynchronous response. They aren't objects. Interoperability at that
> > > point boils down to:
> > >
>
> > > - agreement or following a published business choreography
> > > - agreement on the message data (or any transformations)
> > > - standardized or commoditized transport
> > >
>
> > > If I want to book a flight, I provide the same information over the
> > > phone, on the Web or in person to a travel agent. They all implement
> > > the same service interface, but the transport and agents are
> different.
> > >
>
> > > To me, this is where you get the power of SOA, and the flexibility to
> > > exchange messages with parties that weren't there yesterday.
> > >
>
> > > I know you all now probably think I'm crazy, but does this make sense?
> > >
>
> > > Is it the same or different than what your understanding is?
> > >
>
> > > ast
> > >
>
> > > [1] http://www.idealliance.org/papers/xml02/dx_xml02/papers/03-02-
> 04/03-
> > > 02-04.pdf
> > > [2] http://www.semanticcore.org/requirements/InterfaceAdaptation.pdf
> > > [3] http://colab.cim3.net/file/work/SICoP/2006-02-
> > > 09/Presentations/CCasanave02102006
> > > [4] http://www.w3.org/TR/ws-arch/
> > > [5] http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
> > >
>
> > > On Mon, 2006-03-27 at 23:20, Cory Casanave wrote:
> > > > Andrew,
> > > > One think I suspect we can all agree on is that there are multiple
> > > > applications for SOA. Perhaps a little more background on the kinds
> of
> > > > problems we are trying to solve would be appropriate, below is our
> > focus.
> > > >
> > >
>
> > > > Business Need; Collaboration and integration
> > > >
> > >
>
> > > > The idea of an isolated company, organization, mission or
> application
> > > has
> > > > become the exception. It is simply impractical to think of what you
> or
> > > your
> > > > organization offers without considering the environment in which it
> is
> > > > offered and performed. Businesses have their supply chains, value
> > > chains
> > > > and business processes. Defense has joint missions and
> collaborative
> > > > forces. Applications require integration and interoperability.
> > > >
> > >
>
> > > > In each case the problem is; how to all these things work together?
> The
> > > > problems is also that how it works together is a dynamic environment
> as
> > > > parts and pieces get outsourced, insourced, or modified. The
> problem is
> > > > also that most solutions to enabling these things to work together
> get
> > > tied
> > > > to particular processes, information or technologies such that it
> > > becomes
> > > > brittle and inflexible.
> > > >
> > >
>
> > > > This is the problem we wish to address - how things work together
> for a
> > > > common purpose while retaining agility. This problem exists at many
> > > levels,
> > > > from a worldwide scale where there is collaboration between
> countries
> > > and/or
> > > > major organizations to how people work together within a department.
> > > These
> > > > "big" collaborations are realized by smaller and still smaller
> > > > collaborations - until you have a small group executing their
> specific
> > > > "business process" on their specific information to realize their
> part
> > > in
> > > > the larger picture.
> > > >
> > >
>
> > > > A community may be small or large, the smallest being a pair of
> roles
> > > > interacting for some purpose, the most common example being a retail
> > > > purchase - buyer and seller. But communities are often large, such
> as
> > > the
> > > > financial management community of a large enterprise.
> > > >
> > >
>
> > > > Where people, organizations, missions or countries work together for
> a
> > > > common purpose - there must be some element of agreement, some
> implicit
> > > or
> > > > explicit understanding of how they are going to work together for
> that
> > > > purpose. That agreement may be a simple sales agreement to a
> complex
> > > > multi-lateral collaboration of many parties. We express this by
> saying
> > > that
> > > > people and organizations are actors playing roles with given
> > > > responsibilities within a community and they enact their common
> purpose
> > > by
> > > > behaving and interacting according to the contract of that
> community.
> > > > This is the architecture of that community.
> > > >
> > >
>
> > > > We can also look at this community of actors playing roles as each
> > > providing
> > > > a service to the community - this is the "larger" view of service,
> more
> > > akin
> > > > to a business service - like maintaining a fleet of vehicles. Thus
> the
> > > > architecture of the community is the business view of the "Service
> > > Oriented
> > > > Architecture".
> > > > Note: This kind of business service of an actor playing a role in a
> > > > community is related to, but not the same as the service interfaces
> one
> > > > finds in middleware technologies, such as web services.
> > > >
> > >
>
> > > > Between these actors playing roles there are interactions - these
> > > > interactions are frequently bi-directional, asynchronous,
> choreographed
> > > and
> > > > long-lived. They represent the "conversations" between the parties
> > > playing
> > > > the roles. Each of these conversations generally correspond a pair
> of
> > > > service interfaces, one for each side of the conversation. These
> > > service
> > > > interfaces can be instrumented in technology, and when they are, you
> > > have
> > > > provided a vehicle for that community to operate more efficiently
> and
> > > > openly. You have provided a way for the "business process" of the
> > > community
> > > > to happen without any special monitor or control, but as the natural
> > > > progression of actors playing their role based on the community
> process.
> > > >
> > >
>
> > > > So for us, from the perspective of a "community" the interesting
> > > > architecture is how all of these actors work together, and by
> extension,
> > > how
> > > > all the services work together for a business purpose. A single
> > service,
> > > > out of context, can provide value - but an architecture of a
> community
> > > of
> > > > roles and services can transform an enterprise or influence a
> society.
> > > >
> > >
>
> > > > It is this kind of community we would like to demonstrate - how it
> can
> > > be
> > > > described, architected and realized with SOA. The paradigm we use
> to do
> > > > this brings together standards based collaboration modeling (Based
> on
> > > > OMG-EDOC), information modeling (Based on UML) and process modeling
> into
> > > a
> > > > cohesive architecture for a community.
> > > >
> > >
>
> > > > A specific example is an architecture we have just done for the
> GSA'a
> > > CFO
> > > > for their Financial Management Line of Business - how can GSA
> organize
> > > to
> > > > provide financial management services within GSA and externally.
> This
> > > is
> > > > what we would consider an SAO in that it describes these
> communities,
> > > the
> > > > roles and interactions, the information models and processes. (You
> may
> > > also
> > > > consider that this is more than an SOA in that it also shows how
> some of
> > > the
> > > > roles are implemented, but at the top is the SOA). This SOA does
> not
> > > > mention any systems, middleware or technology - it is how the
> business
> > > is
> > > > understood as collaborating business services. We then derive
> (Using
> > > MDA),
> > > > how middleware services interfaces can help realize and implement
> these
> > > > communities. There are about 60 roles and hundreds of service
> > > interfaces in
> > > > this architecture (not monolithically, they can be understood in
> smaller
> > > > pieces).
> > >
>
> > > >
> > >
>
> > > > So, this kind of architecture for a community where the goal is to
> > > > understand how roles interact using service interfaces to achieve a
> > > common
> > > > purpose is a great way to utilize SOA. It allows different actors,
> > > > technologies, systems and processes to be used "under the covers" to
> > > help
> > > > the actors play their role. This kind of community simply does not
> > > function
> > > > without some agreement of this kind, without a community contract.
> You
> > > > can't do "financial management" one WSDL interface at a time.
> > > >
> > >
>
> > > > This kind of community architecture can be differentiated from
> > > applications
> > > > where a single "web service" can supply a unique capability without
> this
> > > > kind of context. These, of course, exist and can provide value - it
> is
> > > > another application of SOA. But the architecture here is focused on
> the
> > > > individual service interface, less so on the environment or
> community.
> > >
>
> > > >
> > >
>
> > > > The demo outline we presented is a minimalist and simple community,
> but
> > > > intended to show this community effect based on the business need
> for
> > > > collaboration and integration. You could, of course, come up with
> any
> > > > number of communities to demo. Another kind of demo could be based
> on
> > > other
> > > > business needs or approaches to applying MDA - I think some of the
> other
> > > > ideas are more along this line. Our business stakeholders should
> help
> > > guide
> > > > us on what kind of problem will resonate with the business
> community.
> > > >
> > >
>
> > > > Regards,
> > > > Cory Casanave
> > > >
> > >
>
> > > > > -----Original Message-----
> > > > > From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
> > > > > bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> > > > > Sent: Saturday, March 25, 2006 12:03 PM
> > > > > To: Service-Oriented Architecture CoP
> > > > > Subject: Re: SOA Semantic Variation ( was RE: [soa-forum] RE: SOA
> > > > > CommunityDemoCon Call)
> > > > >
> > >
>
> > > > >
> > >
>
> > > > > Hi folks,
> > > > >
> > >
>
> > > > > I've combined some of the points from both Cory and Ken into one
> > > > > response. Please see in-line.
> > > > >
> > >
>
> > > > > On Fri, 2006-03-24 at 22:32, Cory Casanave wrote:
> > > > > > It is this contract of interaction that is the essence of SOA,
> this
> > > is
> > > > > what
> > > > > > allows multiple actors to play roles as providers or users of
> > > services.
> > > > > It
> > > > > > is the glue.
> > > > >
> > >
>
> > > > > Absolutely correct, but so is Ken's point here
> > > > >
> > >
>
> > > > > On Sat, 2006-03-25 at 05:02, Ken Laskey wrote:
> > > > >
> > >
>
> > > > > > The essence of SOA is not that we have architected solutions
> > > > >
> > >
>
> > > > > > but that we have the power to architect the hooks for solution
> > > modules
> > > > >
> > >
>
> > > > > > that deal with areas which make interoperability difficult now.
> The
> > > > >
> > >
>
> > > > > > essence of SOA is we can add new services to fill those voids as
> > > > >
> > >
>
> > > > > > technology and knowledge grows, and we can keep multiple
> solutions
> > > > >
> > >
>
> > > > > > around as long as these are useful. The essence of SOA is that
> we
> > > can
> > > > >
> > >
>
> > > > > > interoperate (to some extent) with people who moments ago we did
> not
> > > > >
> > >
>
> > > > > > know existed.
> > > > >
> > >
>
> > > > > What Ken pointed out is why the S of SOA is so important. The
> > > community
> > > > > is defined by the services that are provided to it. The
> interaction
> > > > > models of the services themselves define the interaction models of
> the
> > > > > architecture. This is also where you can get explosive complexity
> if
> > > > > things within the architecture aren't managed correctly. So
> Cory's
> > > > > point about the "contract of interaction" is correct, but it
> exists
> > > only
> > > > > between a requester and provider.
> > > > >
> > >
>
> > > > > The architecture defines how these two agents can communicate,
> with
> > > what
> > > > > data models and under what constraints, but it cannot do more than
> > > > > that. Satisfying those constraints and being able to participate
> in
> > > the
> > > > > community require the business relationships that are the glue
> that
> > > Cory
> > > > > mentioned.
> > > > >
> > >
>
> > > > > > How you get to satisfy that contract is another matter. This is
> > > almost
> > > > > > always a facade on another system or component or service. How
> you
> > > map
> > > > > from
> > > > > > this "community" specification to your "internal" specification
> is
> > > > > > interesting and important, but it is not important to the
> community.
> > > > > This
> > > > > > is your business (So for the demo, this can be a differentiation
> > > point
> > > > > for
> > > > > > the implementers). I think some of the conversation has been
> how to
> > > > > achieve
> > > > > > this façade mapping, which is not then NOT something we have to
> > > agree on
> > > > > but
> > > > > > is a great thing to demonstrate.
> > > > >
> > >
>
> > > > > Actually, if this is in relation to my comments, then this comes
> from
> > > > > the way I expressed it. I was actually not talking about this
> type of
> > > > > mapping at all. This is what we refer to as "behind the service
> > > > > boundary", and it is, as you said, only really relevant to the
> service
> > > > > provider and not to the community of requesters. I'll come to
> more of
> > > > > what I meant below.
> > > > >
> > >
>
> > > > > > The reason we like MDA is it gets us from the business model
> > > (providing
> > > > > > context and definition for the processes and messages) to the
> > > contract
> > > > > of
> > > > > > interaction (E.G. WS-* and other technologies) with full
> tracability
> > > and
> > > > > a
> > > > > > lot of automation. Just this is a big win - far beyond the
> current
> > > > > common
> > > > > > practice. Having the business model in the picture tackles many
> of
> > > the
> > > > > > "what does this tag mean" questions without a full ontology.
> > > > >
> > >
>
> > > > > True, but doesn't that pretty-much imply point-to-point
> interactions
> > > and
> > > > > limited re-use of commonalities through standardized message
> types?
> > > > >
> > >
>
> > > > > These standardized message types may be used by multiple business
> > > > > processes. This way you can attempt to define the message
> fragment
> > > > > (e.g. a complex element using XML) and state what that message
> type is
> > > > > intended to be. This says what it is in the context of the entire
> SOA
> > > > > community. Once you have this done, the service model for each
> > > service
> > > > > specifies the context for how it is actually interpreted by that
> > > > > service.
> > > > >
> > >
>
> > > > > The best example of this sort of thing is an address. You can
> specify
> > > > > the structure of an address and how the elements should be
> populated
> > > (by
> > > > > profiling, rolling your own, or pulling in xAL), but that in one
> case
> > > > > the address data returned from the yellow pages is for a business
> and
> > > in
> > > > > another case the one returned from the white pages is for a
> residence
> > > is
> > > > > dependent on the service creating the message. It may be
> represented
> > > by
> > > > > the content model as type="business", but ultimately, the context
> is
> > > > > provided by the service model and the business process it
> represents.
> > > > >
> > >
>
> > > > > >From what I've seen of MDA from Cory's XML'02 paper "Enterprise
> > > > > Distributed Object Computing" and his referenced presentation, it
> > > > > doesn't really look like MDA can handle this very well. MDA seems
> to
> > > > > provide higher levels of abstractions to support more generalized
> > > > > process modelling, but it's still dealing with an object-oriented
> > > > > approach once you get down to the information model. Once this
> > > happens,
> > > > > you've defined a representation of the concept and you start
> getting
> > > > > into trouble.
> > > > >
> > >
>
> > > > > I am not convinced that SOA is about objects. Yes, you need a way
> to
> > > > > ship data around, but the power of shared concepts does not come
> from
> > > a
> > > > > particular representation. It comes from a shared understanding
> of
> > > the
> > > > > concept. If you have this, why not have a shared representation
> as
> > > > > well?
> > > > >
> > >
>
> > > > > > So the specification we described in the straw man is only the
> > > community
> > > > > > contract, with full expectation that interesting approaches will
> be
> > > used
> > > > > to
> > > > > > adapt this community contract to systems and other SOA models.
> But
> > > the
> > > > > > community contract would be our anchor point. The important
> point
> > > here
> > > > > is
> > > > > > that "SOA", as an "architected" solution (the A in SOA) does not
> > > need or
> > > > > > expect semantic variation in the contract. But realizing SOA
> > > contracts
> > > > > will
> > > > > > be much easier if semantic approaches are available.
> > > > >
> > >
>
> > > > > The other thing is: once you have a community, you must have some
> > > sort
> > > > > of governance of that community (even if it's 'none'). This
> > > governance
> > > > > model decides how and when shared data models can change. It
> isn't
> > > > > about semantic adaptation at the service boundary, it's about
> changing
> > > > > or extending a data model used by many services in the community.
> You
> > > > > can't cause everyone to change their agent implementations because
> > > > > someone has a legitimate need for including more information into
> a
> > > > > common model. I believe that this issue is what both Ken and I
> were
> > > > > trying to highlight (Ken, please feel free to correct me if I'm
> wrong
> > > > > here).
> > > > >
> > >
>
> > > > > What worries me about what I've seen and read thus far about
> semantic
> > > > > negotiation across ontologies is that this is really trying to
> provide
> > > a
> > > > > technical solution to a community problem. It goes back to the
> > > > > governance thing I mentioned above. If you have a community, you
> must
> > > > > have some shared understandings within that community. Yes, there
> > > will
> > > > > always be intersections and touchpoints between communities, but
> this
> > > > > can be resolved by putting the semantic negotiation at those
> > > > > intersection points.
> > > > >
> > >
>
> > > > > The fact that within a single community you can have a nearly
> infinite
> > > > > variation in the way the data for an operation is structured and
> what
> > > > > the operation to use it is called is *not* a good thing. Sure
> they're
> > > > > all "semantically equivalent" because what they are supposed to do
> is
> > > > > the same, but how you invoke it should be agreed within the
> community.
> > > > >
> > >
>
> > > > > Just because I can define them all in WSDL and figure out how to
> map
> > > > > them does not make it legitimate.
> > > > >
> > >
>
> > > > > Within a community, there has to be some level of shared sense of
> > > > > legitimacy or there is no community. We can't drive on whichever
> side
> > > > > of the road we want to just because we have a car. The community
> says
> > > > > that you drive on the right, so you drive on the right, If you
> could
> > > > > drive from New York to London, you'd need to make some slight
> > > > > modifications when you cross the community boundary, but once
> you're
> > > in
> > > > > the UK, you drive on the left. If you don't agree, e.g. establish
> > > > > legitimacy, there is chaos because everyone's trying to do their
> own
> > > > > thing.
> > > > >
> > >
>
> > > > > In an SOA, there isn't one contract, there are many contracts;
> each
> > > one
> > > > > defined by the service provider's interaction with a requestor.
> What
> > > > > tools you use to hook those two together is not a problem for the
> SOA.
> > > > >
> > >
>
> > > > > The SOA says that you can do it and provides the structure to make
> it
> > > > > happen. The architecture is relatively straightforward; the
> services
> > > > > are the hard part.
> > > > >
> > >
>
> > > > > 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
> > > >
> > >
>
> > > > _________________________________________________________________
> > > > 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.
> > >
>
> > >
> **************************************************************************
> > > *************************
> > > 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
> >
>
> > _________________________________________________________________
> > 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.
>
> **************************************************************************
> *************************
> 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
> (03)
_________________________________________________________________
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 (04)
|