Beyond The Yellow Bubble

Release 1.0.2 of the .Domino Framework will contain the first small steps for building an SOA. The existing Connections feature (available with 1.0) will be extended to support Web Services.

For those not familiar, the concept of Connections is to define all external dependencies an application may have via a series of "Connection" documents.  This eliminates the need for hard-coding the information about external resources.  As documents these can be changed without the need for code changes.  As data documents these can be copied from application to application.  Even the basis for the connection can be changed (e.g. a connection to a Notes database can be defined using servername/filpath, replicid, or NotesURL and then changed on the fly to one of the other methods).

The same need exists when linking to Web services.  The URL used to invoke a Web service will also change each time there is a change to the server name, or filepath.  This includes when an application migrates from a development environment to qa and on to production.  By creating a Connection document for each web service we can change details about the web services withou the need for coding.

The following is a sample of the standard code from a Web Service Consumer generated by importing a WSDL:-

%INCLUDE "lsxsd.lss"
Class PropertyGenerator As PortTypeBase
 
 Sub NEW
  Call Service.Initialize ("UrnDefaultNamespacePropertyGeneratorService", _
  "PropertyGeneratorService.Domino", "http://devservername.domain.com:80/dominoframework2.nsf/PropertyGenerator.wsp?OpenWebService", _
  "PropertyGenerator")
  
 End Sub
 
 Function GENERATEPROPERTY(LANGUAGE As String, PROPERTYNAME As String, FIELDNAME As String, _
 FIELDTYPE As String, GETREQUIRED As Boolean, SETREQUIRED As Boolean, TRACKCHANGES As Boolean) As String
  Let GENERATEPROPERTY = Service.Invoke("GENERATEPROPERTY", LANGUAGE, PROPERTYNAME, FIELDNAME, FIELDTYPE, GETREQUIRED, SETREQUIRED, TRACKCHANGES)
 End Function
 
End Class

As you can see, the server name and filepath of the web service is hard-coded.  If this pointed to a dev server you would need to change the code before it is migrated to production (never a good idea).  Using a Connection the code could be rewritten as

%INCLUDE "lsxsd.lss"
Class PropertyGenerator As PortTypeBase
 
 Sub NEW
  Dim URL As String
  URL$ = GetConnectionString("PropertyGenerator")
  Call Service.Initialize ("UrnDefaultNamespacePropertyGeneratorService", _
  "PropertyGeneratorService.Domino", URL$ + "?OpenWebService", "PropertyGenerator")
  
 End Sub
 
 Function GENERATEPROPERTY(LANGUAGE As String, PROPERTYNAME As String, FIELDNAME As String, _
 FIELDTYPE As String, GETREQUIRED As Boolean, SETREQUIRED As Boolean, TRACKCHANGES As Boolean) As String
  Let GENERATEPROPERTY = Service.Invoke("GENERATEPROPERTY", LANGUAGE, PROPERTYNAME, FIELDNAME, FIELDTYPE, GETREQUIRED, SETREQUIRED, TRACKCHANGES)
 End Function
 
End Class

It would be fair so say over the past few weeks that I have been caught up in all the hype about XPages.  So much so that I had forgotten about the thing I was most looking forward to when doing Notes 6 development.  For me the single most important recent enhancement to Notes was not XPages or even the new LotusScript editor (in 8.5.1) but the ability to design Notes applications using a Services Oriented Architecture.  To me this one new capability ensure Notes future more than anything.  Let me explain why.....

What Is SOA?
There are many definitions out there on SOA.  To me SOA extends the concept of Object Oriented Programming to an entirely new level.  With OOP we define applications as objects (classes) comprising properties (data) and operations (methods).  Now step back and look at all the applications in your organization.  Not as a disparate set of applications but rather as a series of components capable of interacting with each other without regard of the application platform in which they were developed.

Why Is SOA so Important?
Suddenly the application platform is no longer as important as it once was.  As long as that platform supports Web Services (and other higher levels of SOA such as property brokers etc.) it really doesn't matter platform what they are written in.  Notes applications no longer need to be second class citizens within an IT department.  By creating Web Services Notes applications can be accessed by non-Notes applications in the same way as any other SOA application.  Likewise Notes applications can also access data from these other applications directly without the need for LEI or other data synching processes.  Moving towards an SOA has the potential to solidify a place for Notes as a strategic application development environment.  For the great many small-medium sized applications Notes will often offer a clear advantage over alternatives due to its RAD environment.  In fact, the need for large applications can be replaced by building a a larger number of smaller components that are intergrated via SOA.

And Xpages?
Xpages can consume Web services so they are not excluded from this and this may even represent a better way to integrate XPage and non-Xpage Notes applications.  Even within a single Notes applications, web services represent a way you can invoke LotusScript code from inside an Xpage.

SOA will not happen overnight.  Some organizations are much more advanced than others.  With Notes 8.x SOA is relatively simple to implement .  So the opportunity is there for Notes developers to lead the way   Web service providers were added in Notes 7.  Web Service Consumers and Composite applications were added in Notes 8.0.  My suggestion would be to become familiar with these design elements and play around with them.  I will be developing SOA components as part of the .Dominio Framework 2.0 and you will probably see as many blogs from me about SOA  as XPages in the coming months.  My goal is to transform my own Notes applications into components and then start integrating them, in ways that were never possible before.

In Part 1 and Part 2 I presented the opportunity to add functionality to applications by generating a collection of data (dataset) at run-time  and presenting this data within a Notes application as a datagrid.  Using this technique it becomes possible to do such things as embed multiple category views, display the top 5 x by category, or generate dynamic columns based upon logic built into a form.  The components to implement this in the .Domino Framework are based upon Notes 6.0 (Form, View, Folder, LS Class).

In July I will be starting work on .Domino Framewok 2.0.  This new version of the framework will be targeted specifically at Notes 8.5.1.  (I previously blogged about bypassing 8.5.0 and whilst a year has now passsed my views havent changed about this).  One of the first things I want to do with 2.0 is extend the concept of datasets/datagrids even further....

In .Domino Framework 2.0 the process for building a dataset will be converted to a Web service.  The Web service will then return a Notes URL that correspons to either an existing view/folder that can be used to view this dataset or a folder that has been dynamically generated by the Web service.  This takes the task of (potentially) building a document collection away from the Notes client and places it on the Domino server.  What it also means is that I now have a simple way to build a dataset in one Notes database and pass it to another Notes application where it can potentially be embedded in a frame, form, page, or XPage.  This may not always be the most efficient way to achieve the end result, but in implementing an SOA approach, it eliminates the need to customize views in application A to meet the needs of Application B.