Members of the IETF Network Configuration (NETCONF) Working Group have
released "NETCONF Configuration Interface Advertisement with WSDL
and XSD" as an updated I-D. This IETF Working Group has created the
NETCONF protocol as a standard configuration protocol between a
network management system and network devices. By using this unified
management/configuration protocol, operators can reduce management/
configuration cost. The updated memo describes a configuration
interface advertisement method for NETCONF device developers. In the
proposal, the developers take a configuration interface definition
information of target NETCONF devices. On their development environment,
they generate stab classes to control the devices. The NETCONF device
advertises their configuration interface by a WSDL file. The WSDL
file describes message type of each NETCONF operation of the device.
The WSDL file contains XML Schema in its types element and describes
definition of the types definition used to configuration data. By
this configuration interface advertisement, Network management System
(NMS) developers can improve their development efficiency of the NMS.
Wednesday, March 12, 2008
IDS Scheer Supports OASIS Reference Model, ARIS SOA Architect
IDS Scheer has announced support for the OASIS SOA Reference Model used
in tandem with ARIS SOA Architect. The structure and management of a
business process-oriented service landscape requires close cooperation
between specialized departments and IT within companies. IDS Scheer has
leveraged its expanded methodology for Business-Driven SOA into
developing comprehensive support for describing, planning and managing
services -- designed specifically for this type of collaboration within
an organization. The new methodology, based on the OASIS SOA Reference
Model, categorizes services using business criteria with a concentration
on those with the greatest strategic importance -- the end result is
mitigation of risks within SOA projects. SOA projects are designed to
help companies become more flexible to react efficiently to changes
in the market. With the new reference model, these projects can now be
achieved directly without moving from pillar to post because the
development and management of the services work in conjunction with
the relevant business unit. The technical specification of individual
services within a SOA is a new feature and it ensures the continuing
provision of target-oriented service development in IT and subsequent
service reuse. This methodology is fully integrated into ARIS SOA
Architect. Existing models for describing IT landscapes and web services
can be reused, thus securing investments and enabling service orientation
and Enterprise Architecture measures to work together. ARIS SOA Architect
reduces implementation costs considerably because redundant
implementations within a service are compiled, thereby producing an
efficient service architecture. If a service fails, alternative
implementations can be identified with ease.
in tandem with ARIS SOA Architect. The structure and management of a
business process-oriented service landscape requires close cooperation
between specialized departments and IT within companies. IDS Scheer has
leveraged its expanded methodology for Business-Driven SOA into
developing comprehensive support for describing, planning and managing
services -- designed specifically for this type of collaboration within
an organization. The new methodology, based on the OASIS SOA Reference
Model, categorizes services using business criteria with a concentration
on those with the greatest strategic importance -- the end result is
mitigation of risks within SOA projects. SOA projects are designed to
help companies become more flexible to react efficiently to changes
in the market. With the new reference model, these projects can now be
achieved directly without moving from pillar to post because the
development and management of the services work in conjunction with
the relevant business unit. The technical specification of individual
services within a SOA is a new feature and it ensures the continuing
provision of target-oriented service development in IT and subsequent
service reuse. This methodology is fully integrated into ARIS SOA
Architect. Existing models for describing IT landscapes and web services
can be reused, thus securing investments and enabling service orientation
and Enterprise Architecture measures to work together. ARIS SOA Architect
reduces implementation costs considerably because redundant
implementations within a service are compiled, thereby producing an
efficient service architecture. If a service fails, alternative
implementations can be identified with ease.
Extensible Resource Identifier (XRI) Resolution Version 2.0
OASIS announced the release of an approved Committee Draft 03 of
"Extensible Resource Identifier (XRI) Resolution Version 2.0" for
fifteen-day public review 26-March-2008. The Relax-NG schema files
referenced normatively in the prose specification document are also
available separately. Extensible Resource Identifier (XRI) provides
a uniform syntax for abstract structured identifiers. Because XRIs
may be used across a wide variety of communities and applications
(as Web addresses, database keys, filenames, object IDs, XML IDs,
tags, etc.), no single resolution mechanism may prove appropriate for
all XRIs. However, in the interest of promoting interoperability,
this specification defines a simple generic resource description
format called XRDS (Extensible Resource Descriptor Sequence), a
standard protocol for requesting XRDS documents using HTTP(S) URIs,
and standard protocol for resolving XRIs using XRDS documents and
HTTP(S) URIs. Both generic and trusted versions of the XRI resolution
protocol are defined (the latter using HTTPS (RFC 2818) and/or
signed SAML assertions. In addition, an HTTP(S) proxy resolution
service is specified both to provide network-based resolution services
and for backwards compatibility with existing HTTP(S) infrastructure.
Resolution is the function of dereferencing an identifier to a set
of metadata describing the identified resource. For example, in DNS,
a domain name is typically resolved using the UDP protocol into a set
of resource records describing a host. If the resolver does not have
the answer cached, it will start by querying one of the well-known
DNS root nameservers for the fully qualified domain name. Since domain
names work from right to left, and the root nameservers know only
about top level domains, they will return the NS (name server)
records for the top-level domain. The resolver will then repeat the
same query to those name servers and 'walk down the tree' until the
domain name is fully resolved or an error is encountered. A simple
non-recursing resolver will rely on a recursing nameserver to do
this work. For example, it will send a query for the fully qualified
domain name docs.oasis-open.org to a local nameserver. If the
nameserver doesn't have the answer cached, it will resolve the domain
name and return the results back to the resolver (and cache the
results for subsequent queries). XRI resolution follows this same
architecture except at a higher level of abstraction, i.e., rather
than using UDP to resolve a domain name into a text-based resource
descriptor, it uses HTTP(S) to resolve an XRI into an XML-based
resource descriptor called an XRDS document.
"Extensible Resource Identifier (XRI) Resolution Version 2.0" for
fifteen-day public review 26-March-2008. The Relax-NG schema files
referenced normatively in the prose specification document are also
available separately. Extensible Resource Identifier (XRI) provides
a uniform syntax for abstract structured identifiers. Because XRIs
may be used across a wide variety of communities and applications
(as Web addresses, database keys, filenames, object IDs, XML IDs,
tags, etc.), no single resolution mechanism may prove appropriate for
all XRIs. However, in the interest of promoting interoperability,
this specification defines a simple generic resource description
format called XRDS (Extensible Resource Descriptor Sequence), a
standard protocol for requesting XRDS documents using HTTP(S) URIs,
and standard protocol for resolving XRIs using XRDS documents and
HTTP(S) URIs. Both generic and trusted versions of the XRI resolution
protocol are defined (the latter using HTTPS (RFC 2818) and/or
signed SAML assertions. In addition, an HTTP(S) proxy resolution
service is specified both to provide network-based resolution services
and for backwards compatibility with existing HTTP(S) infrastructure.
Resolution is the function of dereferencing an identifier to a set
of metadata describing the identified resource. For example, in DNS,
a domain name is typically resolved using the UDP protocol into a set
of resource records describing a host. If the resolver does not have
the answer cached, it will start by querying one of the well-known
DNS root nameservers for the fully qualified domain name. Since domain
names work from right to left, and the root nameservers know only
about top level domains, they will return the NS (name server)
records for the top-level domain. The resolver will then repeat the
same query to those name servers and 'walk down the tree' until the
domain name is fully resolved or an error is encountered. A simple
non-recursing resolver will rely on a recursing nameserver to do
this work. For example, it will send a query for the fully qualified
domain name docs.oasis-open.org to a local nameserver. If the
nameserver doesn't have the answer cached, it will resolve the domain
name and return the results back to the resolver (and cache the
results for subsequent queries). XRI resolution follows this same
architecture except at a higher level of abstraction, i.e., rather
than using UDP to resolve a domain name into a text-based resource
descriptor, it uses HTTP(S) to resolve an XRI into an XML-based
resource descriptor called an XRDS document.
Surveys from BPTrends and BEA Reflect on 'The State of BPM in 2008'
In the past couple of weeks, two major reports on "The State of BPM
in 2008" were published. The first one (54 pages) was based on a
survey filled by 274 respondents and published by Paul Harmon and Celia
Wolf, Executive Editor and Publisher of BPTrends.com. The second one
(36 pages) was based on analyst reports, articles and a survey of
customers and was published by BEA with Sandy Kemsley as a co-author.
BPTrends reports that a wide variety of process standards are being
used by the respondents. However, BPMN shows the strongest momentum
with 41% (from 22% in 2006) and BPEL showing a modest progression
with 26 % (from 23% in 2006). XPDL (6%) and the OMG Process Metamodel
(7%) are far behind while UML (30%) and CMM/CMMI (28%) remain fairly
stable. The most popular tools to capture business processes remained
Visio and PowerPoint. The respondents deployed a wide spectrum of
BPMS suites with a prominence of the leading SOA infrastructure
vendors: IBM (including FileNet), SAP, and Oracle.
in 2008" were published. The first one (54 pages) was based on a
survey filled by 274 respondents and published by Paul Harmon and Celia
Wolf, Executive Editor and Publisher of BPTrends.com. The second one
(36 pages) was based on analyst reports, articles and a survey of
customers and was published by BEA with Sandy Kemsley as a co-author.
BPTrends reports that a wide variety of process standards are being
used by the respondents. However, BPMN shows the strongest momentum
with 41% (from 22% in 2006) and BPEL showing a modest progression
with 26 % (from 23% in 2006). XPDL (6%) and the OMG Process Metamodel
(7%) are far behind while UML (30%) and CMM/CMMI (28%) remain fairly
stable. The most popular tools to capture business processes remained
Visio and PowerPoint. The respondents deployed a wide spectrum of
BPMS suites with a prominence of the leading SOA infrastructure
vendors: IBM (including FileNet), SAP, and Oracle.
Services-Based Enterprise Integration Patterns Made Easy
This serial article presents some of the central concepts and features
of enterprise integration patterns, introducing several basic concepts
and features involved in Service-Oriented Architecture (SOA). Part 1
and Part 2 of this series describe the basic concepts essential for
understanding a services-based integration pattern. These concepts
include loose coupling, code reuse and layering, language and platform
independence, language independent interface, the idea of discovering
a remote object at run time, invoking methods remotely, and asynchronous
messaging for scalability. To improve on RPC functionality, two methods
are used: (1) Distributed objects, also known as the Object Request
Broker (ORB): This approach focuses on code reuse and language
independence. (2) Asynchronous messaging: This approach addresses the
problem of tight coupling between applications. In addition to
introducing the benefits of object orientation, such as inheritance,
polymorphism, and encapsulation, CORBA introduced a number of new
features. Probably the most important was the concept of ORB, which
extracted the code for marshaling input and output arguments and the
code for communication from the client and server applications into a
separate software component. In addition, ORB provides a facility to
get a reference to a remote object so that methods can be invoked on
that remote object. This separation let the same code be reused by
many applications and allowed a certain amount of decoupling between
the applications by moving away from point-to-point integration. This
move away from point-to-point integration may be considered the first
step in the evolution of the concept of ESB. A parallel development
based on asynchronous messaging contains the seeds for the development
of another type of ESB. This type of ESB provides a more scalable
solution than the ESB type based on ORB. In asynchronous messaging,
the client or client object sends a message to the target application,
but doesn't wait for the response to continue its work. This leads
to a certain amount of decoupling between the applications involved.
Thus asynchronous messaging may be employed as the integration basis
if high transaction volumes are expected. In messaging, the
applications don't communicate with each other directly and don't
have a dedicated communication link established between them. Instead,
they communicate indirectly through queues. A central message broker
can receive messages from different applications, determine the
correct destination for each message type, and route the message to
the appropriate destination application. This lets applications
communicate with each other without knowing the location of the
receiving applications.
of enterprise integration patterns, introducing several basic concepts
and features involved in Service-Oriented Architecture (SOA). Part 1
and Part 2 of this series describe the basic concepts essential for
understanding a services-based integration pattern. These concepts
include loose coupling, code reuse and layering, language and platform
independence, language independent interface, the idea of discovering
a remote object at run time, invoking methods remotely, and asynchronous
messaging for scalability. To improve on RPC functionality, two methods
are used: (1) Distributed objects, also known as the Object Request
Broker (ORB): This approach focuses on code reuse and language
independence. (2) Asynchronous messaging: This approach addresses the
problem of tight coupling between applications. In addition to
introducing the benefits of object orientation, such as inheritance,
polymorphism, and encapsulation, CORBA introduced a number of new
features. Probably the most important was the concept of ORB, which
extracted the code for marshaling input and output arguments and the
code for communication from the client and server applications into a
separate software component. In addition, ORB provides a facility to
get a reference to a remote object so that methods can be invoked on
that remote object. This separation let the same code be reused by
many applications and allowed a certain amount of decoupling between
the applications by moving away from point-to-point integration. This
move away from point-to-point integration may be considered the first
step in the evolution of the concept of ESB. A parallel development
based on asynchronous messaging contains the seeds for the development
of another type of ESB. This type of ESB provides a more scalable
solution than the ESB type based on ORB. In asynchronous messaging,
the client or client object sends a message to the target application,
but doesn't wait for the response to continue its work. This leads
to a certain amount of decoupling between the applications involved.
Thus asynchronous messaging may be employed as the integration basis
if high transaction volumes are expected. In messaging, the
applications don't communicate with each other directly and don't
have a dedicated communication link established between them. Instead,
they communicate indirectly through queues. A central message broker
can receive messages from different applications, determine the
correct destination for each message type, and route the message to
the appropriate destination application. This lets applications
communicate with each other without knowing the location of the
receiving applications.
Improving Performance of Healthcare Systems with SOA
Healthcare organizations today are challenged to manage a growing
portfolio of systems. The cost of acquiring, integrating, and
maintaining these systems are rising, while the demands of system
users are increasing. Organizations must address evolving clinical
requirements as well as support revenue cycle and administration
business functions. In addition, demands are increasing for
interoperability with other organizations to regionally support
care delivery. Service oriented architecture offers system design
and management principles that support reuse and sharing of system
resources across the healthcare organization. SOA does not require
the re-engineering of existing systems. With SOA, existing processing
can be combined with new capabilities to build a library of services
that are used as a part of solutions. Using shared services that
are aligned with business processes, SOA strengthens interoperability
while reducing the need to synchronize data between isolated systems.
Services may be made available, no matter their location, to create
solutions that reach beyond the desktop, the department, and the
healthcare organization.
portfolio of systems. The cost of acquiring, integrating, and
maintaining these systems are rising, while the demands of system
users are increasing. Organizations must address evolving clinical
requirements as well as support revenue cycle and administration
business functions. In addition, demands are increasing for
interoperability with other organizations to regionally support
care delivery. Service oriented architecture offers system design
and management principles that support reuse and sharing of system
resources across the healthcare organization. SOA does not require
the re-engineering of existing systems. With SOA, existing processing
can be combined with new capabilities to build a library of services
that are used as a part of solutions. Using shared services that
are aligned with business processes, SOA strengthens interoperability
while reducing the need to synchronize data between isolated systems.
Services may be made available, no matter their location, to create
solutions that reach beyond the desktop, the department, and the
healthcare organization.
Web Security Experience, Indicators and Trust: Scope and Use Cases
W3C has announced an update from the Web Security Context Working Group
in the form of a published Note "Web Security Experience, Indicators
and Trust: Scope and Use Cases." Web user agents are now used to engage
in a great variety and number of commercial and personal activities.
Though the medium for these activities has changed, the potential for
fraud has not. The W3C Web Security Context Working Group, as part of
the Security Activity, was chartered to recommend user interfaces that
help users make trust decisions on the Web. The updated Note explains
the group's technical aims, complementing the WG charter. It explains
what the group aims to achieve, what technologies may be used, and how
proposals will be evaluated. This elaboration is limited to the group's
technical work and does not cover additional activities the group
intends to engage in, such as ongoing outreach and education. The work
outlined in the document is expected to take existing standards and
best practices into account; where relevant, such existing work will
be leveraged. (1) Security information within the Working Group's scope
will be catalogued, along with corresponding presentations and user
interpretations reported in user studies. (2) Members will analyze
common use cases to determine what security information the user needs
to safely accomplish their current task and recommend security
information that should, or should not, be presented in each case. (3)
The WG will recommend a set of terms, indicators and metaphors for
consistent presentation of security information to users, across all
web user agents. For each of these items, the Working Group will
describe the intended user interpretation, as well as safe actions
the user may respond with in common use cases. (4) Group members will
recommend presentation techniques that integrate the consumption of
security information by the user into the normal browsing workflow.
Presenting security information in a way that is typically ignored by
the user is of little value. (5) The Working Group will recommend
presentation techniques that mitigate deceptive imitation, or hiding,
of the user agent's presentation of security information.
in the form of a published Note "Web Security Experience, Indicators
and Trust: Scope and Use Cases." Web user agents are now used to engage
in a great variety and number of commercial and personal activities.
Though the medium for these activities has changed, the potential for
fraud has not. The W3C Web Security Context Working Group, as part of
the Security Activity, was chartered to recommend user interfaces that
help users make trust decisions on the Web. The updated Note explains
the group's technical aims, complementing the WG charter. It explains
what the group aims to achieve, what technologies may be used, and how
proposals will be evaluated. This elaboration is limited to the group's
technical work and does not cover additional activities the group
intends to engage in, such as ongoing outreach and education. The work
outlined in the document is expected to take existing standards and
best practices into account; where relevant, such existing work will
be leveraged. (1) Security information within the Working Group's scope
will be catalogued, along with corresponding presentations and user
interpretations reported in user studies. (2) Members will analyze
common use cases to determine what security information the user needs
to safely accomplish their current task and recommend security
information that should, or should not, be presented in each case. (3)
The WG will recommend a set of terms, indicators and metaphors for
consistent presentation of security information to users, across all
web user agents. For each of these items, the Working Group will
describe the intended user interpretation, as well as safe actions
the user may respond with in common use cases. (4) Group members will
recommend presentation techniques that integrate the consumption of
security information by the user into the normal browsing workflow.
Presenting security information in a way that is typically ignored by
the user is of little value. (5) The Working Group will recommend
presentation techniques that mitigate deceptive imitation, or hiding,
of the user agent's presentation of security information.
Subscribe to:
Posts (Atom)