What good is a Service Oriented Architecture with no services?
There are many great ways to exploit a Service Oriented Architecture, or SOA, a.k.a. bunch'a web services. CodeProject members familiar with the Visual Studio Web Reference capability know how easy it is to point at a server and gain access to its available web service calls. Along with Visual Studio, there are a number of available commercial products and libraries that can consume a web service but only if the web service is available!
The ability to consume an existing Web Service and exploit it in the creation of something new and cool, like a user-designed visual workflow solution, is widely available today.
Implementing those fifteen Web Service calls to enable a decent order entry system? In an organization that already has a complete terminal-based order entry system running on a back-office UNIX box? Not so available, and not so easy. Lots and lots of days/weeks/months to implement, even more days/weeks/months to test and put into production reliably.
Who cares about old UNIX VT100 or IBM Mainframe applications?
If the only applications you will ever need to deal with are all modern, well-architected SQL/Server .NET applications, well, you might have something better to do than read this article. But, if there is an IBM Mainframe, an IBM iSeries/i5 (AS/400), DEC/VAX, or UNIX application in-use at any organization you work for or with, our breakthrough in Web Service development is about to be explained.
Why is this a "Breakthrough"?
Using APIs to hook-up to existing terminal environments to exploit the underlying business functionality has been in use since the 1970's. Unpopular with many, it is commonly referred to as "Screen scraping". In the past, using low-level API sets to read and write a "green screen", then simulate the "ENTER" key to move to the next screen, could involve some tedious, messy coding. Thus, the preference by some to avoid the "Green Screen" and go for the "Green Field" project with a clean slate and, perhaps, a contemporary relational database...
But what if the existing functionality behind all those screens, including data entry and update, could be wrapped easily and quickly with a high-level toolset? What if, instead of an empty SQL Server catalog, your "Green Field" was a comprehensive set of Web Services that take care of all the heavy lifting and leave you with the role of implementing a brand-new user interface or workflow solution?
This is the breakthrough I am writing about, and it has been introduced this month with the general availability of the Flynet Viewer Studio. This is the part of the release of Flynet Viewer Version 4, a suite of development tools and a powerful Windows-based terminal emulation server.
Introducing the Flynet Viewer V4 Studio
We, at Inventu, have been involved in mainframe integration since its very earliest days, and have never seen any product that comes close to this product for ease of development, speed of success, and depth of the final product. Flynet Viewer Studio, from Flynet LTD in the U.K., is a 100% .NET product which, along with Flynet Viewer V4, includes these features:
- Familiar Integrated Development Environment (IDE) user interface
- Recorder to document and encode how users work with host applications
- Visual mapping for defining and naming recorded screens and data fields
- Visual workflow modeler to define ASMX modules and available methods
- Integrated CodeSmith code generation technology
- Generates 100% Visual Studio Web Service solutions for both VS2003 and VS2005
- For Framework 2.0, optionally instantly publishes web services (no Visual Studio required)
This product's most revolutionary feature is the code generation framework. Taking nothing more than a few recordings of users interacting with the existing application (as well as developer settings made in the property sheets of the IDE), the framework is able to analyze the navigation between screens and generate a complete Web Service folder including both inquiry and entry/update operations.
With this new development framework, if you can see it work in a user's terminal emulation screen, you can use it to publish a web service.
Three Steps to a Web Service
Thanks to the powerful, flexible, and extensible code generation architecture of Flynet Viewer Studio, we can help you rapidly create web services in three steps:
Figure 1: Flynet Viewer's three steps to a Web Service
Building a Web Service with the Flynet Viewer Toolset involves three principal steps: recording the application, mapping fields and designing workflows, and running the code generation wizard. Mapping fields, setting object properties, and designing workflows require that at least one member of a development team learns how the host application works as well as how the Flynet Toolset works. This may be an ideal role for an existing host system developer, and is an excellent way for a COBOL or RPG developer to gain exposure and training in .NET development.
The generated Web Service
If you are like me, your first question when you hear "code generator" is "junk generator?" After all, many products generate applications based on either proprietary binary formats or obscure and proprietary scripting languages. Other products I've evaluated produced code that resembled an entry in the International Obfuscated C Code Contest!
The astute reader might note that I only ask questions that I can answer in my favor. So, no, the code generated by the Studio is not junk! It is well structured, documented, and has a clean class design. In fact, the generated application framework and code classes are based on multiple customer applications delivered by Inventu consulting services that have been live and in production for over a year.
Even if it were junk, you have full control over the generated code since all of the CodeSmith templates used in the generation are provided in source format with the product installation. We expect and encourage our customers and consulting partners to tune the templates to best fit their needs.
Figure 2: The generated Web Services runtime environment
The above is a high-level diagram of the components that make-up the generated web service. As a standard ASP.NET application, the Web Service gains all of the advantages of the ASP.NET SOAP support, as well as the highly acclaimed HTML testing interface. The only "black box" in the above diagram is the core emulation service itself; all user logic and Web Service definitions are implemented using a standard .NET and Visual Studio solution.
Thank you, CodeSmith
When we started the design for Studio a number of years ago, we knew that application generation was critical for the success of the product. We also knew that code generation requires a high degree of extensibility and flexibility, or the nitpicking details would rob us of the productivity we would need to deliver a high quality end product.
Early on, we chose CodeSmith as our code generation "partner", and have licensed their code generation technology with each copy of Viewer Studio. This has enabled us to create custom property grid classes within "our" Studio to plug-in properties and whole sets of logic as the CodeSmith templates are generated.
The end result is a powerful code-generation environment with the flexibility and extensibility we sought early on. The CodeSmith Studio for editing templates has been particularly valuable in meeting our goals. So, thank you, CodeSmith :)
Ready to run with Framework 2.0
The code generation framework supports both .NET Framework 1.1 (VS2003) and Framework 2.0 (VS2005), with a simple radio button in the wizard selecting the target.
With Framework 2.0, due to the integration with the MSBUILD utility included with the base framework, the generated Visual Studio 2005 solution is "good to go" with MSBUILD. What this means is that the code generation wizard will ask:
Figure 3: Framework 2.0 includes MSBuild support; no Visual Studio required
Ready to load in Visual Studio
The generated solution includes multiple projects, based on functional areas of the application. Both Visual Studio 2003 and Visual Studio 2005 are supported, and a solution file is generated for each. To make life even easier, an optional desktop folder is created by the wizard to provide a handy link to the <solution name>.sln file.
Figure 4: Optional Desktop folder with handy links
Once you load the solution, the Solution Explorer will contain a number of projects, including a reference to the web folder (if ASP.NET 2.0 and Visual Studio 2005 are installed), as the following screenshot shows:
|
This solution includes the following projects:
| Etc: |
Includes miscellaneous classes, a Debug logger, enumerations, and so on |
| ...\web: |
This is the ASP.NET 2.0 web folder, and contains the ASMX files and code-behind files that provide the Web Service interface |
| LogonEditor: |
Optional WinForms project for maintaining pooled session passwords (encrypted using RijndaelManaged .NET support) |
| SessionPool: |
Optional pooled session class, which provides high-speed switching between requests for a shared pool of host sessions |
| Tasks: |
The workflow management classes and methods which provide session control, navigation and view state management for the ASMX modules |
| Tasks/Lists: |
Special classes to manage multi-row lists, supporting paging through multiple screens and selection of rows for further action | |
Figure 5: The generated Visual Studio solution | |
Does the generated code need to be tweaked?
The definitive answer to that question is the standard for all questions of this nature: "maybe."
The areas we see that could benefit most from tuning are the Web Service interface and screen navigation. The parameters declared in the public WebMethod methods as well as the objects returned could be tuned without affecting how the screen interactions occur.
The following code fragment shows a generated WebMethod call, with two key variable parameters that can be renamed, removed, or added to, depending on how you want to publish this method.
[WebMethod(Description="Start the UpdateAccount workflow,
return the AcctUpdate data")]
public UpdateAccountInfo UpdateAccountGetAcctUpdate(string sessionKey,
string Company, string AccountOrPolicy)
{
UpdateAccountInfo info=new UpdateAccountInfo("ok");
TaskSession ts=null;
try
{
ts=TaskSession.GetSavedSession(sessionKey);
#if DEBUG
if (ts!=null)
ts.Dbg.Explain("CodePoint #11",
"Update.UpdateAccountGet Web Service Method...a data update method "
+ "The ioType for the ProjectTask and "
+ "this ProjectScreen is Edit_Existing_Data. "
+ "The sessionKey ("+sessionKey+") was "
+ "used to pull the TaskSession object "
+ "from the TaskSession static storage"
+ " using the GetSavedSession method.");
#endif
UpdateAccountTask task=
(UpdateAccountTask) ts.SetActiveTask(TaskID.UpdateAccount);
IOBag ioBag=new IOBag(7);
ioBag[FieldID.Company]=Company;
ioBag[FieldID.AccountOrPolicy]=AccountOrPolicy;
ts.Dbg.Log("WSTask","Update.UpdateAccountGetAcctUpdate Top,
ioBag contents=",ioBag);
task.Start(ioBag);
task.ReadAcctUpdate(info);
}
catch (System.Exception ex)
{
info.status="Exception";
info.message=ex.Message+":\r\n"+ex.ToString();
ts.Dbg.Log(LogLevelEnum.ExceptionsOnly, "WSExcpt",
"Update.UpdateAccount Exception, " +
"info.status=\""+info.status+"\",
info.message=\""+info.message+"\"");
}
return info;
} |
Figure 6: A sample Web Service method from a generated ASMX module
Supporting non-standard host applications
Included in the challenges for users of mainframe applications are the many unique and sometimes odd user interfaces. While this is a strong justification to front-end these screens with contemporary .NET applications, it is a challenge for the Flynet code generation wizards.
At Inventu and Flynet, we anticipate and support applications on our customer's host systems that break or compromise the active internal rule base of the Flynet Studio code generation wizards. Support of these non-standard applications is a simple process:
- Open a ticket on our Web-based Helpdesk
- Describe the goals of the workflow that is not generating properly
- Zip your Studio Project file and host screen recordings and attach to the ticket
Using the standard Flynet Viewer simulated host service, our support group will replicate your host application from the recordings you provide (no connection to your host is necessary). We will then analyze the screens and workflow and add the missing rules into the code generation engine and templates. Updated code generation assemblies and templates will then be posted back to the ticket as well as added to the product update downloads.
This service is free for customers. It is also offered to evaluators willing to commit to a future purchase based on the success of our effort.
Wizards-in-Process
With the power of the code generation technology live for creating Web Service solutions, the Flynet Viewer developers are busy on future application wizards.
The first of these, expected later this year, is a generator wizard for a full green screen to Visual Studio ASP.NET User Interface solutions.
Conclusion
The Flynet Viewer V4 Studio provides .NET development teams with a radical improvement in their ability to tie new .NET projects into existing Enterprise applications. Viewer's "See It, Use It" ability to publish existing screen-based host applications as Web Services brings the real promise of Service Oriented Architecture to .NET.
**CodeSmith and Microsoft are registered trademarks of their respective organizations in the United States and/or other countries.
