EXTOL Technology Blog

Class and object design can be a tricky thing.  It’s not really something that can be taught or quantified.  This skill is developed through years of experience.  This may be more of an art than it is a science.  No expert can come up with an exact formula on how this should be done but all experts can pretty much agree on what is a bad design.

A possible starting point of a process could be to develop a written problem statement outlining the issue at hand.  This can be done by interviewing a customer or whoever the requirements are coming from.  Once the problem statement is developed you will find that the nouns in the statement will turn into classes and the verbs in the statement will turn into operations.  From there relationships between the classes can be derived.  Statements like “is a” can denote inheritance, “has a” can denote composition, “uses” can denote delegation, etc.

A UML diagram should be drawn modeling what was discovered by the problem statement.  It is also good to keep a catalogue of design patterns at hand so that a given pattern may be applied to a module of the software system.  Remember that Object Oriented Software is about loose coupling, encapsulation, and reuse, which design patterns help enforce.  Once the initial diagram is developed it is really more of a guideline than concrete fact at this point.  When the implementation process begins new facts will come to light that haven’t been considered before which will ultimately force the redesign some components of the software.  Once this happens the diagram should be updated to reflect the new functionality.  This will create a software cycle that will bounce back and forth from implementation to redesign approaching a final version of the software.

This is really only a generalized overview of an absolutely monstrous topic in which there are many different paradigms and many different ways to go about tackling the problem.  As a closing thought, keep in mind that a design is never really complete, that it can always be improved upon and made more robust, clearer, and more efficient.

If you’ve ever dealt with changes to a working version of a schema, whether it is database, EDI, XML, or whatever format your data may be in, then you know how painful it is.  In most shops in the typical data processing scenario, either a tool or a custom program is used to process the data in one format and convert it to another format to be piped off for further processing somewhere else.  The most difficult to deal with example can be changes to an XML schema.  The reason is that XML is so extensible and just about anything can be done with it.  The contrasting example would be EDI data where the changes are usually miniscule and the structure itself does not vastly change.  The typical example that most IT shops face is a change in a database which could be the addition of a table or column, the deletion of a table or column, the moving of a table or column, or a change in table/column properties.

If we look at this from the perspective of a model, a schema is really a tree or graph (depending on whether it’s recursive) with entities representing the schema structure. Read more…

When you ask recent IT graduates about the IBM i they either have never heard of it or think of green screen and RPG.  The IBM i has been more than green screen and RPG for a long time and has progressed along with the needs of its customer base, always keeping pace with current trends.  It was 20 years after the original release of the IBM System/3x, lineup that Sun released it first version of java.  And java was not widely used until a few years ago.  Those first releases of Sun java performed poorly.  The first releases of java on the IBM i had the same poor performance issues, but with the recent releases of the OS and Power hardware, java performance on the IBM i is now inline with other platforms.  Read more…

How do people learn best? As a trainer, I often think about what is the best way to present training material so customers can understand and get the most out of our products. There are two main factors that I take into account when developing new training curriculum: Learning Styles and Delivery Methods.

There are number of different learning styles, I refer to them as the “Doers”, “Listeners”, “Watchers” and “Repeaters”. The “Doers” have to do it themselves to learn the lesson.  They usually like to figure things out themselves. The “Listeners” normally learn the best by just hearing the information. The “Watchers” learn by watching someone else do the lesson. They are very visual and love diagrams. The “Repeaters” use a combination of listening, watching and then doing what was just taught. They learn by repeating the lesson. I think most people understand what style of learning works best for them. I am a “Repeater”.

Delivery Methods also vary. I refer to some of the different methods as “Traditional Classroom”, “Phone Call”, “Looking over the Shoulder”, and “Web Based”. Read more…

There’s a lot going on in our system…. What does it really mean?

Complex Event Processing (CEP) is an emerging field that leverages the transport-level layer of the Event-Driven Architecture (EDA) model and applies an “analysis” layer on top of it.  EDA enables you to monitor and analyze important events that affect your business – like unusually large orders, significant inventory draws, critical processing delays, high- and low-water resource thresholds, and even suspicious activities – and provides a technological basis for responding to those events.

Supplementing conventional batch processing with EDA requires a mindset change, but once you have an EDA implemented, a lot of useful and actionable information about how things are working in your system becomes available.  However, coordinating this analysis and correlating disparate events into meaningful information is not a trivial task.  Read more…

Having just returned from a 2-week vacation, I’ve had plenty of time to think about things that my work schedule normally pushes to the background – music, hobbies, investments (don’t ask), and our surreal national political scene. After listening to some of the bizarre preconceptions and arguments about health care reform and US economic policy (throws shoe at TV), it’s hard to avoid the conclusion that many of our beliefs are so ingrained that they approach the status of “religious” tenets.

As business and IT professionals, we like to think that we operate in a reality-based world, where facts and good sense dominate. But the same factors that muddy public policy decisions – incomplete and inaccurate information, the lack of a contextual model that can assist in predicting outcomes, and inherent biases toward or away from certain solution approaches – are just as influential in the decisions we make, every day.

One example that’s top-of-mind, for me, is the debate over managed services delivery models.  EXTOL and other companies in the B2B integration space have offered managed services for years, but cost-cutting measures and our shrinking economy have pushed managed services to the fore, of late.  We are still seeing greater demand in the market for self-managed B2B integration than for 3^rd party managed services, but battered budgets, scarce IT resources, and shifting business priorities make managed services more attractive than ever.

Deciding between self-managed B2B integration and managed services integration usually comes down to financial and budgetary factors (capex vs. operating budgeting, front-loaded vs. ongoing expenses, etc.). While “religion” can come into play here, decisions at this level are usually based on clear-cut business priorities. Read more…

For my inaugural post on this blog, I want to revisit one of those “solved problems” that still dogs many of the companies we talk with, namely, how to handle B2B integration requirements that don’t involve standard EDI. Companies still find it difficult to cope with the full range of B2B connections and content types needed to integrate with large and small trading partners, including:

• Standard EDI (and in some cases, EDI that does not fully conform to standards)
• “Standard” XML, which ranges from well-developed, horizontal standards like RosettaNet to hundreds of loosely-defined vertical transaction sets
• EDI-like flat file standards (most of these are older, vertically-focused cases)
• EDI-based web forms
• Proprietary, partner-defined flat files
• Proprietary, partner-defined spreadsheets
• Proprietary, partner-defined web portals
• Proprietary, partner-defined documents sent by email or fax

Did I miss any? Probably. But the point is that standard EDI is just one of numerous conventions used for B2B integration.  Of course, standard X12 and EDIFACT EDI are still the mainstay of B2B integration. And there is little evidence to suggest that companies are ready to invest in replacing all of their EDI connections with something “better”.  In fact, EDI adoption is increasing.

Read more…

Welcome to EXTOL’s Technology Blog with insights and technical information from EXTOL International Inc. expert staff. We will bring you insights on application and data integration, EDI/B2Bi, emerging technologies and integration trends.

EXTOL is a leading provider of B2B, application, and data integration solutions for mid-sized companies and other lean enterprises. It is imperative to us to stay in-tune with leading technologies and new issues effecting EDI and B2B integration. And, even more important to share that information with you!

This Technology Blog provides the perfect place for us to meet, connect and converse on today’s hottest topics.