One thing I would also like to get out of this is
what seems to be the goal in the Executive Summary that was sent out for the
group.
"The SOA Blueprint validates the SOA specification
and blueprint through a real-world reference implementation and
provides a concrete implementation of the SOA model
through various vendors' technologies. Thus, SOA
Blueprints give enterprises real-world
implementations that can be used as a departure point for their own
implementations, which can also benefit from the
body of SOA best practices that the blueprints provide."
Essentially if you look at the W3C and Oasis
committee groups there are a variety of standards that are being defined
around services. I would like to see in what situations do people think
specific standards/implementations should be used.
For instance,
-
When would I use SAML within a service context, if at all?
-
When would I use Web Services Notifications?
-
How would I incorporate Web Services Composite Application Frameworks?
-
When would BPEL be appropriately used? Would it be integrated within a
service bus to managed orchestration of services?
-
Would I use Asynchronous Service Access Protocol standard?
-
Can the Web Services Distributed Management standard be the basis of a
service bus?
These are just some questions to kind of get a feel
for what I was thinking of as far as what the blueprints could
provide.
- Dan
-----Original Message-----
From: Marchant, Dan R.
Sent: Friday, September 16, 2005 12:17 PM
Subject: RE: [soa-blueprints] Suggestion
Robert,
To clarify what I meant by deliverables:
- A product of this group and not a product of an
actual service implementation
(service implementation - instance of a blueprint pattern I would
imagine)
To see if I understood your points here is a list
based on your comments:
1. Define a best practice approach of turning
business process/use cases, etc. into real project based deliverables that
align with the SOA blueprints
2. Establish a set of business use cases to drive
the definitions of SOA blueprints
3. Best practices on how to identify a blueprint to
use for a given real world application (assuming we flush out the
blueprints)
4. Patterns to follow in implementing an SOA
The question is which ones to address within this
group.
" I couldn't quite get a handle on whether our
group
is focused more on what is delivered vs. defining
some best practices on
how to create the deliverables."
This is a good question and one that I imagine we
need to answer before proceeding to far along.
I would imagine we are defining best practices on
how to create specific domain deliverables as well as patterns to follow
within SOA implementations.
- Dan
-----Original Message-----
Sent: Friday, September 16, 2005 11:51 AM
Subject: RE: [soa-blueprints] Suggestion
Daniel,
Here is my take on trying to continue this
thread. As I was trying
to
frame the problem - I couldn't quite get a handle
on whether our group
is focused more on what is delivered vs. defining
some best practices on
how to create the deliverables.
If we look at the process perspective, can we start
at what are the
prerequisites for beginning to build the SOA
blueprint? As an example,
it might be that a domain model and some business
use cases are required
to start building the blueprints. Part of our task could be showing
how
to take these prerequisite artifacts and translate
them into the set of
deliverables that comprise the SOA
blueprints.
Miko - I am anxious to see the information that
Steve contributed - you
did a great job of selling it last night :-)
Thanks,
Robert Porch
Booz Allen Hamilton
-----Original Message-----
Sent: Thursday, September 15, 2005 8:14 PM
Subject: [soa-blueprints] Suggestion
Miko,
I would like to suggest that maybe we have people
establish what they
want to see come out of the group.
If we can get people to send it through email we
can help to establish
an end target goal of the blueprints.
Also with that in mind I will contribute my
thoughts to this based on
some experience I have defining internal SOA
blueprints.
I see the blueprints can be established in a few
different ways.
First, an SOA blueprint can be how the services
interact and are managed
within the context of your service oriented
environment.
Second, an SOA blueprint can be an expression of
how common business
process can be evolved into an SOA.
Third, an SOA blueprint is specific to a domain
since the domain
establishes business processes and the SOA realizes
those processes.
The first can be leverage by the other ones. The
last one is a difficult
exercise to achieve and is very similar to having a
unified business
language (see the oasis standard).
Maybe in some ways the SOA blueprints can leverage
some of the work that
is done by the unified business language
standard.
These are some ideas to trigger more definition on
the end state of this
technical committee.
Thoughts?
Obviously the body of work that was done as part of
the middleware group
seems to straddle the First and Second
points.
Thanks,
Daniel Marchant
Architect
Wells Fargo