soa-forum
[Top] [All Lists]

Re: SOA Semantic Variation ( was RE: [soa-forum] RE: SOA Community Demo

To: Service-Oriented Architecture CoP <soa-forum@xxxxxxxxxxxxxx>
From: Mills Davis <mdavis@xxxxxxxxxxxxxx>
Date: Fri, 24 Mar 2006 18:28:35 -0500
Message-id: <B57478D1-F37A-4126-863D-E1D9996D9571@xxxxxxxxxxxxxx>
Modus Operandi's WAVE provides an example of productized Semantic SOA over BEA's Aqua Logic..

http://www.modusoperandi.com/


On Mar 24, 2006, at 5:32 PM, Cory Casanave wrote:

Ken,
Just to compare notes - this is how we handle semantic variation and
thoughts on the evolution of it.

AT the outset we assume there exists SOME architected solution - the "A" in
SOA.  In this case this is the architected solution for the community.  To
belong to that community means you subscribe to that architecture and the
contracts of interaction [interfaces and other constraints] within that
community.  Information exchanges are well defined within that contract of
interaction based on the business interactions (this is very similar to the
ebXML model).   Of course, any specification can be mis-interpreted, by man
or machine.  But the intent is a clear and precise specification.  There may
be multiple versions of this specification, each being such a contract.

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.

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.

A "smart", ontology driven façade can also be envisioned where this
adaptation from the community contract to the system contract is machine
generated.  There is a lot of discussion about dynamic adaptation - this is
one possibility.  The other is that you have ontology assisted adaptation
that required user validation - it depends on how deep the ontologies are
and how much they are trusted (would you trust un-validated inference to
give you a dangerous medicine?) In any case, we feel there is a lot of value
in using KR concepts to join these architected solutions -
community-community, system-community or system-system.  We could show this
within the context of the architected community.

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.

We like the semantic technologies in that we can start to adapt these models
(and thus the SOA) where they were not previously intended to work together.
There are some challenges in both the infrastructure and semantics, this is,
of course, an area that is growing fast.  We are very interested in semantic
"hubs" to join specifications.

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.

I did a presentation on this approach and how we are realizing it in the
OsEra open source project at the last semantic interoperability conference: 
2006.ppt
Regards,
-Cory Casanave

-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
bounces@xxxxxxxxxxxxxx] On Behalf Of Ken Laskey
Sent: Thursday, March 23, 2006 5:08 PM
To: Service-Oriented Architecture CoP
Subject: Re: [soa-forum] RE: SOA Community Demo Con Call

I wouldn't write off semantic variation because the understanding of
semantics for both the XML tags and the values wrapped in the tags is
critical and usually swept under the rug.  You do not have to do full
blown inferencing as part of the demo but I'd strongly suggest
including some simple level of semantic negotiation.  Remember, this is
SOA and semantic negotiation is likely to be provided as a service by
those who research and provide capabilities in that field.  We can have
a semantic negotiation service that looks up a schema and finds an XSLT
transform to convert it to another schema, and then a conversion back.
Simple?  I think so but it is a placeholder for a future service that
does real magic.

Do an old tired scenario and you will convince no one.  Demonstrate
where your dreams could lead and your audience will follow.

Ken


On Mar 23, 2006, at 1:56 PM, Andrew S. Townley wrote:


Hmmm.... I do recall saying I was trying to *help*.  My comments and
observations come from implementing an e-Government, SOA project for
the
last 18 months.  I'm only trying to share some perspective.

On Thu, 2006-03-23 at 15:57, Cory Casanave wrote:
Status; Remember that the point of this call and our current status
is to
start assembling a core team and writing the spec for the demo,
flushing out
aspects such as identity.  Certainly the one sentence does not do
identity
management justice!

I didn't think it did, nor did I think that was the intent.  My
comments
were intended to provide feedback before the meeting which was to
discuss and further flesh out the specification for the demo (as
indicated in the proposed agenda).  I was not sure if I was able to
participate in the conference call.

