Hello and Happy New
Year to All,
Picking up the thread
below from last year: One of the ways we could organize ourselves would be to
use the SOALogic “brand” for all of the Enterprise and Project view
artifacts/deliverables where as the Generico “brand” could be used for lower
level artifacts that pertain to the design and architecture of applications,
services, and shared infrastructure of an SOA.
This would flow
naturally from where we are currently at since the SOALogic initiative has been
taking a top down approach where as the Generico specs are detailed centric and
lack a complete high level view.
In other words the
SOALogic deliverables would concern themselves with the Enterprise Architecture
and high level project view of the organization where as the Generico
deliverables would concern the structure of the lower level service components
in terms of technical architecture and design.
The first Genrico
deliverable could concern itself with the existing elements: That is the HR,
Payroll and the shared/common Security services. In the future we could envision
“Generico Finance”, “Generico CRM”, “Generico Service Registry”, etc…
deliverables.
I have attached a
coarse diagram to illustrate this…
Regards,
Reza
From:
marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com]
Sent: Thursday, December 15, 2005 12:24
PM
To:
jharby@gmail.com
Cc:
mmatsumura@infravio.com; soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Questions to
the Group
-----Original
Message-----
From: John Harby
[mailto:jharby@gmail.com]
Sent: Thursday, December 15, 2005 9:05
AM
To: Marchant, Dan
R.
Cc:
mmatsumura@infravio.com; soa-blueprints@lists.oasis-open.org
Subject: Re: [soa-blueprints] Questions
to the Group
I think this liason makes sense and since
we had discussed a third subgroup or subcommittee on the first call this could
be a function of that entity.
On 12/15/05, marchadr@wellsfargo.com
<marchadr@wellsfargo.com>
wrote:
I vote for keeping it on right now or
having a working committee where the Soa Logic working group and the Generico
group can exchange information to keep the approaches pretty unified.
Maybe the SoaLogic points to Generico for the supporting part of
it.
-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com]
Sent:
Thursday, December 15, 2005 8:42 AM
To: John Harby; Marchant, Dan
R.
Cc: soa-blueprints@lists.oasis-open.org
Subject:
RE: [soa-blueprints] Questions to the Group
Since there are
existing implementations of Generico, we should certainly not rock the boat
too greatly, however, creating a context where SOAlogic and Generico can
sensibly be related is a good idea imho. Is there interest in creating
SOALogic and Generico subcommittees?
Miko
-----Original
Message-----
From: John Harby
[mailto:jharby@gmail.com]
Sent: Thu 12/15/2005 8:39 AM
To: marchadr@wellsfargo.com
Cc: soa-blueprints@lists.oasis-open.org
Subject: Re: [soa-blueprints] Questions to the
Group
I disagree. I am in
favor of the discussion on the last call which proposed separating the
Generico update activity and developing the others in parallel. One primary
reason is the maturity of Generico combined with the existing implementations.
On 12/15/05, marchadr@wellsfargo.com <marchadr@wellsfargo.com>
wrote:
1. Do we want to combine the SoaLogic (previously CoaLogic) with Generico
Requirements?
Proposal
of how it would fit
together:
-
"HR Supporting Service" would be based entirely on the Generico Requirements
contribution
-
Generico would be put into the following sections
-
HR Supporting Service
Model
-
HR Supporting Service
Architecture
-
HR Supporting Service
Mapping
This would give the Case Study currently on Kavi "working folder" the
following parts:
-
An Enterprise View - Soa
Logic
-
A Project View - Soa Logic product introduction "lawn
vacuum"
-
A Supporting Service View -
Generico
Would help in having the same people that would be working on a generico
update contributing to a more exhaustive case study/blueprint realization.
2. Do we have a framework/blueprints document like the one on Kavi "working
folder" to illustrate the general patterns that anyone can realize with the
reference of a realization being the case study document?
3. Do we have a seperate methodology document or set of documents that
faciliate a user of the framework/blueprints document to get to a
realization?
So the proposal would be to have the following deliverables:
DOC-1. SOA Adoption Blueprints - creates a framework type document for
anything that can be
generalized
-
contains the work from the SOA Blueprints Concepts document from the
Middleware group, within service types section
-
contains some parts of the Capgemni contribution as a service model
section
DOC-2. SOA Case Study - Soa Logic - incorporates the work from the generic
requirements document and the existing Soa Logic content
DOC-3. SOA Methodology - builds on the Capgemni
contributions
Thoughts,
Dan