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. (01)
Business Need; Collaboration and integration (02)
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. (03)
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. (04)
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. (05)
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. (06)
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. (07)
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. (08)
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. (09)
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. (010)
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. (011)
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). (012)
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. (013)
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. (014)
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. (015)
Regards,
Cory Casanave (016)
> -----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 (017)
_________________________________________________________________
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 (018)
|