Challenge; I suspect getting this defined and interoperable, even as s
"simple" demo will be more of a challenge than you suspect and that
the
impact of seeing it run with multiple players, application and
technologies
will be meaningful to our business stakeholders.  The are not
successfully
instrumenting communities, even at this level of simplicity!

I have some idea of the effort involved based on my current work.  I
was
attempting to focus on the technical issues rather than the
organizational ones, as these were really the only ones in the current
version of the evolving specification.

However, I do think the use of the word "simplicity" in the context of
a
full-blown, MDA + WS-* implementation of SOA is a bit ironic. ;)

Security & Identity; Go for it!  Lets get this well defined.  Doing
this in
an open, standards based, robust, performing and interoperable way is
still
something we must show and prove.

I'm more than happy to help do this and other things, as I said.

Semantic variation; Our view of SOA is that it enables architected
interoperability across a wide range of actors and technologies.  It
is
however, architected.  There is a specification of the contract of
interaction to participate in that community.  Differing
representation of
similar semantics is something we are interested in, and interested in
showing how it fits with architected solution - but it a separate
problem in
our view - one where we bring in ontologies.  The fact that you can
implement SOA using Corba is a good thing - this is architecture not
technology. (Side note; many of the best examples of deployed
wide-scale SOA
architectr4es use Corba)

I specifically mentioned CORBA *because* I know it can and has been
used
to implement large-scale systems in an SOA style.

As I mentioned in my earlier response to Paul, I was not trying to
introduce ontologies and the semantic web into the equation.  What I
was
trying to do is point out that what we've seen is that people either:

a) misunderstand the way they're supposed to use an XML instance
document, even if the documentation exists, or

b) that existing data formats are "close" and have the same semantic
intent, but reflect this intent with a different structure which
requires either special processing or transformation into a more
agreed/canonical data format.

Specification Evolution; Great thing too shoe, I would tend to get one
revision of an architecture working first.

Again, based on what I've been doing, this is the only thing that
matters.  In the overall scheme of things, building a relatively static
architecture as described in the demo is far less complex than dealing
with the first time someone forgot they wanted to track how many times
someone's seen Star Wars as part of their data model for a person.

This is even more crucial to address when using nearly every tool I've
seen to date which supports some of the WS-* standards, because they
don't automatically make it easy for you to adapt.  They're quite happy
to automagically generate about a million classes for you which
hard-codes your data model into your application.  Change the data
model--even slightly, and it can mean rebuild, retest & redeploy.  For
this reason and the associated costs to the owners of each agent, I
suggest that it is critical to show that the architecture is not
brittle.  You can argue that this is good design, but at the moment,
with the current crop of tools, they're working against flexible design
in the name of efficiency and "time to market" so you can get your code
running quickly and (mostly falsely) prove your ROI to the business.

Green field; This is as green field as you make it - the intent is
that both
legacy and new applications can use and implement the interfaces.

Yeah, but that's just plumbing.  How much of the legacy application's
existing interface is going to drive the interfaces for the service
interfaces and data models?  How are these mappings going to be dealt
with?

In our case, we've seen that generally the first thing people want to
do
is encode their current database schema model types and sizes into the
XML data model for the service they're providing.  This is exactly
orthogonal to the interoperability of that service and allowing it to
vary internally vs. externally.  This is the issue I was trying to
highlight.

Rocket scientists; You are all rocket scientists wanting to show great
stuff.  There is some great business value we can show with relatively
simple scenarios.  Also, even some of this "simple stuff" is more whet
behind the ears than the industry would like to admit to - showing it
work
is great.

Which is fundamentally the reason that I am interested in participating
in this effort.  I want to see it all work together based on what would
otherwise be an impossible collaboration of bright people on one
project.  My project is not using any of these technologies to
implement
SOA.  While I certainly have some opinions about the maturity and
practicalities of the whole WS-* stack, I'm genuinely interested in
seeing what a group like this can accomplish in making it work.

I hope this clears up any questions of my original intent in posting
the
feedback.

Cheers,

ast


-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
Sent: Thursday, March 23, 2006 10:38 AM
To: Service-Oriented Architecture CoP
Subject: RE: [soa-forum] RE: SOA Community Demo Con Call


Hi David,

