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. (01)
Do an old tired scenario and you will convince no one. Demonstrate
where your dreams could lead and your audience will follow. (02)
Ken (03)
On Mar 23, 2006, at 1:56 PM, Andrew S. Townley wrote: (04)
>
> 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
>>>> <soa-forum@xxxxxxxxxxxxxx>
>>>>
>>>> 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
>>>> [mailto:cbc@xxxxxxxxxxxxxxxxxxxxxxx]
>>>>> 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:
>>>>>
>>>>
>>> http://colab.cim3.net/file/work/SOACoP/
>>> 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:
>>>>> 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
>>
>> _________________________________________________________________
>> 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
> (05)
------------------------------------------------------------------------
------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508 (06)
_________________________________________________________________
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 (07)
|