The STAR eXchange

STAR is pleased to announce that the Feb 11th 2010 STAR General Session Keynote Speaker will be Chuck Allen, Integration Architect at SilkRoad Technologies, Inc and founder of HR-XML Consortium.

Chuck Scahill, current STAR Development Chair and VP of Business Development from Karmak, Inc stated, “I think it will be an excellent presentation.  It is both timely and consistent with our experiences, particularly this past year.”

———————————————————-

Keynote Presentation:  “Standards 2010: Prospects and Challenges for Standards Development in the Next Decade”

Abstract:

As standards organizations enter the 2010s, they face very different circumstances than a decade a ago. At the dawn of the “2000s,” analysts warned us that a key risk was the creation of a “tower of babel” as industry standards groups proliferated nearly as fast as dot.com start-ups. By the end of the decade, some groups had achieved measurable interoperability gains, but at the cost of years of upfront committee time followed by implementation and revision cycles also spanning years. Today, standards organizations that have managed to survive the decade’s two boom and bust cyles face vastly different funding circumstances and participation levels. At the same time, standards organizations are challenged by an accelerating pace of technology and marketplace change.

In this session, Chuck Allen, founder of the HR-XML Consortium and an adviser to other standards initiatives, will offer a survey of the state of standards development, including key challenges and new approaches. Among topics to be reviewed are:

Development methodologies. The committee processes driving most standards development organizations (SDOs) have remained largely unchanged over the past decade (STAR standards being an important exception). Most SDOs take months or years to spec out a standard with meaningful development against the specification beginning only after publication. While standards organizations have been slow to adapt their methodologies, in the same period, many enterprises have significantly transformed their internal development processes through the adoption of a range of agile methodologies. While there is growing recognition of the need to update standards development process, the prospect of applying agile methodologies to standards development tends to be met with equal degrees of interest and trepidation.

Intellectual property. Most standards organizations manage intellectual property by requiring participants to grant royalty-free licenses to the SDO and to anyone implementing the standard. For companies with large patent portfolios, this can impose a burden of expensive patent inventory searches and monitoring. Since each SDO has slightly different licensing terms, current licensing practices also prove challenging for an implementer wanting to apply multiple standards as well as for standards development organizations trying to converge standards. Patent non-assertion policies and efforts to simplify and standardize licenses hold some promise is reigning in the complexity associated with managing IP.

Funding models. Standards cost money to develop and maintain. However, traditional funding approaches, such as pay-to-play” and “pay-for-the-standard” don’t always keep up with funding needs and can work as disincentives for adoption and engagement.  There isn’t an easy answer to the question of financial sustainability for many SDOs, particularly in these tight economic times. The answer likely lies in a combination of approaches, including doing more with less, the design of attractive sponsorships, meeting and programming fees, and taking advantage of grant opportunities.

About the Speaker:

Chuck Allen, Integration Architect at SilkRoad technologies, Inc., was the founder and Executive Director of the HR-XML Consortium, Inc. Prior to founding HR-XML in Dec. 1999, Allen worked in a variety of new product development roles for major business publishers, including Thomson (now Thomson-Reuters) and the Bureau of National Affairs. Allen has a B.A. from the University of Virginia.

———————————————————-

Event Date: Thurs., Feb 11th 2010

Host Details: STAR Organization

Meeting Registration Information: The STAR February 2010 General Session is available only to STAR Members and approved Guests. If you are a non-member and wish to attend, please email Ghezal Khalili, STAR Executive Coordinator at gkhalili@starstandard.org .  If you are a STAR Member, please register at this link: STAR Member Meeting Registration Link

Interoperability when dealing with standards can be a frustrating thing, and it should not be.   The goal of a standard is to reduce the overall work that has to be done, eliminate the one offs, and allow users to exchange their data between tools.   However, the failure of many UML based tools to reliably read and exchange even the simplest of models is a lesson that we should learn from, not try to emulate.

