By "my description of the concept", do you mean Paving the Bare Spots? I've little to add beyond that. FYI There's a link to it in the outline and at http://giglite.com
Reflecting on today's teleconf, I heard a lot of smart, dedicated people eager to explain/advocate the wonders of the SOA journey. I sat there mystified, knowing full well that nobody's going anywhere with this yawning chasm at our feet... the lack of a secure interoperable SOA infrastructure. Feeling very out of place given the obvious desire to run on (and on! and on!) about the wonders of this journey, all eager to not get "hung up" on "techie details", like that danged canyon at our feet.
Folks, SOA's not going anywhere (in govt) until a workable SOA infrastructure is in place; i.e. a usable bridge over the secure+interoperable chasm.
Best I can suggest is let the planners do their planning elsewhere in the document, and focus our section very specifically on *doing*; moving the ball ahead by laying out exactly what needs to be done before their journey can even begin. Impatience with "techie details" be damned; you can't build a bridge without crossing techie T's, as much as the planners might wish otherwise.
1) Stop building interoperable infrastructures in project stovepipes (NCES, FCS, etc).
2) Establish an enterprise space staffed by cross-project collaboration (http://giglitie.org or similar)
3) Build a SOA infrastructure within enterprise space based on pre-existing prototypes from existing projects (NCES, FCS, etc) through an extended process of cross-project collaboration.
4) Test, Fix, Evolve, Deploy, Wash, Rinse, Repeat...
--
Brad Cox, Ph.D: Enterprise Architect, Binary Group
Mail: bcox@xxxxxxxxxxxxxxx; Phone: 703 361 4751
Chat: brdjcx@AIM; Web: http://virtualschool.edu
---------- Original Message
-----------
From: <chris.gunderson@xxxxxxxxx>
To: "'Vijay Raghavan -Towerstrides'"
<vijay.raghavan@xxxxxxxxxxxxxxxx>, "'Rollins, John'"
<jrolli01@xxxxxxxxxx>, "'Dov J. Levy'"
<Dov.Levy@xxxxxxxxxxxxx>, <RFarrow@xxxxxxxxxxxxxx>,
<bcox@xxxxxxxxxxxxxxx>
Cc: <pgfsoa-infra@xxxxxxxxxxxxxx>
Sent: Fri, 9 Feb 2007 18:03:26 -0500
Subject: RE: PGFSOA-Infrastructure- Key messages
> Friends, Great inputs?
Per
discussion with the SOA COP project, Dov?s earlier comment, and a
running
conversation Brad and I have been having, I think we should also emphasize
the
need
> to include a shared ?lab?
as
part of the infrastructure. I defer to Brad?s description of the
concept.
>
> Another thought?. Should
we
emphasize that SOA is at least as much about B2B as P2B?
>
> Best, Chris
>
>
> From: Vijay
Raghavan
-Towerstrides [mailto:vijay.raghavan@xxxxxxxxxxxxxxxx]
>
Sent: Friday, February 09,
2007
1:39 AM
>
To: 'Rollins, John'; 'Dov
J.
Levy'; RFarrow@xxxxxxxxxxxxxx; bcox@xxxxxxxxxxxxxxx
>
Cc:
pgfsoa-infra@xxxxxxxxxxxxxx;
Chris.Gunderson@xxxxxxxxx
>
Subject:
PGFSOA-Infrastructure-
Key
messages
>
>
> Team
> I took the liberty of continuing
this
thread instead of posting new. Please advice if it has to be
new.
>
> John/Dov/Brad I had the pleasure of
going
through each of your analysis and comments.
>
> I would like to add or reiterate some
of
the key messages here. As always please feel free to comment or
advice.
>
> 1) Network Infrastructure with focus
on
Transport technologies: We all agree one of the enablers for SOA is Web
services
and one of the critical components of SOA Governance is SLA.
>
> How Web Services affect
Network?
> Renewed IT investments are driven
by
increasing demands for more efficient communications and information
sharing
across disparate agency networks. Increasing volumes of data required
for
decision support results in progressively more complex data
management
environments. Web services, which use distributed software programs and
applets
that form building blocks for application development, operate
across
geographically dispersed computing platforms. The need to reference
multiple
applications physically residing in geographically distributed
locations
creates additional traffic and service management challenges. Controlling
large
quantities of intersystem traffic requires robust, flexible networks
that
provide high levels of network performance (i.e., low latency and
high
throughput) to enable a high-quality user
experience
>
> Why SLA
(High Availability) affect
Network
> Agencies
increasingly focus on data availability and protection as they
implement
solutions for continuity of operations (COOP) and disaster recovery (DR).
Data
transport between primary and backup locations, often separated by hundreds
or
thousands of miles, is integral to effective COOP and DR strategies. As
data
backup needs increase, agencies must weigh the risk versus importance of
the
data and balance this by providing an affordable, secure and highly
adaptable
network solution. Increased user demands on agency networks, coupled with the
growth
in latency-intolerant and bandwidth-hungry applications, often exceed
the
capabilities of existing network
infrastructure.
>
>
>
Disjointed network architecture with multiple transport technologies managed
by
a mix of in-house and third parties contribute to the limited
interoperability
of networks and applications. Taken together, these factors drive
network
planners to seek flexible, adaptable and manageable WAN solutions. These
WAN
solutions include private optical networks and managed wavelength
services
tailored to the networking requirements and cost constraints of
government
agency
networks.
>
>
> 2)
Portal Infrastructure: To implement a service-oriented architecture
(SOA),
companies must consider what steps and technologies are involved.
Portals
represent a logical first step in the
process.
> A
portal
can clarify the sometimes confusing SOA concept for an organization?s
IT
staff and end users. An enterprise portal project pulls together the
disparate
groups involved in cross-enterprise technology projects. No other technology
is
more tangible than a portal, and IT professionals and users can relate to
it.
Portal products have leveraged service-oriented concepts since 1998, so
they
provide a natural approach to SOA. It leverages Web services
extensively.
? It leverages portlets, which consume services or communicate to
provide
orchestrated flows and on-the-glass composite
applications.
>
> 3)
Meta
Data Management: Although promising as a new method for building
applications,
SOA will fail if long-standing data quality, data redundancy and
semantic
inconsistency issues are not addressed.
Unless
> Organizations
take a disciplined approach toward enterprise wide information management;
the
SOA method of development may become fraught with highly redundant
and
inconsistent data stores and data integration applications, which is
no
different than today's reality in most large enterprises or Gov.
Organizations.
Complex or conflicting sources, inconsistent semantics and poor quality
data
(previously hidden and protected in tightly coupled systems) are
suddenly
exposed during service composition, creating confusion as multiple
developers
try to achieve efficiency and
reuse.
>
>
> More
to
follow.
>
> Thanks
>
> Vijay
>
>
>
>
> From: Rollins, John
[mailto:jrolli01@xxxxxxxxxx]
>
Sent: Thursday, February 08,
2007
5:56 PM
>
To: Dov J.
Levy;
RFarrow@xxxxxxxxxxxxxx; bcox@xxxxxxxxxxxxxxx;
vijay.raghavan@xxxxxxxxxxxxxxxx; Rollins, John
>
Cc:
pgfsoa-infra@xxxxxxxxxxxxxx
>
Subject: Key
messages
>
> All,
> I
thought I'd take a shot at a few key SOA Infrastructure messages. No pride
of
ownership so feel free to comment.
> 1)
The same principles that applied in managing
"pre-SOA"
infrastructures also apply here. The platform technologies such as
the
networks, protocols, OS's, storage, computers, etc. are essentially the
same.
The SOA Infrastructure, the subsequent services and applications are
still
beholden to that platform and must be managed in a similar way. Therefore,
the
same approaches for network/enterprise management are relevant, i.e. I have
to
make systems available, secure, monitorable, accountable,
etc.
> So
don't throw away your enterprise management techniques.
> 2)
In fact, SOA makes enterprise management a little harder. At its essence
it
encourages ad-hoc connections across the infrastructure. Consumers may
use
services in ways never conceived, and of course with unreasonable
expectations.
This can stress parts of the infrastructure that were architected with
a
"known-connection" mindset. Therefore, you must manage
the
infrastructure to ensure service SLA
compliance, balanced infrastructure load, and priority resolution to
accomplish
mission goals. New tools that understand the SOA platform should be part of
the
SOA
portfolio.
> Greater
freedom in employing services to solve problems requires greater management
of
the infrastructure.
> 3)
Policies need to be declarative, centralized, and executable.
Declarative:
Human readable and represented as data, not code, so that they can
be
understood and changed. Centralized: From an operator perspective, he/she
must
be able to access the relevant policies. These policies may be federated
across
different stores, but the operator should have one access point.
Executable:
Policy Enforcement Engines, wherever they may live in the enterprise, must
be
able to execute the policies within the context that they are executed.
> A
self-organizing set of services requires accessible, flexible,
changeable
management policies.
> 4)
The communications infrastructure used to invoke services, send messages,
etc.
must support flexible message exchange patterns. a) Lengthy
request-response
transactions within a distributed environment can cause chaos.
The
infrastructure should provide a range of invocation patterns that
enable
clients to experience synchronous operations, while the
infrastructure
implements asynchronous behavior. b) The infrastructure should allow
service
locations to be hidden. The client of a service should not be bound to
its
location; the infrastructure should take care of the routing and QoS.
c)
Point-to-point messaging often used by publish and subscribe components
-
especially with centralized broker scenarios - can cause immense
performance
problems. Alternatives that allow either federation of the publication
or
multicast of the information should be
available.
> The
messaging plumbing is the key component to enabling services - you can't
use
what you can't get to.
> 5)
Service profiles should not only state what consumers expect of the
service,
but also what the service expects of the infrastructure. A service can't
meet
its SLA's if it expects performance, QoS,
etc.
that can't be delivered by the infrastructure. These service profile
statements
could be inputs to management
policies.
> There's
no sense offering services that can't meet their SLA's.
> Thanks,
>
John
------- End of Original Message
-------
|
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/pgfsoa-infra/
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/pgfsoa-infra/
Shared Files: http://colab.cim3.net/file/work/pgfsoa/pgfsoa-infra/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?PracticalGuideToFederalSOA
Community Portal: http://colab.cim3.net/
To Post: mailto:pgfsoa-infra@xxxxxxxxxxxxxx (01)
|