The STAR eXchange

Standards are one of those things where they seem to take years to release.   Most organizations tend to release every couple of years and then only a few of the standards may have had new information.   However because of the time lag involved, many users tend to extend the standard to meet their immediate needs.    While STAR releases once a year to the public, STAR members can get immediate updates, evening nightly depending on their needs.   Other standards organizations like OAGIs are starting to do releases twice a year to meed their communities needs.   This is something that STAR may need to look into in the coming years.

The 2010 release includes changes from STAR members that cover additional requirements for Marine, Heavy Duty Truck, and Automotive.    In addition, the STAR Web Services Transport package now includes to levels of compliance.  STAR Level 1 and STAR Level 2.   The goal of the compliance rules are to promote interoperability of the transport.   The prior versions allowed too many items open to interpretation, and created a wide variety of one-off-implementations.  Through the hard work of several member companies, the new STAR transport was created to help alleviate this problem, and promote a truly interoperable transport.

The new specifications become effective July 4, 2010.

STAR will be hosting it’s upcoming Winter/Spring General Session in nice and warm Orlando Florida.   As I write this entry we just were slammed with a nice winter storm which pretty much shut the east coast down.   So those heading to the NADA convention will enjoy a much needed reprieve from winter’s grasp.    As they are doing so, and since spring is right around the corner here is some food for thought.

Where should STAR as an organization go for the next several years?   Some may think we have done all that we can and there is nothing left to do.  However, the only thing that is constant in the universe is change.   Some will argue that the speed of light is constant, but that is a nit pick.   While many of the data standards are fairly mature, there are still areas in the Dealership’s business process we do not address, or have not addressed well.

One area that is growing and needs some help in standardization is the growing need for add-on provider integration with the main dealership system.  In some ways there has been resistance to providing a common approach to allowing these add on providers to connect.  Valid concerns about network bandwidth, and security have been used as reasons to limit availability.   Network bandwidth increases over the years, and with recent changes to the STAR Web Services 4.0 specification the security aspect should be addressed.

The OEM and Dealership Management System providers can leaverage the same STAR Web Service specification that they use for communication with each other to allow third party providers to connect to their system.   By leveraging this they are making it easier for more providers that they certify for connection, to be used by the dealership.   A third party provider may have more than one dealership management system to connect with, and by leveraging a common industry standard transport, it can make it easier for all involved.

Prior versions of the STAR Web Service specification left too much open for interpretation.  The new version due in May for general use, address this by specifying a minimum level of interoperability that all implementations must support.   It also updates to the latest Web Service specifications supported by implementation frameworks.     The security aspect leverages industry standards like WS-Security and Digital Certificate Authentication, giving the service provider that needed level of authentication to know who is accessing the system and when.

Service providers can and should be allowed to provide certification into their system, but the starting point for the transport and gate way should be a common industry standard like STAR’s Web Service specification.   In the long run, it is about keeping the dealers happy, and giving them secure access to their data to work with the applications they choose to run their business.   After all if the Dealer is happy, everybody is happy.

If you are going to the STAR General Session and have other ideas for discussion, please feel free to bring those up during the General Topics discussion section in the afternoon on February 11.  Oh and make sure you stop by the STAR booth to say High and show your support for the organization.

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.

Traditionally the STAR Architecture Workgroup has been focused on the delivery and maintenance of the STAR Transport packages:

• STAR Web Services – specifying the Generic and BOD Specific WSDLs.
• ebMS – covers the STAR specific profiles for ebMS 2.0 (ebXML).
• Transport Package – covers the overall direction and guidelines regardless of the transport being used.
• STAR Web Services Quickstart Guide – samples and available tooling that can be used to implement the STAR web services guide.

Over the last several years, most of the work has been concentrated on the Web Services portion. In the past the name of the group was the Transport Workgroup, but that was changed in recent years. However, the overall direction didn’t change with it.

I’m now managing the Architecture Workgroup and Jason Loeffler from Karmak is the workgroup lead. Together we are trying to broaden the horizon. We want to make it more than just working on specifications. Architecture around standards covers more than just the transport layer. It covers design and implementation of the standards. Security. Integration of various tools and technologies.

We want the group to evolve into an information resource for both STAR members as well as the general community. So I’m asking for some community input. What do you want to see from the workgroup. What is missing from an architecture standpoint that STAR members should be trying to address? Collaboration is what helps drive standards forward, now is the time to weigh in on the direction that the Architecture Workgroup at STAR should take. Please leave a comment here with your ideas and suggestions.