It's been interesting following the Model Interchange Workgroup's testing of various UML 2.1 compliant tools.  The results have not been surprising.  Many tools have interoperability problems, from failing to render according to the spec, to not even being able to read a compliant XMI file.    To many large vendors there is little incentive to have interoperability as they feel it gives them a edge.  However, these vendors are just opening the door to others that can provide interoperability.   Having a unique implementation or a one off of a standard is not an advantage, it's a hindrance to your customers.

It's important for Standards to be Standard.  While it may be convenient for you to make a one off change, as soon as you role that change outside of your internal application, you provide a pain point for all of your trading partners.    In order for Standards to be Standard, members and the community need to participate.  It means contributing your requirements back to the organization, or working with the organization to find where your requirements are captured.  In many cases your use case is not unique as you think.

In order to help enable these changes, standard organizations need to respond quicker to the communities needs.  They need to adapt and make changes available sooner.   STAR currently publishes a yearly version available to the community.  However members can get updated versions in a little as a day after the request is received.   It's one of the benefits of being a member.  However, are we responding quick enough by a yearly release?  Does the community need a bi-annual release?

Organizations should also provide a testing tools for the community.  STAR provides the BOD Validation website which adopters can use to check that their STAR BOD validates against the official STAR schemas.  If you receive something from a trading partner that doesn't validate, it isn't STAR compliant.  The community needs to step up as well and make sure that your trading partners are using validly formatted BODs.  There is only so much enforcement that an organization can do.

The community needs to ask and demand for interoperability.

In general though, having non-interoperable changes may not necessarily affect your implementation, but it does greatly affect your trading partners and their trading partners as well.   Do not repeat the mistakes of the UML Tool vendors.  Let's learn from them.

One of the most difficult things from a Standard organization aspect is getting people to request changes to a standard. STAR has been pretty good about this over the years, and in many ways I contribute it to the adoption of Agile development and management techniques. In general, people do not contribute or request modifications because they feel it takes too long to get their requirements met. STAR members can get a turn around in as little as a day, sometimes even within an hour. How is this achieved?

One of the technical development techniques that has come out of Agile development is the concept of Continuous Integration. Basically, everybody that is developing on a standard and creating its artifacts are integrating continuously. As code or changes to models are checked into source control, builds are started to generate and check that all artifacts are being produced as expected. Below is a snapshot of an early setup of the STAR Hudson continuous integration server:

STAR actually has about 6500 unit tests that run to check the quality of the XML schemas we produce. As the developers make changes and check in their changes, the Hudson build server monitors for new changes and then runs a build. If a build breaks, notifications are sent out to those that broke the build. This way we catch integration issues early instead of late when they are more difficult to debug and fix. The Hudson instance is made available to STAR members so that they have the ability to pull down changes at their convenience.

Providing your members and community with development snapshots helps improve the overall quality of the standard being produced, but also helps to eliminate one of the road blocks of getting community members to contribute or request changes. Shortening the overall development cycle is something that standard organizations need to do, as adopters can not wait years or even months to use what is being produced. Business moves ever faster, and we need to adapt or get out of the way.

One of the constant themes I hear about users in STAR is the size of the XML files. That there is a problem parsing them, processing them, and in general trying to cram them into legacy data stores and using legacy technologies. One of the unfortunate side affects of data binding of XML is that everybody tries to use it for everything. The first and typically last tool a programmer will go for now a-days is a data binding framework. Unfortunately, this is not necessarily the best choice. In many cases, if you dig around in the xml tool bag you can find other choices.

Kurt Cagle has written an excellent rebuttal on the FUD (Fear, Uncertainty, and Doubt) that XML is not right for BIG Data. When we are talking BIG we are talking 50MB or larger. In fact, he rightly says:

Frankly, if you ARE storing your XMLdata in a relational database repository, then you’re throwing valuable money away, because you’re adding a hideous performance penalty on every transaction.

Kurt Cagle, XMLToday.com

