Title: Message
Tim,
SOA RM is the generalized case for XML based
content in the large.
ebSOA is the specialized case around B2B
electronic business and
business information exchanges.
As Duane points out ebSOA makes use of and
references SOA RM - however
ebSOA should be a
self-contained and supporting entity that works - by
leveraging the coupling between the ebSOA components and their
characteristics and behaviours.
Clearly much has been penned WRT ebXML components -
and so
how they deploy to give you an ebSOA is the pieces to the puzzle.
As Duane notes there are three levels to this story
- conceptual, logical, physical - for more
on this see the PPT #3 @ http://ebxmlpresentations.com
Enjoy, DW
----- Original Message -----
From:
To: ; ; ;
Sent: Wednesday, December 15, 2004 3:58
PM
Subject: RE: [ebsoa] Does SOA Require
Registry-Based Dynamic Discovery?
This discussion sounds like its coming from
a service/application only perspective. We need to scope the
SOA RM very carefully. If we are looking for a SOA RM that can be
applied in any domain, then I am still not a proponent of calling it an 'SOA'
RM. If I apply all components of the SOA reference model, then I have an
SOA, right? The more abstract the reference model the more delta you
have between implementations/specializations, so the RM really would be only
be valuable with specializations as a deliverable. Call it a
'web services' or equivalent RM, but not an SOA RM. The argument that
almost everything is an SOA does not hold water with me. SOA in its
final tangible form has a considerable number of requirements that make it
unique. I see an SOA RM like a 'three-tier' architecture model
that would be more effective, we all know that is www/app/db right? http://www.sei.cmu.edu/str/descriptions/threetier.html
What is it for SOA? I argue it should at a minimum include a
function/process for a registry, in addition it should also include at a
minimum 'support' for secure communication.
TM
From: Yunker, John [mailto:]
Sent: Wednesday, December 15, 2004 12:35 PM
To: Chiusano
Joseph; Matthew MacKenzie; ebSOA OASIS TC
Subject: RE: [ebsoa] Does
SOA Require Registry-Based Dynamic Discovery?
First, let me agree with Matt that "ebXML Registry
(big R)" is just one way of discovery, however any discovery requires that
what is being discovered is registered . Let me further assert that
discovery outside of a tightly controlled group requires some sort of registry
(small r) mechanism for discovery to be effective. These are the
assumptions I started with.
Sorry if your initial question was only directed
towards big R registry!!! :-)
-----Original Message-----
From: Chiusano
Joseph [mailto:]
Sent: Wednesday, December
15, 2004 9:13 AM
To: Yunker, John; Matthew MacKenzie; ebSOA OASIS
TC
Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic
Discovery?
Thanks John - I'm going to take all 4 parts of your excellent
comments below separately, and comment further. You basically
said:
An
SOA without registry by definition is limited
[JMC] Limited in what way? I
assume because there is no dynamic discovery, and if the interface
requirements and/or service location changed, it would require an
out-of-band mechanism. I would assert that it is limited if the technical
and business requirements led to an anticipation of updates to the interface
requirements and/or service location on a regular basis - otherwise, is it
*really* limited?
[yunker] Limited in the ability
of the SOA to support broad groups or
communities.
An
SOA without registry by definition is
private
[JMC] So if a SOA-based system is being used
among 2 or more organizations, and the technical and business requirements
*do not lead* to an anticipation of updates to the interface requirements
and/or service location on a regular basis, then the SOA is "private"? Seems
orthogonal to me...
[yunker] Private in that some
out-of-band communication must be
supported.
An
SOA with a registry is open
[JMC] Open to
who? If it does not have a registry, it is not
open?
[yunker] Open, in that you
don't need to be on the mailing list of the service provider to know that a
service is available.
An
SOA with a registry is
dynamic
[JMC] Agree!
(one out of 4 ain't bad ;)
Thanks again!
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants
to the World
From: Yunker, John
[mailto:]
Sent: Wednesday, December 15, 2004
12:06 PM
To: Chiusano Joseph; Matthew MacKenzie; ebSOA OASIS
TC
Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic
Discovery?
From my view the "registry requirement" is
more a function of the distributed nature of the participants, the number
and type of services, and the amount of change. A registry provides
a method for decoupling "the use of an SOA" from "direct
communication of the participants about HOW to use the
SOA".
An SOA without registry by definition is limited
and private
An SOA with a registry is open and
dynamic
John
-----Original Message-----
From: Chiusano
Joseph [mailto:]
Sent: Wednesday,
December 15, 2004 9:01 AM
To: Matthew MacKenzie; ebSOA OASIS
TC
Subject: RE: [ebsoa] Does SOA Require Registry-Based
Dynamic Discovery?
Thanks Matt. From that I take:
- Discovery in general is required for SOA (cannot function
without it)
- Whether it is (what I will call) "fundamental" discovery -
meaning your first example below - or "registry-based" discovery depends
on technical and business requirements.
I just cannot foresee trying to convince a current or potential
customer that they have to put up $XX,XXX for a registry product if the
technical and business requirements do not call for it, just to comply
with someone's definition of the term "SOA".
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology
Consultants to the World
From: Matthew MacKenzie
[mailto:]
Sent: Wednesday, December 15, 2004
11:57 AM
To: Chiusano Joseph; 'ebSOA OASIS
TC'
Subject: RE: [ebsoa] Does SOA Require Registry-Based
Dynamic Discovery?
My opinion is
that a registry is nothing more than a very explicit service discovery
device.
An SOA does
need a method of discovering services, and consuming them, but this
method may in some cases be subtle. For example, my SOA may
operate on the premise that consumers all are aware of an enumeration
of service types, and their port numbers (think /etc/services in the
unix world), and allowable IP ranges for finding services.
Clients may be configured something like:
{
Services imap, http, ssh, daytime, pop3,
portmap
IPRange 192.168.0.0/24
}
A client with
such a configuration does have a way of discovering services that are
available to it, and of course, a way of binding to
them.
Contrast this
with a registry driven SOA:
{
ServiceRegistry http://foo/registry
}
The only
difference is in the implementation detail and verbosity of
information available. Conceptually, they are the
same.
--Matt
MacKenzie
From:
Chiusano Joseph [mailto:]
Sent: Wednesday, December 15,
2004 11:38 AM
To:
ebSOA OASIS TC
Subject: [ebsoa] Does SOA Require
Registry-Based Dynamic Discovery?
What is the TC's opinion
on the answer to the question of "does SOA require registry-based
dynamic discovery"? I know that Discovery is a pattern in the .047
spec, which leads me to believe that the position is that SOA does not
*require* registry-based discovery.
For example, suppose
that:
- 2 organizations are
using Web Services in a "SOA-like" manner (meaning shared services
represented as Web Services, that are invoked by other Web Services).
- There is no
registry-based dynamic discovery, perhaps because the organizations
agree that these service locations are completely (or relatively)
stable, and that if the locations change, there will be some
out-of-band mechanism for propagating updated WSDL
documents
Are these 2 organizations
therefore *not* using a service-oriented architecture? That is, does
the second point completely negate the first? Or, is it all really a
matter of business and technical
requirements?
Kind
Regards,
Joseph
Chiusano
Booz Allen
Hamilton
Strategy and Technology
Consultants to the World
