With Obsydian for Windows NT, Synon claims to be aiming for 50% of the BackOffice application development market. Is this realistic? Right now, Obsydian is the only enterprise-scale client/server application development tool that can automatically generate BackOffice logo-compliant code. This is a decisive feature: Obsydian applications should be as robust as possible on Windows NT, and the logo compliance automatically confers added value.
Its unique status is unlikely to last very long, but once it is established, Obsydian should be able to shed its one major shortcoming: it had been associated exclusively with AS/400 and had therefore been seen as something of a niche product.
Much has been made of Synon's failure to deliver on its promises of Obsydian for a variety of Unix versions. Clearly, to announce a range of forthcoming products and then not deliver is a big mistake; added to this, Unix is a natural target for Obsydian applications. The reasons behind Synon's change of direction have to do with the company's resources and with the result of its relationships with its customers.
Synon is primarily customer -- rather than market -- driven and often seems to work on a per-project basis: developing code as it is needed, then productizing it later. Thus, Obsydian is now available for Unix, but only for HP-UX with Oracle 7.
Synon needed new platforms to exorcise its niche status. At the same time, Microsoft needs AS/400 tools to further its attempts to move into the AS/400 market space. Thus, Synon gains financially, and Microsoft gains status, together with a useful development system: Windows NT server applications are not particularly easy to manage, and Obsydian will certainly help in this area. Client integration of Obsydian applications is also possible; this is done using OLE and DCOM. Because of this, Microsoft Visual Studio applications can be integrated with Obsydian applications.
Products
The Synon/2 development system for the AS/400 was introduced in 1986. Since then, more
than 6,000 companies have used the product to build a wide range of complex midrange
systems. Although Obsydian is in some ways a competitor to Synon/2, the company is
continuing to support and to extend its more established product: Synon/2 is now gaining
Java generation.
Obsydian aimed to gain advantage of Synon/2's robust midrange application skills and take advantage of object-oriented techniques; Obsydian was to be the practical implementation of OO technology. By providing a high-level view of business processes, Obsydian always had the potential for application portability; with the introduction of Obsydian for Windows NT/BackOffice, this portability is gradually becoming available.
As part of the process of productizing what began as customer-specific solutions, Synon is currently developing a set of Business Objects for Lotus Domino applications; these classes are available for beta testing. Obsydian for Lotus Domino was originally developed in the AS/400 environment, but because of Obsydian's inherent platform-independence, applications developed with these objects are directly portable to Windows NT.
Obsydian 2.5
The key concept for Obsydian is the Business Object: this is a macroscopic component,
which is itself composed of lower-level objects. Business Objects represent recognizable
business processes. They are therefore closer to the terms of an application
specification, and because they properly encapsulate their lower-level components, they
are efficient and flexible in development and aid in generating robust solutions. Business
Objects are used to specify a design model, which is logically independent of the deployed
application code.
Working with large-scale objects has proved to be a nontrivial exercise. The obvious solution -- that of using the OO language's class system to build big, application-specific objects -- is not particularly effective, because customizing big object classes is such a haphazard process. Synon has addressed this problem head-on and developed its own abstraction mechanisms -- these are frameworks and patterns -- which allow continuous refinement of the design model. The resulting system allows application builders to start with a set of high-level, business-oriented components, but to retain flexibility without having to descend into a morass of low-level, system-oriented components.
In practice, the Obsydian class library contains the whole spectrum of object types and levels of complexity. These can be summarized as:
· Large-scale Business Objects reflect the most common patterns seen in commercial
applications. These were developed from experience in building real applications and
represent the most significant value-added aspect of Obsydian.
· Functional Business Objects support security, data replication, and business calendars.
To some extent, these are dependent on both operating system and network services.
However, the large-scale objects should remain independent of these functional objects.
· Components enhance the user interface (e.g., GUI controls). Again, these may be
dependent on the presentation platform.
In general, wherever dependencies on deployment decisions do enter the design of the
application, the Obsydian modeling abstractions will isolate these and remain independent
of them as far as possible.
The Obsydian design system is composed of three major components:
Repository -- This is the class library for reusable objects. Obsydian Business Objects can be complete applications; the framework model abstraction allows these complex units to be customized as required. An outstanding feature of the Obsydian repository is its ability to support version control in three dimensions simultaneously: a single object can be stored and updated according to, for example, target platform, nationality (including language and localized business rules), and version. Updates to any one dimension are reflected in the other copies as appropriate.
Design Tools -- Synon intends the design process to begin with the business model, together with its associated business processes and database requirements. Presentation issues are left to the last stage of the design process. A visual design system allows the developer to select the appropriate business object, then instantiate it as appropriate for the given application. The customization process involves refining the database specification, processes, views, then finally screen and report designs. Functions can be defined using either a graphical diagrammer or an action diagrammer, which offers a structured, text-based editor for a Visual Basic-like language. At all times, local modifications will not affect the inherited objects, and changes in the inherited object will preserve local changes.
Application Generation -- Obsydian generates code for the target platform, along with the required database access code. The application is then compiled with standard compilers. Currently, database definitions and views are automatically generated for Oracle, DB2/400, and ODBC/SQL Server. Obsydian does not force a particular client/server architecture on the application and allows the developer to partition the application as required. After the application has been partitioned, Obsydian will generate the relevant calls between the platforms using RPC. It is possible at any stage to reassign the partitioning, and to regenerate the application.
Obsydian is particularly flexible in partitioning and provides three different ways to configure an application:
Design Time -- The different tiers of an application can be explicitly specified inside the design model. When the application is generated, it can be easily deployed across the tiers specified in the design.
Deploy Time -- The application is designed to be partitioned across multiple tiers, but they are not explicitly named. At runtime (using INI files or the registry in the NT environment), the tiers can be given actual physical locations.
Runtime -- Applications can programmatically switch from one tier to another at runtime. This is useful in applications that may share loads or require failover support.
Alternative partitioning strategies could obviously be achieved using Java. Synon recognizes this; however, its Java strategy is currently underdeveloped. Obsydian does now have a Java client option, but because this uses the Microsoft Application Foundation Classes, the process may result in noninteroperable Java code; developers should take care. A 100% pure Java option should also become available. Synon is currently working on server-side Java; this opens up a whole range of possibilities, including deployment using the standard Java Database Connectivity (JDBC) class.
There is no explicit object request broker (ORB) strategy yet, but if both server- and client-side Java were generated by Obsydian, a range of third-party and open standard possibilities would become available.
Java is part of Synon's incremental development of Obsydian, which at some point will become Obsydian 3.0 -- most likely with Windows NT Enterprise, BackOffice Enterprise, and NT 5.0 targets. Other items on the Synon to-do list are Java Beans, full 32-bit support, an SQL Server-based repository, SQL 7 support, and maybe more Unix platforms.
Obsydian for Windows NT/BackOffice
The Windows NT/BackOffice generator is intended for the development or design of
large-scale, distributed client/server applications that are integrated with the Microsoft
Windows operating systems:
· Applications can be implemented for both Win16 and Win32 clients.
· Applications can be deployed and managed through Microsoft Systems Management Server
(SMS); Obsydian will create all the scripts necessary for installing and deinstalling the
application.
· Security issues are simplified, as Obsydian applications automatically incorporate
Windows NT security, based on access tokens for user-based authentication.
· Applications use network independent middleware (Microsoft RPC), so they can be
deployed across a variety of network protocols.
· Applications can be designed for implementation on a wide variety of architectures:
multiple NT or AS/400 servers, multiple server tiers, tier switching, and DCOM.
Obsydian BackOffice server applications use the Win32 API and are implemented as a
collection of services. Communications between services are always via remote procedure
calls, to allow each service to run on separate computers. This distributed function
provides users with the benefits of greater capacity and scalability. The Obsydian NT
Dispatcher acts as a focal point, through which all client requests are funneled for
access to server resources. Server functions are contained in DLLs that the Obsydian NT
Dispatcher finds, loads, and calls into passing the parameters received from the client.
Obsydian OLE Automation provides the capability for applications that are designed and generated using Obsydian to act as OLE Automation Servers. This integration capability allows other development environments and languages to call and interact with Obsydian functions: applications written with Visual Basic, Delphi, C++, C, COBOL, or Java can call Obsydian functions using the OLE Automation protocol. The same Obsydian function can participate with multiple OLE clients, as well as native Obsydian applications simultaneously, but there is a risk involved: OLE automation can be unreliable.
No matter how well-specified an object is within Obsydian, inadequacies and incompatibilities introduced by external components will jeopardize the robustness of the overall application. This is a common problem for OLE users, but will be an unfamiliar hazard for existing Obsydian AS/400 developers.
Platforms
Clients -- Windows 3.11, Windows 95, Windows NT Workstation, character-based
terminals
Server platforms -- AS/400 (with DB2/400), HP-UX (with Oracle 7), Windows (with SQL Server)
Generated languages -- C, C++, RPG (on AS/400)
Pricing
Contact Synon sales offices.
Opinion
Strengths
· From the point of view of its development tools, Obsydian has already proved itself to
be a system with almost no weaknesses. Obsydian can be used to bash out very complex
applications extremely fast, with the assurance that these deliverables will at least be
robust. Iterative development is quick, easy, and reliable.
· The Obsydian Business Objects reach up close to the terms used in any sound business
analysis. This does not reduce the need for experienced developers, but it is a big help
in matching the specification to the completed application. The model works, too: when an
iteration in the business model is required, customization is preserved.
· Obsydian has a brilliant repository design, allowing equivalent design components to
coexist in three separate dimensions. This is just one example of Synon's experience in
the field being fed back into product design. The current repository is implemented on a
server file system, but future versions will use an RDBMS.
· The Obsydian Business Objects library contains a lot of useful material, developed both
by Synon itself and by third parties. IBM operates its own laboratory for Obsydian
application development work by both VARs and corporates, and this has to be a useful
source for further library components.
Weaknesses
· Given that Obsydian is in other respects well suited to large-scale development,
connectivity for databases and middleware components is relatively weak. The reason for
this is that Synon entered the heterogeneous world later than some of its competitors. Its
association with Microsoft might not help it here, because the emphasis now will be on
Microsoft specifics.
· The situation with database and middleware connectivity is also true of operating
systems: Synon is still promising more versions of Unix.
· Synon's Java and object request broker strategies are currently fuzzy: yes, there will
be server-side Java (hopefully, this will be native compiled code), and yes, CORBA is
important. Developing for distributed objects is a challenging process, to which Synon
could contribute a lot. However, as of now, it is not clear what the contribution will be.
· OLE is a problem for Obsydian. Synon is obliged to create OLE interfaces as part of its
deal with Microsoft, and in principle at least, the motivation behind OLE is attractive.
However, by doing so, Synon is opening up its applications to potentially very unreliable
components. Windows users may take this in their stride, but AS/400 users will not.
Bottom Line
Obsydian has always been a highly respected application development tool with only one
limitation: it was seen as an exclusively AS/400 product and was therefore thought of as
being strategically weak and having severely limited use. Added to this problem, Synon
claims that the vast majority of the AS/400 sites it sees nowadays are heterogeneous
environments, with both AS/400 and NT (or Unix) platforms, so something had to be done.
To some extent, there is always a tradeoff between how specific a development tool is to a set of possible tasks and how productive it is when applied to those tasks. In part, Obsydian is productive because it embodies a great deal of experience in building database applications -- Obsydian's object library contains all the high-level database and application component descriptions that most developers will ever need.
The brilliance comes from its object model -- this is much more than a slavish reworking of the familiar inheritance-plus-composition design, common to all OO 3GLs. Instead, it was designed from the ground up to address the manipulation for reuse of complex, high-level objects, as well as a logical disconnection between model and implementation. Both features add to the robustness and flexibility of Obsydian applications, and the overall scheme is well suited to iterative development.
Despite its potential for easy portability, Obsydian does not emphasize either choice of platform or connectivity. Native access to databases is extremely limited: DB2/400 on AS/400, Oracle 7 on HP-UX, and ODBC/SQL Server elsewhere. Even on HP-UX, there is no direct support for Oracle's PL/SQL stored procedures. With Obsydian for Windows NT/BackOffice, Synon is pushing the idea of SQL Server, because this is ODBC native. The problem is that SQL Server is simply not as scalable as DB2. Synon does not say this, and there is a lingering fear that some Obsydian developers will find out -- to their cost -- that there is more to portability than meets the eye.
But users should look on the bright side. This is probably the best development tool for Windows NT, and Microsoft has already set its sights on the midrange server space. Synon, being so clearly associated with AS/400, was the obvious candidates to help Microsoft move into this area. Under the circumstances, it is a little surprising that Synon is still an independent company. Synon may go public this year, and at that point, everything may change.
For its part, Synon seems to have swallowed the whole Microsoft integration package: Obsydian allows access to all BackOffice services, Microsoft integration protocols are used throughout, and to top it all, Synon's Java initiative incorporates the Microsoft Application Foundation Classes (AFC) for Java. The last of these seems to violate the pure Java initiative launched by IBM, Oracle, and Microsoft's other foes. All these integration tools have weaknesses that could cause trouble for the unwary AS/400 application developer. Conversely, for the Microsoft developer, Obsydian is something of a breakthrough.
Company Profile
Synon has made a name for itself by providing high-quality, robust, and
flexible tools for AS/400 application development. The secret of the AS/400's success is
believed to lie in its convenience as a turnkey system, which could be unobtrusively
installed and start delivering business benefits with a minimum of fuss. This sort of
product appeals to the early majority, precisely the market segment so many IT
entrepreneurs never manage to reach. For a single supplier to have obtained, at its peak,
71% of the market for AS/400 development software is an amazing achievement and
demonstrates that Synon has a profound understanding of what midrange customers want.
In pursuit of the key US market, Synon is now headquartered in Larkspur,
CA, with European offices in England, France, and Italy. The rest of Europe, Turkey, the
UAE, and South Africa are covered by distributors. Synon is privately held and officially
does not supply financial details. It has, however, more than 900 Obsydian customers
worldwide and more than 5,000 Synon/2 customers worldwide.
The tools themselves have undergone relatively modest incremental
development; the big change is Synon's partnership with Microsoft to apply Obsydian to
Windows NT BackOffice services. Microsoft needs the likes of Synon if it is to establish
itself as a serious player in the server business. At the same time, this would seem to be
a radical change in Synon's position in the client/server tool business. At the very
least, the company now has a new big and growing market for a product that is already
highly respected.
Founded in London in 1983, Synon is roughly as old as the AS/400 operating
system itself. The company moved to California in 1991. Obsydian was developed by the
company's founder, Simon Williams, who established his own company in London in 1991,
specifically to develop the product. His company, Dysys Limited, was reincorporated into
Synon in 1994; Simon Williams remains a board member of Synon. In 1992, IBM bought a
minority holding in the company. It is possible that Synon may go public by the end of
1997; presumably, this is dependent on the market's response to Obsydian for Windows NT.
Synon now seems to be equally content to supply to VARs and corporates:
American Software of Atlanta, GA, chose Obsydian to create a Windows version of its Supply
Chain Planning software. Chorus Software (part of Datalink International) has decided to
redevelop its suite of financial applications with Obsydian, to port them from AS/400 to
NT and other platforms.
John Wiley & Sons Inc., the US-based publishing company, uses Synon/2
to develop and support a common, enterprisewide platform. Within an initial six-month
period, Wiley developed a corporate business model using Synon technology for its
Singapore site and continued deployment to all its locations during the next several
years. Recently, Wiley expanded its system architecture to address transaction-based
electronic commerce via the Internet, and it is working with Synon and Client-Server
Technology (CST) to take advantage of the two companies' emerging Java technology.
More significantly, James Martin & Co. has developed an enhanced
version of The Client-Server Methodology (TCSM), tailored for use with Obsydian. Unlike
some software vendors that have striven to fill catalogs with scores or hundreds of
application partners, Synon prefers to establish quality relationships with a small number
of leading companies such as AT&T, HP, IBM, Oracle, and James Martin.
Synon Inc.
1100 Larkspur Landing Circle
Larkspur, CA 94939
Tel: (415) 461-5000
Fax: (415) 461-2171
E-mail: info@synon.com
http://www.synon.com
Electronically Reprinted with Permission
META Group Client/Server Tools Bulletin
Obsydian 2.5
Issue Date: 06/01/97
©1995-98 Synon Corporation. All rights
reserved. |