With all the media attention to Web Services and now SOA it is an interesting exercise to look back at the steps we took to get here. Hind site is 20-20 and the dead ends that we followed are just memories so the evolution is pretty clear.
DEC VMS
Digital Equipment Corp, maker of the MicroVAX, boasted the first common language programming environment. Meaning that any of the languages, FORTRAN, COBOL, Bliss, etc., could call procedures from the other languages and the VMS runtime and system services libraries. This of course was not across the network, but it did begin the journey toward loosely coupled systems by allowing systems written in different languages to call each other, which was a huge step in code/library reuse. Perhaps the biggest hurdle was mapping datatypes from one language to another.
RPC
The Remote Procedure Call (RPC) allowed a program to call a function/procedure across machine boundaries. The programmer used Interface Definition Language (IDL) to "design" an API and generate a stub and skeleton code. The skeleton code had to be filled in with the remote side code and the stub code was used locally to call the remote procedure. Again, datatype mapping issues where the biggest issue here.
CORBA
Common Object Request Broker Architecture. Besides being a mouthful, CORBA extended RPC calls into a the object oriented world. While CORBA is still viable, Web Services have all but replaced the need for it.
CGI
Right around the time the HTML became popular the Common Gateway Interface (CGI) became the way to deliver dynamic HTML. This was pretty clumbsy because the entire payload had to be generated every time. So, this gave way to just delivering the data from a CGI and parsing the bits (typically CSV) in a hidden frame using JavaScript allowed two things. The UI could be separated from the Web Tier allowing the Web programmer to focus on the user experience instead of interfacing with the backend system. It also opened up the possibility of having more than one client use the same backend. CGI gave way to Java Servlets with better performance.
XML/HTTP
With Servlets dishing up CSV and text blobs to clients, along came XML. At first XML was more of a pain than a help. That is, dealing with it with Javascript, C, or even Java was not easy, reliable, or efficient, until it was widely supported. Soon every language had very good XML parsers and some even saved code. Eventually, the parsers, like SAX and now StAX, made performance only a minor consideration.
XSD
Since XML representations of data can vary greatly the correctness of XML, and so the usefulness of it, varies too. For instance, repeating elements with different meanings, missing or badly named elements are often used. Adding a schema definition XSD or previously DTD provides structure and common datatype definition to XML. Basically, it evolves to better XML. XSD also allows for a message definition and client side message validation. Without XSD, message definition was left to user documentation and server side message validation required a round trip to the server to verify simple things like required elements.
SOAP
Simple Object Access Protocol is really just a combination of the RPC mechanism and XML/XSD. SOAP defines the service operations (functions) and XSD defines the operation payloads (request and response). Typical clients generate stubs and proxy classes to use when calling a SOAP service. The details of the call are handled by the generated code, like the Axis2 client from Apache, wsdl2java or a Web Reference in Visual Studio. The classes acts much like a local object call.
The REST
RESTful services are in interesting evolution or de-evolution. They offer a simpler call interface yet still provide XSD/XML output. Because of the simple use, REST could gain significant popularity.
WS-*
The need for increased functionality from Web Services has pushed for Security, ReliableMessaging, etc. As the standards evolve, so does the usablility.
Wednesday, January 10, 2007
Tuesday, October 18, 2005
BPEL
BPEL
BPEL stands for Business Process and Execution Language. It is a standard from the Oasis group for defining Web Services Orchestration. That is, it is an XML process flow language for calling and defining Web Services. Some of the language constructs are: while loop, invoke, request, response, sequence, etc. A coder will build a BPEL flow and deploy it in a server like BPWS4J or WebSphere Application Server (WAS). BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. (BPEL is also sometimes identified as BPELWS or BPEL4WS.)
BPEL Tools
The IBM WebSphere Business Integration Modeler
http://www-306.ibm.com/software/integration/wbimodeler/faq/faq_51.html http://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/planning/bpm-solution-overview.mspx
BPEL stands for Business Process and Execution Language. It is a standard from the Oasis group for defining Web Services Orchestration. That is, it is an XML process flow language for calling and defining Web Services. Some of the language constructs are: while loop, invoke, request, response, sequence, etc. A coder will build a BPEL flow and deploy it in a server like BPWS4J or WebSphere Application Server (WAS). BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. (BPEL is also sometimes identified as BPELWS or BPEL4WS.)
BPEL Tools
The IBM WebSphere Business Integration Modeler
- Eclipse plug-in
- graphical tool
- Supposed to export to WSDL and BPEL, but the export wizard failed to start for me
- Can import XSD but not WSDL (for referencing existing web services)
- I think the idea of this product is to export to BPEL and import into the IBM WebSphere Studio Application Developer Integration Edition (WSAD - IE)
- Deployment in WAS
IBM BPEL4WS editor or BPWS4J editor
- plug-in for eclipse
- table drive (not drag and drop)
- very basic, you have to fill in much of the information
- Saves to BPEL (this does actually work)
- Provides error messages, but doesn't help you fix them
- Double click properties doesn't work
- Deployment in BPWS4J runtime
I think both of these are free downloads
Microsoft Visual Studio Orchestration Designer
- BPEL compliant
- Deployment to Biztalk
BPEL and enterprise software
Currently proprietary work flow products do not all provide BPEL compatibility. Neither do all the Web Services as a standard interface for the legacy application. As Web Services are added, it might make sense for the work flow to support BPEL and export flows to BPEL for customers to use as a midlevel solution. High end solutions might be IBM's Business Modeler.
References
Friday, April 9, 2004
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.aboutlegacycoding.com/default.htm?AURL=%2FArticles%2FV%2FV60101%2Easp
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
Friday, February 27, 2004
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/
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/
Friday, January 23, 2004
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.
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
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
Friday, January 9, 2004
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://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001891
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
Friday, December 19, 2003
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
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
Subscribe to:
Posts (Atom)
