This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation http://www.microsoft.com
- WS-I Publishes Basic Security Profile Version 1.1 as Final Material
- CMIS API Library for Python: Real World ECM Tools with Python and cmislib
- Sieve Email Filtering: Delivery Status Notifications/Deliver-By Extensions
- Front Range OWASP Conference 2010 (FROC 2010) Call for Presentations
- OGC Seeks Comments on SWE Common Service Model Interface Standard
- Red Hat Updates JBoss Dev Tools, SOA Platform
- Java Web Services: WS-Security with the Apache CXF Web Services Stack
- Business Glossary: Define a Common Business Language Among Modeling Tools
WS-I Publishes Basic Security Profile Version 1.1 as Final Material
Michael McIntosh, Martin Gudgin, K. Scott Morrison, Abbie Barbir (eds)WS-I TR
"The Web Services Interoperability Organization (WS-I) has announced publication of the WS-I Basic Security Profile (BSP) 1.1 as final material for public access. BSP 1.1 is available at no charge from the WS-I Web site. BSP 1.1 constrains the use of several common security tokens based on the OASIS Web Services Security (WS-Security) 1.1 and its token profiles. Security tokens profiled include Kerberos, X.509, SAML and Username token.
WS-I is an open industry organization chartered to establish and document Best Practices for Web Services interoperability. The WS-I Basic Security Profile is an essential guide for ensuring secure, interoperable Web services, based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications that promote interoperability. BSP 1.1 integrates OASIS Web Services Security (WS-Security) 1.1 key encryption and signature features that can improve interoperability of practical secure technologies used in current Web services applications.
Specifically, BSP 1.1 targets transport and SOAP message security, and Basic Profile-specific security considerations of Web Services. BSP 1.1 focuses on Web Services Message Security and HTTP over Transport Level Security (TLS). Building on BSP 1.0, BSP 1.1 is based on the key security usage scenarios and requirements identified in WS-I's 'Security Challenges' document...
Concluding a six-month testing effort, six WS-I member companies—Intel, IBM, Layer 7, Microsoft, Oracle and SAP AG—successfully interoperated using BSP 1.1 and contributed to profile enhancements based on their results. The scenarios and test tools are publicly available... The WS-I Board approved BSP 1.1 after receiving confirmation that the members' interoperability tests were successfully concluded. Following the Board's positive ballot, the document was submitted to WS-I's membership, who voted to approve publication of BSP 1.1. Among the WS-I member companies whose representatives participated in developing BSP 1.1 were BMC Software, Inc.; Hitachi, Ltd.; HP; IBM; Layer 7 Technologies; Microsoft Corporation; Nokia; Oracle; and SAP..."
CMIS API Library for Python: Real World ECM Tools with Python and cmislib
Jay Brown, IBM developerWorks
This article is Part 2 of a series on CMIS and Python, demonstrating how to build an xcopy-like data population and migration tool using the Python cmislib library. The tool not only xcopies local file systems to any CMIS repository but is also aware of JPG Exif data and preserves it during the copy if possible.
The article has three main sections: (1) Python and CMIS—An introduction to and discussion of why Python is a natural fit when you write CMIS-related tools; (2) Code walkthrough - review of the code with an explanation of how it all fits together so you can easily extend it for other types of metadata and sources; (3) Running the tool—explore runtime aspects of using the tool as well as setting up the dependencies. If you are just interested in downloading the tool and using it without an explanation of why it came to be or how it works, then jump to the section Running the tool.
When you build a CMIS client or tool, remember it is virtually impossible to build a truly compatible CMIS client if you only test with one repository. If you test with only one repository, you built a client for just that one repository, not a true CMIS client. Please always test with at least two compliant repositories to make sure that you are OASIS CMIS specification compliant. In keeping with these values, I tested this code with both IBM servers and the Alfresco public server. The easy part for me is that Jeff Potts has already done the work of making sure cmislib is compatible with the specification as opposed to just one repository, so after getting the prototype to work with the IBM CMIS server, my first attempt with the Alfresco server just worked...
This example shows how easy it is to script complex operations against ECM repositories in a way that is compatible with all repositories that are CMIS compliant. Hopefully, this will inspire you to look into CMIS if you have not done so already, or if you have to consider using cmislib and Python next time you have some scriptable work to do on your CMIS ECM system..."
See also: CMIS references
Sieve Email Filtering: Delivery Status Notifications/Deliver-By Extensions
Ned Freed (ed), IETF Internet Draft
The Internet Engineering Steering Group (IESG) has received a request to consider the specification Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions as an IETF Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action; please send substantive comments to the IETF mailing lists by 2010-04-08.
Sieve (RFC 5228 - Sieve: An Email Filtering Language) defines a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.
The base sieve specification defines the envelope extension and test to access information in the message envelope. Only information available in regular SMTP is provided; additional information added to the SMTP envelope by SMTP extensions cannot be accessed. This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language.
The "envelope-dsn" extension extends the envelope test to allow access to the additional envelope fields defined by the SMTP extension for delivery status notification specified in RFC 3461. The "envelope-deliverby" extension extends the envelope test to allow access to the additional envelope fields defined by the deliver-by SMTP extension defined in RFC 2852. The base sieve specification also defines the redirect action which sends the message to a different address. Redirect only allows specification of the new recipient address. The "redirect-dsn" extension extends redirect to allow specification of some fields defined by the delivery status notification SMTP extension. "redirect-deliverby" in turn provides the ability to set a time limit for delivery..."
Front Range OWASP Conference 2010 (FROC 2010) Call for Presentations
Staff, Open Web Application Security Project (OWASP) Announcement
FROC 2010 Call for Participation: "On Wednesday, June 02, 2010, OWASP will hold its third annual 'Front Range OWASP Conference (FROC)' in Denver, Colorado, USA. The deadline for submission is March 31, 2010.
The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas.
For FROC 2010, the conference organizers are collaborating with colleagues at the Cloud Security Alliance, and will feature an AppSec track as well as a CloudSec/VirtSec track. They are seeking presentations on any of the following topics: (1) Application Security: e.g., Web Services and Application Security; Common Application related Threats and Risks; Business Risks with Application Security; Vulnerability Research in Application Security; Web Application Penetration Testing; Secure Coding Practices; Browser Security, and (2) Cloud Security: e.g., Identity Management in the Cloud; Incident response in the Cloud; New cloud-based malicious threats; Virtualization Security; Transparency and Auditing in the Cloud..."
See also: OWASP references
OGC Seeks Comments on SWE Common Service Model Interface Standard
Staff, Open Geospatial Consortium Announcement
OGC has invited "public comment on the candidate OGC Sensor Web Enablement (SWE) Common Service Model Interface Standard Version 2.0. The SWE Service Model provides a common set of data types and defines a common set of interface mechanisms that can be used with other SWE interface standards. The public comment period closes on April 25, 2010.
There are two 'SWE Common' standards: The OGC SWE Common Service Model Interface Standard is applicable to all services that provide or require information from or about sensors. It is designed for uses cases in which sensors need to be accessed and managed through service interfaces.
A related standard, the OGC SWE Common Encoding Standard, provides a standard model (and XML implementation of the model) for the representation, nature, structure and encoding of sensor related data. It is used for describing static data (files) as well as dynamically generated datasets (on-the-fly processing), real-time streaming data, and process and web service inputs and outputs. Both of the SWE Common standards are designed to be used with other existing OGC Sensor Web Enablement standards such as OGC Sensor Model Language (SensorML) Encoding Standard, Sensor Observation Service (SOS) Interface Standard and Sensor Planning Service (SPS) Interface Standard.
The OpenGIS Sensor Model Language Encoding Standard (SensorML) specifies models and XML encoding that provide a framework within which the geometric, dynamic, and observational characteristics of sensors and sensor systems can be defined. There are many different sensor types, from simple visual thermometers to complex electron microscopes and earth observing satellites. These can all be supported through the definition of atomic process models and process chains. Within SensorML, all processes and components are encoded as application schema of the Feature model in the XML-based Geographic Markup Language (GML) Version 3.1.1..."
See also: SensorML specification references
Red Hat Updates JBoss Dev Tools, SOA Platform
John K. Waters, Application Development Trends
"Red Hat showed off the latest incarnation of its JBoss Developer Studio IDE at the annual EclipseCon developer conference in Santa Clara, as well as a new version of its JBoss Enterprise SOA Platform, and it unveiled the latest version of its JBoss Enterprise Web Platform.
JBoss Developer Studio 3.0 is built on the latest Eclipse platform release (3.5),according to Ashesh Badani, senior director of Red Hat's Middleware Products group, and expands support within that IDE for the breadth of the company's product line, including its enterprise application platform and its SOA, portal and data-services platforms...
The company also launched a major update of its SOA software. JBoss Enterprise SOA Platform 5.0 adds a number of features to the company's evolving middleware product, which Badani said supports the integration of an array of applications, services, transactions and business processes in one simple architecture.
The 5.0 release comes with new administration consoles, a new tool for transforming XML docs (based on XSLT) and an upgraded UDDI registry. Look also for version 5 of JBoss Rules, which works with JBoss Enterprise BRMS, and better integration with such cloud services as Amazon's Elastic Compute Cloud (EC2), as well as in-house cloud environments..."
See also: the announcement
Java Web Services: WS-Security with the Apache CXF Web Services Stack
Dennis Sosnoski, IBM developerWorks
The Apache CXF Web services stack supports WS-Security, including using WS-SecurityPolicy to configure the security handling. CXF is flexible in how you configure the deployment parameters used at run time to implement the security handling, supporting both static and dynamic configuration options for the client side...
WS-SecurityPolicy security configurations detail the security processing needed for messages being exchanged between a client and service. In most cases, the Web services stack also requires some additional information to apply the security to a message exchange. For instance, a WS-SecurityPolicy may require the client to sign request messages sent to the server, providing nonrepudiation for the service. In this case, the client Web services stack needs some way of identifying the specific private key to be used for signing when sending a message to the service.
Both Axis2 and Metro use custom WS-SecurityPolicy extensions to provide security parameters of this type. Since the WS-SecurityPolicy is normally embedded in a WSDL service description, you generally need to modify the WSDL document to add these details—though Axis2 allows you to set a policy directly in client code, as an alternative. This need to modify the WSDL document is both cumbersome and somewhat contrary to WSDL's intent, which is to serve as a service description.
CXF takes a different approach—or perhaps that should be different approaches—since there are multiple ways to configure CXF with the added parameters needed when applying a WS-SecurityPolicy configuration to messages. On the client side, you can do this either directly in client code or by using a Spring XML configuration file. On the server side, you always need to use an XML configuration file, though you still can choose among different types of files. You'll see how these alternatives for both client and server work in this article's examples..."
See also: the OASIS WS-Security specifications
Business Glossary: Define a Common Business Language Among Modeling Tools
Brian Byrne and Jennifer Ramirez, IBM developerWorks
In a large organization with complex analysis, modeling, and development initiatives spread across multiple projects, standardizing business semantics is key. Without a way to standardize the meanings and definitions of business concepts, each analysis, modeling, or development thread will naturally establish its own semantics. These disparate semantics can compound the already fragmented understanding of the relationship between IT assets and the business concepts they support.
For example, the business side of the house might clearly define the term Customer Tax Status. This enables each IT initiative that supports Customer Tax Status to use the defined meaning, which drives consistency of term name, definition, and related semantics across all the IT initiatives. By contrast, in the absence of such a structure, each IT initiative might naturally come to its own conclusion as to what Customer Tax Status means and how it should be defined. This can result in multiple structures, such as Customer Tax Code, Tax Status, Customer Code, all of which loosely imply the same semantics but differ in name and definition...
InfoSphere Business Glossary provides a means to specify business concepts and to manage the relationship among those concepts and the IT structures that support them. However, this content is only useful if it is easy to access. For example, without immediate and efficient access to glossary content, model users, including service analysts, component designers, and logical data modelers, might ignore the glossary and define their own terms. The glossary content should be available within the modeling tools, making the content impossible for the modeler to ignore. Still, there might be complications with model interchange and synchronization as relationships between model structures and glossary terms must be retained as models flow from tool to tool...
These new functions within the modeling platform fundamentally change the capability of an enterprise to define and control business semantics across various modeling domains. These techniques, properly applied, can greatly reduce the variation in business definitions across modeling efforts, across projects, and across line-of-business boundaries..."
XML Daily Newslink and Cover Pages sponsored by:
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/