To leverage legacy systems so they can be "mobilized," consider adopting an approach that aligns canonical data models in service oriented architecture (SOA) with your message models. Such a data model may be developed top-down based on business requirements or, alternately, through reverse engineering of existing data structures. This is the approach I've used most frequently.
So how to do this?
While it sometimes is difficult to create pure system-independent canonical models, aspiring to that in the context of SOA is a worthy goal. It helps to define data types (think of them as the "leaves" on the tress of your XSD, an XML schema or road map for the XML document). This structure could be similar to data types which are used in the RDBMS in your master data sources.
Next, find the differences -- map the supported data types in other systems and databases within your infrastructure. Typical conflict arises in types like "STRING" or "FLOAT". It pays to use more restricted form of this data type. If the databases contain something atypical -- for instance number of decimal places is lower than number which is required by your legal requirements (especially financial transactions) -- you can then disable that column to do critical transactions by creating a branch in data types. This can then be programmatically set during translations from system-specific data types in your Common Data Model, where you can use common static tables translating. The end result will be a set of data types compatible with your systems and also usable via in semantic standards over your ESB.
The next step is to define basic business objects representing entities within the semantic standard which will have structure, that will be understandable for you business and will be valid for consumers of your services. Of course, you will reuse data types from your data types set and business objects should be dependent on domain. For example, business objects for contract details in different domains if those domains require unique fields. Caveat: data types should be the same; look for archetypes in existing models such as Dublin core.
Finally, define the service interfaces. Are you utilizing a standardized form of message for request and response? Within this form you should use business objects, used whole prevent to fragmentation of interfaces, which could decrease the potential for reuse.
At Bluedog, we have found that canonical data model can provide a common format for the information content of the messages of the individual services, leading to a horizontal alignment of message formats across services.
Intellectual capitalism drives Bluedog. We believe an intellectual capitalist pursues freedom of choice -- and what counts is freedom in the marketplace, in the home, in one's thoughts.
Monday, January 13, 2014
Friday, January 10, 2014
Taking over the driver's seat - another study predicts uptake of autonomous vehicles
There are man benefits to the self-driving car, and these will drive acceptance once such vehicles clear regulatory hurdles.
Several traditional car makers are embarking on autonomous-vehicle projects, and are by the likes of Google and other major industry suppliers. IHS is only predicting self-driving cars to make up two-tenths of a percent of sales in 2025, with price premiums of $7,000 to $10,000. By 2035, 9.2-percent of new vehicles sold will be autonomous, as prices are driven down to a mere $3,000 more than a traditionally controlled vehicle.
Ford, for example, has initiated work on its own autonomous vehicle as well as a solar-powered hybrid plug-in outfitted with silicon panels right on the roof. The Ford C-MAX Solar Energi concept car gets an estimated EPA mileage rating of 100 mpg, and its rooftop array is capable of generating 300 watts. For the self-driving Fusion, Ford replaced the bulky LIDAR units on current autonomous vehicles are four smaller scanners. Linked together, the LIDAR units compose a 360-degree, three-dimensional view of the surroundings, processing the information and allowing the vehicle to accelerate, brake, and steer without driver intervention.
Several traditional car makers are embarking on autonomous-vehicle projects, and are by the likes of Google and other major industry suppliers. IHS is only predicting self-driving cars to make up two-tenths of a percent of sales in 2025, with price premiums of $7,000 to $10,000. By 2035, 9.2-percent of new vehicles sold will be autonomous, as prices are driven down to a mere $3,000 more than a traditionally controlled vehicle.
“There are several benefits from self-driving cars to society, drivers and pedestrians,” says Egil Juliussen, principal analyst for infotainment and autonomous driver assisted systems at IHS Automotive. Juliussen co-authored the study with IHS Automotive senior ADAS analyst Jeremy Carlson.
“Accident rates will plunge to near zero for SDCs, although other cars will crash into SDCs, but as the market share of SDCs on the highway grows, overall accident rates will decline steadily,” Juliussen says. “Traffic congestion and air pollution per car should also decline because SDCs can be programmed to be more efficient in their driving patterns.”
Ford, for example, has initiated work on its own autonomous vehicle as well as a solar-powered hybrid plug-in outfitted with silicon panels right on the roof. The Ford C-MAX Solar Energi concept car gets an estimated EPA mileage rating of 100 mpg, and its rooftop array is capable of generating 300 watts. For the self-driving Fusion, Ford replaced the bulky LIDAR units on current autonomous vehicles are four smaller scanners. Linked together, the LIDAR units compose a 360-degree, three-dimensional view of the surroundings, processing the information and allowing the vehicle to accelerate, brake, and steer without driver intervention.
Tuesday, January 7, 2014
Exoskeleton-wearing teen - paralyzed - to kick off the World Cup
When the World Cup kicks off this summer in Brazil, a paralyzed teen, using a mind-controlled exoskeleton, will make the ceremonial first kick.
Sponsored by the Walk Again Project, this event will showcase how technology improves lives. The Walk Again Project is a nonprofit, international collaboration among the Duke University Center for Neuroengineering, the Technical University of Munich, the Swiss Federal Institute of Technology in Lausanne, the Edmond and Lily Safra International Institute of Neuroscience of Natal in Brazil, The University of California, Davis, The University of Kentucky, and Regis Kopper of The Duke immersive Virtual Environment.
The candidate will he will be picked from a pre-approved group of patients who have been taught how to operate the sophisticated exoskeleton.
Sponsored by the Walk Again Project, this event will showcase how technology improves lives. The Walk Again Project is a nonprofit, international collaboration among the Duke University Center for Neuroengineering, the Technical University of Munich, the Swiss Federal Institute of Technology in Lausanne, the Edmond and Lily Safra International Institute of Neuroscience of Natal in Brazil, The University of California, Davis, The University of Kentucky, and Regis Kopper of The Duke immersive Virtual Environment.
The candidate will he will be picked from a pre-approved group of patients who have been taught how to operate the sophisticated exoskeleton.
Monday, January 6, 2014
"You keep using that word. I do not think it means what you think it means"
In keeping with what a great swordsman once uttered, using that word wrong doesn't make your web service work better. The Application Programming Interface (API) in Service Oriented Architecture (SOA) is a new catch phrase, we hear. This so-called 'REST API' is almost always just an 'HTTP interface' given a fancy name to make it sound better, more so than the integration strategy many consultants are offering up. In an organization with an e-commerce or web development team, this "programmer" view makes SOA seem cool.
REST stands for Representational State Transfer, as proposed in a doctorate dissertation. This approach uses the four HTTP methods GET, POST, PUT and DELETE to execute different operations, compared to SOAP, which creates new arbitrary commands (verbs) like getAccounts() or applyDiscount(). Thus, a REST API is a set of operations that can be invoked by means of any the four verbs, using the actual URI as parameters for a web service operation. For example, we might have a method to query all case management accounts which can be called from /accounts/all/ to invoke a HTTP GET and the 'all' parameter. This tell the web service that to return all accounts, probably in an XML stream annotated for the particular client (with CSS, for example, for a browser).
Here at Bluedog, our apps have always been built with the web tier against the same set of "APIs" as the mobile tier. The advantage of a Java/WebObjects framework is "out-of-the-box" support for a variety of clients. The Ajax framework in Project Wonder provides many of the features that Rails users have come to expect, but written in a style that fits well with "The WebObjects Way" of doing things. An attempt is made to avoid writing javascript whenever feasible, as well as providing as much support for component actions as possible.
The majority of Ajax framework is written without dependencies on ERExtensions (the core framework in Project Wonder). This means that for most Ajax capabilities (the JavaScript/CSS components that give sizzle to the browser), we can use a framework without making a Web Service or Application extend any classes. Advanced capabilities can be designed using supporting classes that are available in the ERExtensions framework or by extending the open source classes such as ERXSession in our foundation frameworks.
The rise of mobile has harkened back the older client/server model which emphasized rich client interfaces, first made popular with Swing and other attempts at native Java clients. With our "API-first" development model, the Java/WebObjects tier is the interface to the device -- or client. When you put a desktop browser client, mobile native app (Objective C for iPhone or iPad) or a desktop app in front of the app server you make a mobile-enabled stack is simple. And all is right, in the world of SOA.
REST stands for Representational State Transfer, as proposed in a doctorate dissertation. This approach uses the four HTTP methods GET, POST, PUT and DELETE to execute different operations, compared to SOAP, which creates new arbitrary commands (verbs) like getAccounts() or applyDiscount(). Thus, a REST API is a set of operations that can be invoked by means of any the four verbs, using the actual URI as parameters for a web service operation. For example, we might have a method to query all case management accounts which can be called from /accounts/all/ to invoke a HTTP GET and the 'all' parameter. This tell the web service that to return all accounts, probably in an XML stream annotated for the particular client (with CSS, for example, for a browser).
Here at Bluedog, our apps have always been built with the web tier against the same set of "APIs" as the mobile tier. The advantage of a Java/WebObjects framework is "out-of-the-box" support for a variety of clients. The Ajax framework in Project Wonder provides many of the features that Rails users have come to expect, but written in a style that fits well with "The WebObjects Way" of doing things. An attempt is made to avoid writing javascript whenever feasible, as well as providing as much support for component actions as possible.
The majority of Ajax framework is written without dependencies on ERExtensions (the core framework in Project Wonder). This means that for most Ajax capabilities (the JavaScript/CSS components that give sizzle to the browser), we can use a framework without making a Web Service or Application extend any classes. Advanced capabilities can be designed using supporting classes that are available in the ERExtensions framework or by extending the open source classes such as ERXSession in our foundation frameworks.
The rise of mobile has harkened back the older client/server model which emphasized rich client interfaces, first made popular with Swing and other attempts at native Java clients. With our "API-first" development model, the Java/WebObjects tier is the interface to the device -- or client. When you put a desktop browser client, mobile native app (Objective C for iPhone or iPad) or a desktop app in front of the app server you make a mobile-enabled stack is simple. And all is right, in the world of SOA.
Wednesday, January 1, 2014
Did Your Espresso Machine Just Tweet You?
When asked, I like to explain the "Internet of Things" as an ecosystem of technologies monitoring the status of physical objects IRL (in real life, in "meatspace", as opposed to cyberspace), capturing meaningful data, and communicating through the great internet IP network to our software apps. For Bluedog, the Internet of Things means smart objects, machine to machine communication, RF technologies, and a central hub of information.
As a proponent of service oriented architecture, I find the idea of the Internet of Things to be compelling. With devices of all kinds reporting data in real-time, people have the ability to make quicker, more accurate decisions. In the supply chain, managers could monitor the status of shipments like a crate filled with expiring pharmaceuticals or spoiling veggies. With sensors, RFID tags, and RFID readers, supply chain participants view in real-time the exact location of the cargo inside the warehouse, its point of origin, time until expiration, and factors in the environment like temperature that might impact the process.
This transparent process improves efficiency, reduces waste, and allows traceability. If a shipment is determined to be unsuitable for consumption due to spoilage or other unforeseen circumstance, the root cause will quickly be discovered from the plethora of information available.
Kevin Ashton likely first coined the phrase in 1999, but the idea has evolved in the intervening time. Initially, it was used to describe the limitations in the relationship between the internet, computers, and the physical world. Ashton was describing how nearly all the data available on the internet originates from a human. With available and emerging technologies, Ashton believed information about things need not be dependent on a manual interaction; it could be an automated process.
At Bluedog, we see the adoption of such supporting technologies as a means of spurring innovation. IP networks are commonplace throughout homes, offices, warehouses, even city streets. Industry need and government mandates are regulating technologies leading to accepted standards across boundaries, allowing for interoperability among devices. The cost and size of devices continues decreasing which allows companies to embed smaller, common items with GPS, Q-codes or bar codes, RFID, and low-cost sensors.
Contemplate the future, on this, the close of 2013. Drones and other autonomous vehicles, more mobile computing, the Cloud, the frontiers of space being pushed back, new genetics, physics, materials science and other advancements! The future is so bright, I've gotta wear shades.
As a proponent of service oriented architecture, I find the idea of the Internet of Things to be compelling. With devices of all kinds reporting data in real-time, people have the ability to make quicker, more accurate decisions. In the supply chain, managers could monitor the status of shipments like a crate filled with expiring pharmaceuticals or spoiling veggies. With sensors, RFID tags, and RFID readers, supply chain participants view in real-time the exact location of the cargo inside the warehouse, its point of origin, time until expiration, and factors in the environment like temperature that might impact the process.
This transparent process improves efficiency, reduces waste, and allows traceability. If a shipment is determined to be unsuitable for consumption due to spoilage or other unforeseen circumstance, the root cause will quickly be discovered from the plethora of information available.
Kevin Ashton likely first coined the phrase in 1999, but the idea has evolved in the intervening time. Initially, it was used to describe the limitations in the relationship between the internet, computers, and the physical world. Ashton was describing how nearly all the data available on the internet originates from a human. With available and emerging technologies, Ashton believed information about things need not be dependent on a manual interaction; it could be an automated process.
At Bluedog, we see the adoption of such supporting technologies as a means of spurring innovation. IP networks are commonplace throughout homes, offices, warehouses, even city streets. Industry need and government mandates are regulating technologies leading to accepted standards across boundaries, allowing for interoperability among devices. The cost and size of devices continues decreasing which allows companies to embed smaller, common items with GPS, Q-codes or bar codes, RFID, and low-cost sensors.
Contemplate the future, on this, the close of 2013. Drones and other autonomous vehicles, more mobile computing, the Cloud, the frontiers of space being pushed back, new genetics, physics, materials science and other advancements! The future is so bright, I've gotta wear shades.
Subscribe to:
Posts (Atom)