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