Object COBOL

Description
In December of 2002 a standard for a new version of COBOL was ratified, Object COBOL. Before you laugh, listen up! They added syntax to the 40 year old language to create class instances and invoke methods in those classes. This means 2 major things: First: the class instances can be activated as a thread instead of a process and pooled in an application server. Second: Interoperability between other OO languages and COBOL is possible. That is, Java can call COBOL and the COBOL can call Java.

The syntax is a little clunky primarily because the period (".") is already used to mark the end of a sentence in COBOL. So, there is a little redirection. For instance the following syntax might be used to create an object instance and then call the ?GetHelloWorld() method.

INVOKE ABC-CLASS "NEW" RETURNING XYZ.
INVOKE XYZ "GETHELLOWORLD" USING "MYNAME" RETURNING MY-NAME.

Microfocus, Fujitsu and IBM are compilers available for Object COBOL.

Fujitsu
The Fujitsu NetCOBOL for .NET product produces a dll of "managed" classes that run in the Microsoft .NET Framework. The .NET application server installs with Windows 2003 server. The application pooling and scaling is managed from IIS 6 application console. Interoperability between .NET classes and the COBOL follows the Object COBOL standard. Visual Studio 2003 for .NET is the development environment.

Microfocus
Microfocus NetExpress has 2 variations, one for J2EE interop and one for .NET. The NetExpress class declaration syntax breaks from the Object COBOL standard slightly, but is basically straight forward. Microfocus has its own application server to provide interop between a J2EE app server and the COBOL. The Java version IDE is also a Microfocus product. The .NET version is similar to Fujitsu where the IDE is Visual Studio and the app server is .NET.


Additional References

• http://www.infogoal.com/cbd/cbdobj.htm
• http://www.aboutlegacycoding.com/default.htm?AURL=%2FArticles%2FV%2FV60101%2Easp

Apache Axis

Apache Axis
As a follow-on to the Apache SOAP project and built on Tomcat, Apache Axis is a Java Web Service deployment server. Axis conforms to SOAP by implementing the JAX-RPC API.

JWS
Axis has a simple way to deploy Web Services, the JWS file. This is a java class with methods that accept and return primitive classes, like String and Integer. The classes are saved in the axis tomcat webapp directory with the .jws extension. Axis compiles the java and generates a WSDL.

WSDD
Axis uses Web Service Deployment Descriptors (WSDD) to describe, register and deploy Web Services in the server. While document style can be specified when deploying a Web Service, currently only primitive parameters can be passed.

What this means to enterprise software
It would be possible to use Axis to deploy SOAP Web Services. It would, however, be limited to Tomcat installations and each of the Web Services would have to be registered with a separate generated WSDD. Also, the current version of Axis does not support document literal Web Services, which is required for Microsoft integration.

References
http://ws.apache.org/axis/

Authentication

Authentication
HTTP Authentication is needed to secure web resources, including directories, files and services, including cgi, servlets and web services. The following list of authentication types are the most common and supported by a wide variety of servers and clients.

• Anonymous
  No challenge to http resources.
  
• Basic
  Sends the password in the http header unencrypted. Supported by most servers, clients and browsers.
  
• Digest
  Similar to basic, but sends password encrypted so more secure. Supported by Apache with a module and IIS natively.
  
• Forms
  A session id based on identity is kept in a Cookie and passed in the http header. Cookies are specific to the browser instance. IIS also provides a framework for implementing this.
  
• Passport
  Microsoft's single sign on solution, with a centralized solution. Native support in IIS/Windows 2003, browser support is not limited to IE.
  
• Kerberos
  A network authentication protocol, implementation available free from MIT and commercially from many vendors, including Microsoft IIS. While the MS implementation in Windows 2000 does use windows user accounts, it is not specific only to IE.
  
• NTLM
  A Windows Integrated authentication similar to Kerberos, but for prior versions of Windows.
  
• Certificates (X.509)
  The client maintains a digital certificate. "Digital certificates are, in essence, electronic ID cards that are issued by trusted parties and enable a user to verify both the sender and the recipient of the certificate through the use of public-key cryptography." Both IBM's Tivoli and IIS support certificates. Not all clients and browsers support certificates because a client install is required.
  

What this means to the enterprise

Since proprietary SSO products are typically based exclusively on a Forms style authentication, it is a strongly encrypted authentication, but we are limited to clients that support it. Also the session is limited a single client session. This means that if you start up another session you will be forced to login again. I believe that we should continue to support basic authentication in 8.1 and moving forward we should support the emerging standards, such as X.509 and Kerberos.

References

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/netdevanchor.asp

http://as400bks.rochester.ibm.com/tividd/td/TWS/SC32-1265-00/en_US/HTML/Eqqc1mst72.htm

http://web.mit.edu/kerberos/www/

http://support.microsoft.com/?id=264921

Microsoft SharePoint

Windows SharePoint Services
WSS is a server portal component included in Windows Server 2003 for creating a workgroup collaboration site. It includes document upload, indexing and searching. It also includes Alerts, which are triggered when a document or document area has been changed.

Why develop on WSS?
Web Parts. Microsoft put a modular user interface into every SharePoint site, and it uses the full power of ASP.NET and Visual Studio .NET. Web Parts are created from within Visual Studio and have strong integration with Web Services. Sites as Programmable Objects. SharePoint sites, their contents, and the servers that deliver them are accessible, manipulable, and extensible via a managed code API and set of Web Services. You can even package them up as Templates to deploy reusable solutions. An accessible, extensible content store for documents and other data. You can reach the contents of a SharePoint site via Web Services, WebDAV, or the Windows XP Web Client service. Office applications read/write from/to SharePoint sites.