He goes on to talk about the role of XML Databases and how in many ways they are out performing their relational database counterparts. STAR has several very large BODs that may need to be processed and queried. PartsMaster, LaborOperations, PartsPriceList, and RepairOrder are a few that come to mind. Processing these with data binding is definitely not the way to go. Supplementing an existing Relational Database with an XML Database can be very beneficial. It also allows you to work with XML natively without necessarily having to do a data transformation to get at the relevent information. Investigate your existing Relational Database as many have XML Data Storage abilities. XML can be a good fit for Big Data, it just takes using the right tool for the right job, and not trying to use the same tool for every job.

At STAR we like to look at what other Standards organizations and non-profits are doing to help their membership and community. One of the ones we keep an eye on is ACORD, they share many of the same values and opinions on standards that STAR does.

ACORD held a recent meeting in which they outlined their goals for the year:

One of the benefits of STAR membership is the ability communicate with the people contributing time, and resources to it’s development. In the last several months, STAR has been upgrading the tools that it provides to it’s membership to make this collaboration easier and more frequent. We’ve recently upgraded the look for the forum itself:

The forums are a great opportunity for STAR members to collaborate on the development of the standards and participate in workgroups, when they have the time. Not everybody can make the scheduled workgroup calls, so we encourage members to participate in other methods. The newest workgroup that has been introduced is the STAR Marketing Workgroup. The marketing workgroup will be working at ways in which STAR and Members can help promote the usage of the standard.

So even if you are not into the technical development of the standards, there is a way for you to participate and give back. If you are a STAR member consider joining the Marketing Workgroup, and if you are not a member, please consider becoming one to help us promote the standard.

With yesterday’s approval and release of the STAR Transport specification documents, STAR has listened to members and the community to help create a more interoperable specification. The STAR Web Service specification received in some ways a much needed refreshing.

The specification has not changed much in the last 4 years. However since the time that it was in production many things have changed within the web services world.

• STAR has both members and non-member implementation experience to draw upon. This helps give us real world interoperability experience to gauge how well the specification is meeting its goals.
• Many of the standards that were recommended in the prior version were draft standards. These have since moved out of draft status and into official recommendations.
• Tooling support has been greatly enhanced and evolved. Many of the older specifications are no longer supported by current tooling.

Interoperability:

One area that has been hard to maintain with out a strict profile is the goal of deploying the web service once, and having it work with out change amongst a variety of trading partners. The reason for this is that the old specification allowed a lot of wiggle room in its interpretation. To help with interoperability the latest specification to has addressed the following:

• Documented a set of REQUIRED rules that STAR Web Services must implement. The current specification addresses the STAR Level 1 compliance rules. Work is under way for more advanced features called STAR Level 2.
• Updated the specifications to the most current approved standards. All STAR Level 1 requirements are supported by the existing tooling and frameworks.
• REQUIRED compliance to the WS-I Basic Profile 1.1.
• NOTE: That STAR WS 4.0 is not backwards compatible with STAR WS 3.0 implementations. Namespaces for many of the required specifications have changed as well as the STAR Transport namespace.

Interoperability Testing:

STAR also joined the WSTF group this last year. WSTF provides a forum where tooling vendors and implementers can work together on specific web service implementations. STAR will be proposing some use case scenarios to the WSTF to have web service endpoints setup to test both the STAR Generic Transport as well as the BOD Specific transports. By publishing these endpoints, STAR Members and Community adopters can test their implementations for interoperability against various implementations. It is the hope that by providing these end points an unofficial verification can be made that an implementation should be interoperable with another.

STAR Level 2:

The Architecture Workgroup is currently addressing some more advance use case scenarios and will be documenting these under STAR Level 2 requirements. An important note is that a STAR Level 2 implementation must be able to fall back and inter-operate with a STAR Level 1 implementation. STAR Level 2 will be addressing items like:

• WS-ReliableMessaging
• WS-Addressing
• WS-Policy
• Attachments with MTOM
• WS-Security with Digital Certificates for Authentication.
• Leveraging the latest approved specifications from WS-I on WS-Security and Reliable and Secure profiles.

What about ebXML?

