Somehow the issue of "capacity of the modeling approach" is
missed (over and
over again).
Fact: SOA cannot now be
implemented in a way that is open to normal human
interaction.
Claim:
this is not a technical issue, it is a design issue (IT has been
designing
the wrong type of human computer interfaces and is
resisting
change).
The model driven approach from OMG has to
assume an authority role and this
authority role is delegated to IT
community. The effort to delegate to the
user communities is not made
and is (deemed) too hard. But it is too hard
because the IT community
resists this effort (and because the issues are
really hard - when defined by
the first school).
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).
I know that the
position of several (Cory and Joe) will be ... well we
cannot do anything
"over the horizon". This is a volunteer group. etc
But this
"over the horizon constraint" is an assertion on Cory's and Joe's
part; and
not necessarily what this SOA CoP community might wish to do.
Any
comments?
Andrew's proposal and his layout of a "collaborative
approach to scenario
building" might be explored a little more.
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?
-----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