Hi Paul, (01)
On Fri, 2006-04-07 at 22:35, Paul S Prueitt wrote:
> This difficulty might be by-passed with a second school approach ... but
> this comment is theory until proven.
>
>
> In a perfect world origin of design delegated to the current IT community
> would not work because of the capacity of the modeling approach (ie UML
> type)
>
> If we move to OWL type modeling the situation is remarkably better, and
> perhaps (following the lead of BioPAX - as I have pointed out before)
> PERHAPS SOA with ontology mediated orchestration and service discovery might
> be demonstrable (but is there anyone here that feels they have the ability
> to demo that SOA capacity?) Top Quadrant could do it if they spent the
> required resources ... (I guess). (02)
I'm hip for trying new things, but I know that I'm only beginning to
understand where you're going with the whole ontology and Knowledge
Management. I feel like I'm trying to read something where most of the
letters have been rubbed out at times... I don't have the ability to do
what you are suggesting. I can only do the best I can do. I think in
either the approach you mention or what I'm trying to suggest, the most
important thing is: (03)
start from the business requirements (04)
After that, you can attack the implementation in whatever way makes
sense. (05)
> I apologize because my comments are (in fact) disruptive of what would be
> occurring otherwise, but I just feel that industry has many examples of
> shallow SOA implementation which do not address "any" of the core knowledge
> elicitation and knowledge management issues - as is done in the OASIS BCM
> specification.
>
> It is not, in my opinion, that we can not move forward with something new;
> but that we are not moving forward with something new.
>
>
> How do we move forward rather than idling? (06)
Is there a way that you think the BCM specification as you understand it
can be applied to the business requirements? If there is, maybe
yourself and David can help us understand how it could be done. Having
read the specification, I think it covers a lot of ground, but, like
most things, until you actually see it work, it's sometimes difficult to
get your head around it. (07)
I had the same issue with the IEEE 1471-2000 specification. Then I saw
a couple of approaches to it, and now, I think it's great. I thought it
had potential before, but now I understand it and how it can be applied
to solve real problems. (08)
Whatever we do, we need to think about what is realistic within the
timescales we have. I don't know the answer to this, but I know from
observation that there are some really smart people receiving these
emails. Maybe collectively we can figure it out. (09)
ast (010)
> -----Original Message-----
> From: soa-forum-bounces@xxxxxxxxxxxxxx
> [mailto:soa-forum-bounces@xxxxxxxxxxxxxx]On Behalf Of Chiusano Joseph
> Sent: Friday, April 07, 2006 3:11 PM
> To: Service-Oriented Architecture CoP
> Subject: RE: [soa-forum] Next level of detail for SOA demo
>
>
> Is there perhaps a best of both worlds approach, where we demonstrate
> both techniques (model-driven and otherwise) while preserving a common
> core?
>
> Joe
>
> Joseph Chiusano
> Associate
> Booz Allen Hamilton
>
> 700 13th St. NW, Suite 1100
> Washington, DC 20005
> O: 202-508-6514
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
> -----Original Message-----
> From: soa-forum-bounces@xxxxxxxxxxxxxx
> [mailto:soa-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> Sent: Friday, April 07, 2006 5:02 PM
> To: Service-Oriented Architecture CoP
> Subject: RE: [soa-forum] Next level of detail for SOA demo
>
>
> Hi Cory,
>
> Ok, I take your points, but I'm wondering how much the community aspect
> of the SOA is influenced by the technology capabilities and programming
> paradigms supported by an MDA approach. I've been going back through
> some of the original mails around this, and been doing some thinking.
>
> Maybe we can try a collaborative approach to scenario building? I know
> you didn't like my last demo proposal very much, so I'm willing to work
> with you here on the buyer/broker/seller[manufacturer] critter.
>
> However, I think the best place to start here is with the following
> requirements:
>
> 1) The system should demonstrate interoperability between community
> participants. Interoperability in this case is defined by whatever
> automated systems communicating using specifications and protocols are
> agreed by the community. Do we have a firm list?
>
> 2) The system, to be realistic, must support user-initiated and
> automatic purchase requests. In this way, we can provide an interactive
> demo which allows for more real-world scenarios such as someone special
> ordering something as well as regular or trigger-based, automated order
> requests.
>
> 3) Orders must be requested by supplying the following information:
>
> - the purchaser identity
> - the number and quantity of the (single) item
> - the amount the purchaser is willing to pay
> - the timeframe in which the items must be delivered
> - the timeframe in which the availability of the item must be confirmed
>
> 4) If the order cannot be confirmed within the timeframe, the purchaser
> must be given a list product descriptions and prices of either a)
> alternative products which are "similar" or b) products which are
> outside what the purchaser has bid.
>
> 5) Purchasers must manually register with the broker, supplying normal
> contact information. As part of this registration process, they will be
> identity-proofed by the broker's human staff. If this is completed
> satisfactorily, the purchaser is issued with an X.509 digital
> certificate which must be used when making any purchases. It is assumed
> that the purchaser has also established a line of credit with the broker
> at this stage, as requested during the registration process.
>
> 6) Sellers/manufacturers must register with the broker in a similar
> manner to purchasers. As part of the registration process, the
> seller/manufacturer will specify:
>
> - SLA for responding to requests for goods
> - SLA for delivery of goods
> - The interval at which the catalog will be updated
> - The manner in which the seller/manufacturer is contacted for quotes
> and final prices.
>
> If this is completed successfully, the seller/manufacturer is issued
> with an X.509 certificate to authenticate it to the broker.
>
> 7) All service brokers must register themselves at a well-known
> location.
>
> 8) When a broker receives an order, it will first compare the order
> criteria with its internal catalog to find appropriate supplier(s), and
> then confirm that the supplier has the item in stock and can supply it
> to the purchaser within the specified criteria.
>
> 9) If any problems occur with the order after it has been made, the
> seller/manufacturer must notify the broker within timescale X. If so
> notified, the broker must notify the purchaser.
>
> 10) Purchasers can cancel orders within timescale X of placing it, or
> prior to shipment.
>
> 11) Purchasers can request a complete catalog of the available products
> offered by the broker either interactively or in an automated fashion.
>
> 12) Once created, purchasers can check the status of their order based
> on a confirmation order number.
>
> Then we can talk about message formats, protocols and invocation
> mechanisms. I could easily see this system being implemented using a
> number of technologies, but I would also say that you could quite
> happily do it with something like XML(Atom/1.0+custom vocabulary), XSLT,
> HTTPS a standard web application and X.509, cert-based authentication
> and a Web browser.
>
> This solution would meet the requirements, and it would be completely
> interoperable, be browser-friendly and would also allow things like
> standard, off the shelf syndication readers to be leveraged in extending
> the services offered. These are the benefits of standardized formats
> and invocation interfaces. However, it wouldn't use WS-* at all, which,
> as I understand it, is a requirement.
>
> If the architecture reflected in the current document is intended to
> reflect these business requirements, I would argue that it is too
> closely aligned with fine grained messages that aren't self-describing
> (this doesn't mean schema, this means stand-alone/context-free) and
> which aren't directly aligned with the types of interactions supported
> by humans or real-world entities.
>
> Today, you would have someone give purchasing requirements to a broker,
> and then they would either say "yea", "nay" or "we can't do it, but
> here's your options." I would see this as a business message, self
> describing, and exchanged between the purchaser and the buyer. It
> naturally aligns itself to the existing business model.
>
> I realize that this model is a bit looser than the one you propose, but
> if we say that the numbered items represent the business requirements,
> we can demonstrate they can be fulfilled in a service-oriented manner
> using a variety of technologies and platforms. You still have the
> community, you still have the choreography between participants, you
> still have the data and you still have the constraints. However, you
> also can then say things like "these are the minimum items you must
> supply, but if you want to supply more (like photos), you can" to your
> manufacturers.
>
> I would see this as a pretty interoperable community which also allows
> collaboration and new applications to be built on an agreed foundation
> of messages, addresses (URIs) and invocation mechanisms. If you want
> reliable delivery of messages between participants, that's cool, we can
> do that in a variety of ways. If you want to transform vocabularies
> between broker/buyer or broker/manufacturer, then insert an intermediary
> service. If you want management, then specify statistics messages to
> receive, how and where.
>
> I also think that the scalability requirements only apply to the
> registry of brokers and the brokers themselves. The buyers should
> interact with the broker in one direction. The manufacturers and the
> broker should have two-way communication, but if the manufacturer was
> unavailable, that's ok. They loose the business. No big deal to the
> community. If there is no alternative, there's no order, or the order
> can be retried within the timeout to ensure that the manufacturers have
> a chance to get back on-line.
>
> What does everyone think about the above as the revised business
> requirements for the buyer/broker/seller scenario? If there's
> agreement, then we can prioritize the requirements to focus on those
> that are of most interest, then we can formalize the business
> relationships/messages/protocols within a revised demo document (which
> is technology neutral except for those technologies deemed necessary for
> the demo). Finally, participants create solution documents describing
> how they will meet those requirements with their tools/technologies.
>
> I don't think the on-the-fly or 1hr wrapping an existing service aspects
> are really anything other than "dog and pony show" type things. They
> aren't really going to help you much in a real SOA environment unless
> you're really lucky, or there's some aspect to it that I'm not aware of.
> It might be cool, but I'm not sure that's part of what we want to show
> if we're talking about legitimate business value to stakeholders.
>
> As I said, I'm open to making this a collaborative effort. I have tried
> to capture the intent of Cory's specification without the technology
> aspects in this email (where possible). I am happy to propose that we
> collect from here into an on-going specification somewhere. I'm tempted
> to volunteer to do this, but then I will get even further behind with my
> already maxed-out workload between now and the 22nd.
>
> I guess you can feel free to propose something else, or say I should
> just give up and we'll go with whatever Cory comes up with. However, I
> think it is possible to draft the demo requirements for the above
> without going into too much technical detail--other than saying how the
> services are invoked and what the messages are. The rest of the service
> contract can be specified in text, or at most, simple UML diagrams.
> However, I think it's possible to do it without those too (even though I
> regularly use UML in the course of my work, and choose it for
> specifications and architecture descriptions reviewed by business
> stakeholders where it is appropriate).
>
> What do you think?
>
> ast
>
> On Fri, 2006-04-07 at 19:00, Cory Casanave wrote:
> > Andrew,
> > Andrew,
> > I do understand that the spec is "MDA Centered" and don't take any
> > offense at all - what I presented is certainly vested in the way we do
>
> > things. Of course, any way to present things has to be vested in
> > something. I did consider this issue and suggest that paradigms for
> > defining & presenting architectures are just as much a part of the
> > demo as anything else, and as such alternative ways of presenting it
> should be encouraged.
> >
> > But, we have to start someplace - so my hope is that we can use this
> > to nail down the demo and then if anyone wants to present it
> > differently they are open to demo it. At that point (after we know
> > what the demo is), then this essentially becomes part of our companies
>
> > demo (and that of the OsEra
> > Project) - of how to link business architecture to systems
> > architecture using MDA.
> >
> > As for "ownership" in the "MDA meta model". First, there is no "MDA
> > meta model", there are several of them - the one we use is the EDOC
> > Enterprise Collaboration Architecture. There is no assumption of
> > "ownership". There is an assumption that there is some form of
> > community contract, the authority and evolution of that contract may
> > come from any source. There is also no assumption (in this model) of
> > an authority over the process - it is defined as a collaboration of
> the participants.
> >
> > In my opinion, it is important for the demo to express the
> > expectations of the community in a way that is business centric and
> > technology independent and to also specify specific technologies (such
>
> > as web services) that realize that community. So if this direction is
>
> > reasonable - I will make it more clear in the model & document that
> > this is one way to express an SOA - others are welcome.
> >
> > -Cory
> >
> > > -----Original Message-----
> > > From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
> > > bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
> > > Sent: Friday, April 07, 2006 12:24 PM
> > > To: Service-Oriented Architecture CoP
> > > Subject: Re: [soa-forum] Next level of detail for SOA demo
> > >
> > >
> > > *steps to the center of the room*
> > >
> > > *looks at all of the OMG members/participants in the audience*
> > >
> > > *blinks*
> > >
> > > Um, Cory... Please don't hit me, but if I didn't know anything
> > > about SOA, and I read the demo specification, I would come to the
> > > conclusion that MDA and OMG-EDOC/ECA were a requirement for SOA.
> > >
> > > I can understand that you, as a contributor to OMG specifications, a
>
> > > developer of tools that implement these specifications and as an OMG
>
> > > participant, naturally are using the technologies you believe in to
> > > both express and meet the requirements of the SOA demo, but would it
>
> > > be possible to not have the implication that SOA requires OMG
> > > standards as part of the document?
> > >
> > > Please don't get me wrong (really!). This isn't a personal thing at
>
> > > all--I'm trying to be objective here. I would say the same thing if
>
> > > someone from Microsoft had expressed the demo requirements in terms
> > > of WCF/Indigo/BizTalk, or someone from IBM/Iona/etc. doing the same
> > > with SCA, or any one of the JBI vendors.
> > >
> > > However, the OMG approach and specifications only represent one way
> > > to implement SOA. Further, I almost see the MDA meta-model as being
>
> > > not in the overall interests of the community (as peers), because it
>
> > > implies that there is an "owner" of the community that dictates the
> > > business processes. Also, if I understand it correctly, changes to
> > > the meta-model require changes to the community's agent
> > > implementations. If these agents are truly independent, they cannot
>
> > > be under the control of or tied to the MDA meta-model, and, as such,
>
> > > the positioning of the MDA meta-model as the foundation of the
> > > community implies a sense of control that cannot exist in a
> > > community of peers. In this respect, MDA is no better or worse than
>
> > > any other way of specifying the "rules" of the community.
> > >
> > > It is for these reasons that I ask the question--not because you are
>
> > > part of the OMG. If the intent of the demo is to prove MDA as a
> > > means of implementing SOA, then fine, it's an MDA-does-SOA demo, and
>
> > > that's cool. It also implies that the fate of the SOA rests solely
> > > on the capabilities of MDA, so I would question if that's a position
>
> > > the OMG really wants to be in. Maybe it does. Sometimes sink or
> > > swim is a good strategy rather than just floating along with all the
> others.
> > >
> > > We have spent a lot of time talking about the community aspects, and
>
> > > all of the people who have participated in these discussions have
> > > completely latched on to the implicit association between a social
> > > community of real people and the way community has been used to
> > > describe the architecture of the SOA. I think this is a powerful
> > > metaphor and one that is good for both this CoI and SOA in general,
> > > but it's a bit like being pregnant--you can't stop half way. All
> > > successful communities have leaders, but few have dictators.
> > >
> > > If we have to create a demo by the conference, then I have no big
> > > issue with the technical details of the scenario other than those I
> > > have already expressed. I have a couple of detail questions around
> > > the necessity of the buyer to register with the registry and the
> > > implication that SOA requires traditional middleware, but these are
> minor things.
> > >
> > > Once again, I am not attacking you, the OMG or anyone else. I just
> > > think that if you believe in SOA and the things we've been
> > > discussing, that this is more important than trying to claim that
> > > there is an optimal set of tools and technologies to implement it.
> > > If vendors wish to showcase products and specifications in the
> > > implementation of agents within the community, I think that's fine,
> > > and a good opportunity for them. However, I firmly believe that
> > > implicitly tying the success or failure of SOA the concept to any
> > > particular vendor or technology is a mistake and is not
> > > representative of the capabilities or the potential of SOA the
> > > architectural style. In this respect, I think the demo should be as
> objective as possible.
> > >
> > > I guess these comments will pretty-much rule me out of much else to
> > > do with this effort, but I think they are necessary. SOA should
> > > stand or not on its own merits, and I think it can do so. Yes, you
> > > have to implement it and there are easier ways than others, but
> > > these are implementation details, and I think they should not be
> > > represented as anything otherwise.
> > >
> > > Thanks for listening and good luck,
> > >
> > > ast
> > >
> > > On Thu, 2006-04-06 at 21:18, Cory Casanave wrote:
> > > > Enclosed expands on the "buyer/broker/manufacturer" example as a
> > > > proposed SOA demo. This is not yet done but I want to get it out
> > > > for feedback prior to doing much more work.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > I actually started to do an SOA based on the records management
> > > > spec and pulled-back because it seemed that much of it would just
> > > > take to much interpretation and explanation - something we don't
> > > > want for our first demo. There are a lot of special "archivist"
> > > > words that are outside of most of our comfort zones. So I
> > > > returned to the more simple (I know, some people think brain-dead)
>
> > > > broker scenario. At least it is easy to understand and implement
> > > > (a lot of systems should be able to be wrapped to implement & use
> > > > the services it in minutes to hours, which makes good demo).
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > I had hoped to get this to the next level, complete with WSDL
> > > > interfaces produced from the model, tested with simulation - but
> > > > that's not done yet but will be in a couple of days (work keeps
> > > > getting in the way). So the idea is to get at least 3 independent
>
> > > > participants to implement components behind the services to
> > > > bootstrap the community.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > One area I really stripped-down is the SOA messages, they are very
>
> > > > small, really just a demo. I looked at some of the industry
> > > > schema, but they are so big it would be a bit hard to follow. So
> > > > consider the tradeoff and provide feedback.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > There was also a question as to what EDOC was and what a SOA
> > > > community is - well, here it is. At least from one view.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > The question was asked, again, as to the purpose of the demo -
> > > > this is what I have:
> > > >
> > >
> > > > The goals of this demonstration are;
> > > >
> > >
> > > > * To provide a concrete example of how the SOA approach
> provides
> > > > business value to a community
> > > > * To provide confidence that the approach and technologies
> are
> > > > real - secure, reliable, performing and practical.
> > > > * To validate that independently developed applications can
> > > > interoperate using SOA standards
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > What I may want to add a non-goal; This is not a demo of what SOA
>
> > > > may become or possible future approaches, this is to show how the
> > > > best practice of SOA and supporting real technologies can provide
> > > > business value RSN (Real Soon Now). Just the idea that
> > > > independently developed systems can interoperate within an open
> > > > community is a big deal to much of the business community, old hat
>
> > > > to many of us, but still of great business value. So that is the
> essence of the business value.
> > >
> > > > We can then add to that all the great stuff we can do with our
> > > > cool tools, infrastructures, ontology-stuff and approaches. If we
>
> > > > can't, at lest, do this simple demo we should just go home.
> > > >
> > >
> > > > Of course, the goals are also a part of the consensus process,
> > > > your mileage may vary.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > We need to get consensus on the scenario real soon, not the
> > > > technology or SOA theory - but what the business intent of the SOA
>
> > > > is. If not "broker" we need well developed alternatives ASAP.
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Regards,
> > > >
> > >
> > > > Cory Casanave
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > __________________________________________________________________
> > > > ____
> > > > _________________________________________________________________
> > > > 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
>
>
>
> _________________________________________________________________
> 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. (011)
***************************************************************************************************
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 (012)
|