This is a topic on the radar for STAR over the next year. ebMS 3.0 is now released, and STAR needs some feedback on whether current implementers are going to migrate to ebMS 3.0 or if they plan to stay on ebMS 2.0. ebMS is a victim of its own success in some ways. This is due in many ways to its stability and interoperability of the specification. Migration may be slow to ebMS 3.0 due to the fact that ebMS 2.0 just seems to work.

Please check out the latest specifications and feel free to comment or send us feedback on the latest specifications. We can only make sure we are addressing community needs if we hear back from the community.

Over the years, I’ve been introduced to a variety of XML Schema design patterns. We’ve gone the route of defining everything in complex types as in STAR 4

STAR 4:

    <xsd:complexType name="PartyBase">        <xsd:sequence>            <xsd:element name="PartyId" type="PartyId" minOccurs="0">                <xsd:annotation>                    <xsd:documentation source="http://www.starstandard.org">Party Identification Number</xsd:documentation>                </xsd:annotation>            </xsd:element>        </xsd:sequence>    </xsd:complexType>

To going to all Global Elements in STAR 5:

   <xsd:complexType name="MessageType">        <xsd:sequence>            <xsd:element ref="ID" minOccurs="0" maxOccurs="1"/>            <xsd:element ref="ReasonCode" minOccurs="0" maxOccurs="1"/>        </xsd:sequence>    </xsd:complexType>

Both of these patterns can be a problem though for various tooling to handle. The reason is that the tools tend to generate extra content models to handle the schemas. In particular data binding frameworks will tend to generate thousands of classes. Which in turn can be problematic to deploy and maintain.

STAR is currently looking at implementing a Hybrid approach for STAR 5. The hybrid approach will maintain backwards compatibility with the existing XML Schemas from an XML Validation standpoint, but will hopefully help reduce the number of classes that are generated.

The XML NDR by UNCEFACT that STAR follows describes the hybrid approach as follows:

    <xsd:complextype name="ApplicantType">        <xsd:sequence>            <xsd:element name="PrimaryDriverIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1">            <xsd:element ref="ResidencePeriod" minoccurs="0" maxoccurs="1">            <xsd:element ref="ApplicantParty" minoccurs="1" maxoccurs="1">            <xsd:element ref="ApplicantDemographics" minoccurs="0" maxoccurs="1">....            <xsd:element ref="ReferencePerson" minoccurs="0" maxoccurs="unbounded">            <xsd:element name="GSTRegistrantIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1"/>       </xsd:sequence>   </xsd:complextype>

Basically anything that is a Component is still treated as a global reference. Anything that is a Field is locally defined within the component that it appears. This should help reduce the number of classes that are generated by various tooling as the local elements will be mapped more directly to fields or attributes in the appropriate language.

The benefits of the design change will vary depending on tooling support. It is the hope though that the design change will help ease some of the integration burden. This is planned to be available to STAR members during the upcoming Draft and Milestone releases for STAR 5.3.2. Other community members will see the proposed design changes in STAR 5.3.4 in March 2010.

David E. Jones, VP of Open for Business at the Apache Foundation has a good blog entry called, Open Source Community Collaboration Best Practices. He has this to say about Collaboration.

If you want other people to collaborate with you, first you need to collaborate with them. If you are hoping for some benefit of the collaboration you first need to set the stage for the collaboration and invite others to collaborate by starting first and giving what you have, then invite others to get involved. The important thing to keep in mind is that collaboration implies a two-way street and if you try to make it one way by not trying to collaborate with others, but still expecting them to collaborate with you, then you will most likely be disappointed by either no collaboration at all, or a good-will attempt by someone else to collaborate with you that will fail because no stage was set for the collaboration and they will likely help in a way you don’t need…..

Substitute open standards for open source and the blog applies just as much to open standards development and collaboration. Read the rest of the entry at his blog.

An interesting quote from Bob Sutor’s most recent blog entry.

….understanding of the value of [sic] and a preference for truly open standards must be both part of the policy of and inherent in the common practices of an IT organization. Technologists and IT administrators must live, breathe, think and reason in terms of open standards. They should feel repelled by dictated or faux-open specifications that were developed without balanced community involvement and innovation.

Read more about his views on Open Standards at his blog.