SharePoint Portal Server 2003
SPS is an enterprise portal server which can tie together individual SharePoint sites. This is a separate product.

Why develop on SPS?
It's based on Windows SharePoint Services. If it works in a SharePoint site, it'll probably work in a MySite, an area or a portal home page. Extensible services for indexing and search, people and personalization, and content aggregation/organization. Enterprise Application Integration features, particularly in the areas of Single Sign-On and BizTalk Server interoperability.

InfoPath Integration
InfoPath, which is a new Web Services forms product in Office 2003, is tightly integrated with SharePoint . It allows for saving forms to and launching forms from a SharePoint forms library. Also, forms data, with repeating complex elements, that is saved to a SharePoint library can be automatically aggregated into a single form inquire. For instance, travel expenses from a department can be merged into a single InfoPath form.

What this means to the enterprise
SharePoint integration is one of the most frequently requested feature from enterprise clients. I believe these are larger clients that have software from other vendors in addition to enterprise applications. One thought is that the enterprise portal could run in a SharePoint instance. Or perhaps integration could be reached using specific WebParts created for forms and drill, calling enterprise Web Services. While this would be a specific platform implementation, it could be a strong product offering for the enterprise.

References

• http://www.microsoft.com/sharepoint/
• http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001891

WSDL

WSDL
Web Service Description Language (WSDL) is an XML document standard defined to describe a SOAP web service. Specifically, a WSDL defines the message, portType, binding and services of a Web Service. The message is basically the XML schema of the SOAP envelope contents, including message structure and the data types used in the message. The portType describes groups of operations (methods) including input and output messages (parameters). The binding describes the specifics of a portType, including style and soapAction. Finally, the service section describes the location of the Web Service, which is often a URL.

WSDLs are consumed by programs which create proxy classes such as wsdltojava from Apache Axis, which generates Java, or wsdl.exe in .NET, which generates VB, C#, or JS. WSDLs are also consumed by Web Service messaging products such as XML Spy Pro and Microsoft InfoPath.

WSDLs are created from classes by javatowsdl or directly by Web Service servers. IIS automatically produces a WSDL for a .NET Web Service. Axis will produce a WSDL from a jws file, which I will discuss next week.

What this means to the enterprise
Simply wrapping a legacy application in a Web Service is very powerfull. This allows Web Service enabled application, such as Microsoft Office, to talk to the Applications (more easily). The preliminary schema validation of the message occurred client side, with no additional programming. This validation, combined with the definition of a specific message description in the WSDL, including readable legacy field names with some meaning, enabled a user, to build an application that consumed this web service.

References

• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/understandwsdl.asp
• http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html
• http://ws.apache.org/axis/java/integration-guide.html

UDDI

UDDI
Universal Discovery Description and Integration (UDDI) is a protocol standard for Web Services repository. Specifically UDDI allows for storage and searching of web service WSDL files and associated information, like web service descriptions, provider information, and categories. Currently UDDI V3 is in beta implementation at the IBM, Microsoft, and SAP sites listed below. You can register and search for Web Services at these sites. The standard describes Web Services for publishing and searching for Web Services.

Support
Microsoft provides UDDI support in Visual Studio and Office for locating and consuming web services, addition to an SDK to publish and search. Also, UDDI services are delivered with Windows 2003 Server.

Also, there is a java UDDI server available on sourceforge and there are java APIs for accessing UDDI, including uddi4j and JAXR. However, using the Web Services described at the sites below is most likely a preferred method to search a UDDI registry.

UBR
Universal Business Registry (UBR) is a specific implementation of the UDDI V2 standard for search for businesses and business web services.

What this means to the enterprise
When an enterprise supports SOAP Web Services for data access, form definitions, and db actions, these Web Services could be published in a local directory at a clients sight. A design tool could search UDDI like the way it searches for web pages today through a search engine. These local UDDI searches could be combined with searches to multiple local servers and Internet based UDDI servers. Since Web Services are the end result of any UDDI search, this would be most appropriate for a developer in a forms designer scenario.

References

• http://www.uddi.org/
• http://uddi.microsoft.com/
• http://uddi.ibm.com/
• http://uddi.sap.com/
• http://soapuddi.sourceforge.net/

SQLXML

SQL XML
SQLXML is a really interesting feature of Microsoft SQL Server 2000. It allows you to send SQL statements or XML queries to the server and get XML back. For instance you can send a SELECT statement to get back a list of currency codes. This would be very useful in an SEA style web applications. It also has support for SOAP Web Services, XPath queries, and SQL templates for other operations, like UPDATE and INSERT.

Since SQLXML is accepting SQL and making the database queries through native drivers, it should perform and scale significantly better than DME.

Authentication and Security
Authentication is managed by IIS virtual directory permissions. Since this utility is native to SQL Server database, security would be limited to the table and column security managed directly by the database. Lawson currently has a utility to dump SQL statements from LAUA data, bldibmsec for db2, to a script file. This script is executed on the database and applies grant/revoke privileges to table and column entities. This native database security is used to secure direct database access with ODBC, OleDB etc and would apply to SQLXML access.

What this means to the enterprise
I believe that it would be possible use to SQLXML to access enterprise Database Information. This would provide direct URL based XML data access without the need to go through a custom DB layer. The drawbacks include lack of support for metadata and custom security. Also, Oracle and DB2 support for an SQLXML standard is not clear. Giving SQL database access to application developers provides more flexibility and also opens the door for problems like database tuning, index design, and SQL syntax issues between db vendors.

More Information
http://www.sqlxml.org/
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001300