On Thu, 2006-03-23 at 14:21, David RR Webber (XML) wrote:
One glaring aspect left on the table (that Amazon.com also
illustrates) is the need to authenticate partners and provide a
secure
access model.   The government really has not got this correct yet
IMHO.  It either goes wildly the one way - requiring excessive
sign-up
criteria taking days/weeks to acquire - or throws the door wide open
and leaves participitants potentially exposed to abuse - and in
either
case, management and control and scalability are indeterminant.

Yeah, but the identity proofing required should be easier with the
PKI
infrastructure already in place.  Still, the identity proofing
required
should reflect the risk assessment for the services being accessed.
I
agree that the access control rights aren't really addressed much in
the
demo proposal, but at least the security stuff is mentioned.  We have
implemented a solution around a constrained, e-Gov vertical WSN, so
we
have access control rules as part of the message delivery.  It's
been a
while since I've looked at the WS-Federation and other ilk, but
that's
also one of the areas that I'm interested in seeing actually working.
Of course, the scope of the demo can't be massive, and some of the
scenarios may be contrived, but the security aspects are some of the
most fundamental parts of e-Gov from my experience.


Probably better to address the conceptual vision of what an SOA
constitutes in an eGov context - before we rush into providing
demo's
of raw technology...

The documents are really rough in places and oscillate between
various
levels of abstraction, but our original requirements are here:
http://www.reach.ie/procurement/.  We've clarified a few things and
are
in the process of clarifying more of the fundamental semantics in a
set
of documents that should be published in draft form for more wide
review
next week (note:  these are not updated requirements, but operation
documents located here:  http://sdec.reach.ie/).

One of the things I'd looked for before (12-14 months ago) was a bit
more of the scope of the US e-Gov project.  The security and
federated
identity management things were quite good, but I didn't find much
else.

It might also make sense - given that this topic is obviously
extensive - to in fact break down the SOA domain into descreet
parts -
and then look at producing demo's for individual parts.  That I
believe would be clearer for people and give better balance around
what choices are out there and key requirements to be fulfilled - to
be able to constitute a robust SOA environment.

I did think the example scenario was a bit odd, but then I thought
about
the number of suppliers and contracts to the US Government, and it
made
sense.  Depends on what you're trying to prove, but once you prove
the
security, scalability and evolution of the fundamentals, the rest is
just variations on a theme of actual service implementations.

Thanks, DW


        -------- Original Message --------
        Subject: Re: [soa-forum] RE: SOA Community Demo Con Call
        From: "Andrew S. Townley" <andrew.townley@xxxxxxxxxxxxxxxx>
        Date: Thu, March 23, 2006 8:55 am
        To: Brand Niemann <bniemann@xxxxxxx>, Service-Oriented
        Architecture CoP

        Hi all,

        I'm not sure if the conference call is open or not, so I'll
        just give
        some initial feedback on the straw man here--assuming that
you
        want a
        few opinions about the specification.  Please don't take
these
        as being
        over critical, because I'm just trying to help.

        I think what you guys are trying to do is great, but I'm
        wondering what
        implementing the spec as-is will prove.  The reason is that,
        if I've
        read the document correctly, you're effectively talking
about
        a "green
        field" type of project with centralized control and
everything
        being
        defined by MDA.  I don't really see how this will prove
        anything other
        than SOAP/WSDL + WS-* will allow you to do distributed
        computing.  You
        could do this with CORBA/J2EE and tunnel everything over
port
        80 with
        standardized data formats.

        I think the demo will only really provide value if it takes
a
        more
        real-world look at the scenario.  I think this can be
        accomplished by
        including the following things:

            1. Including evolution of a message definition and,
since
        you're
               using WSDL, a service interface, and
            2. including some sort of recognition that in an actual
        scenario,
               you're more likely going to be dealing with a variety
        of message
               types which are structurally different but represent
        the same
               semantic concept.

        If you don't take these things into account, you're not
really
        dealing
        with SOA, but a very limited-use, vertical Web services
        network.  I also
        think, to be realistic, you're going to need to deal with
        certain fault
        conditions to prove how flexible the SOA community is when
        things
        break.  Are there intermediaries?

        Also, from my reading of the initial draft, it's not clear
how
        BEPL will
        be applied.  Is this just to allow implementation of agents
        using a
        workflow or orchestration engine, or is it intended to
        represent
        Choreography-style service instructions embedded in the
        message?

        Like I said, I'm not trying to be hyper-critical, I'm just
        very curious
        to see how these things work in a "genuine" WS-* model vs.
        what we're
        doing.  As I'm in Ireland, I'm not sure how practical it is
        for me to
        actively contribute, but I am interested in participating in
        this effort
        in some capacity.

        Thanks for listening,

        ast

        On Thu, 2006-03-23 at 01:47, Brand Niemann wrote:
Thanks and I will try to make this. I am speaking at a
        conference just
before this. Brand
        ----- Original Message -----
        From: Cory Casanave
        To: 'Cory Casanave' ; 'Service-Oriented Architecture
        CoP'
        Sent: Tuesday, March 21, 2006 8:51 PM
        Subject: [soa-forum] RE: SOA Community Demo Con Call


        Ok this is set for 11AM, Thursday March 23rd

        Phone number: 641-297-5900

        Access code: 41677



        As usual, not all could make it ' but most can so
        lets go for
        it.

        -Cory Casanave






______________________________________________________________

        From: Cory Casanave
        Sent: Tuesday, March 21, 2006 2:20 PM
        To: 'Service-Oriented Architecture CoP'
        Subject: SOA Community Demo Con Call




        I would like to propose a con-call for the core team
        of the
        SOA demo this Thursday @ 10:30 '  11:30.  if there
        are any
        critical conflicts please let me know.

        Current demo straw man:


SOA%20Community%20of%20Practice%20D
emo.doc (Unchanged)



        This is an open process but there will certainly be
        a core
        team that will be organizing the effort and doing a
        lot of the
        work.  At this point anyone who asks is part of the
        core team.

        People who have expressed interest in being on the
        core team:

               Allen Matthew, Joe Chiusano (BAH)

               Greg Lomow (Bearingpoint)

               Larry Johnson (Tethers End/OMG)

               Brand Niemann (Government Sponsor -
        Participation
        Assumed)



        Meeting goal ' initial plan to start work on the
        demo.

               Validate/raise issues with current spec

               Governance/Work structure

               Identify participant roles



        --Roles--

        Executable Enterprise Architecture Role

        The operational role in the project we (DAT) are
        volunteering
        for is to produce an Enterprise-MDA architecture of
        the
        subject community.  This will identify the roles,
        collaboration and community interactions.  This can
        then be
        used by the group to validate the architecture in
        more detail
        and then to produce (generate) the candidate service
        specifications that would be implemented by the
        participants.



        Meeting logistics to be sent out once the time is
        confirmed.



        Regards,

        Cory Casanave

        Data Access Technologies, Inc.







______________________________________________________________



_________________________________________________________________
        Subscribe/Unsubscribe/Config:
        Shared Files: http://colab.cim3.net/file/work/soa/
        Community Portal: http://colab.cim3.net/
        Community Wiki:





_____________________________________________________________________
_


_________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Portal: http://colab.cim3.net/
Community Wiki:
        --
        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:
        Shared Files: http://colab.cim3.net/file/work/soa/
        Community Portal: http://colab.cim3.net/
        Community Wiki:


____________________________________________________________________
__
 _________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Portal: http://colab.cim3.net/
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:
forum/
Community Portal: http://colab.cim3.net/
Community Wiki:

 _________________________________________________________________
Subscribe/Unsubscribe/Config:
Community Portal: http://colab.cim3.net/
Community Wiki:
--
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:
Community Portal: http://colab.cim3.net/
Community Wiki:


------------------------------------------------------------------------
------------------
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/
Community Portal: http://colab.cim3.net/

 _________________________________________________________________
Community Portal: http://colab.cim3.net/


Mills Davis
Managing Director
Project10X
202-667-6400
202-255-6655 cel
202-667-6512 fax



 _________________________________________________________________
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    (01)
<Prev in Thread] Current Thread [Next in Thread>