Archive for July, 2009
One of the nice things in web site content and design is that you can pretty easily update the look of the site with out having to redo all of your content. The STAR website has undergone some more visual design tweaking.
- Make it easier for those in the Media to get to the information they need.
- Make it easier for the user community to get to the most requested information quicker.
- Provide an easier method to retrieve printable pages.
- Provide a more pleasant browser experience.
Many of the changes were implemented by leveraging the Top Content reports from Google Analytics. The changes are directly reflected on how users were using the site and which parts they were visiting most often.
Over the years, there have been many variations of the STAR web site. Each hopefully improving on the useability and accessibility to the main content that the user community needs. For a walk down memory lane, the Internet Archive Wayback Machine, has the archived versions of the STAR website. The earliest it goes back is 2001. Take a walk down memory lane, and provide us with feedback on the new look.
Posted in STAR, community, design, open standards | No Comments »
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.
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.
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:
- 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.
Posted in STAR, architecture workgroup, interoperability, standards, transport, web services | No Comments »
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
<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.
Posted in STAR, community, design, standards | No Comments »