wouldn't it be cool if.... ?

One of the various things we try to install in our software design is flexibility and accuracy of documentation so that when that inevitable "wow wouldn't it be cool if..." comes up from a customer, a partner or one of our very own team members we can actually respond to that idea fast to improve what we can offer.

It seems to me that this kind of responsiveness is a goal of many in the software field, though many seem to struggle to make it a reality which is a shame because the benefits of it to everyone involved with your software are enormous.

There is much you can do to make this a reality, but the best thing you can do in my opinion is regularly put such a "wow" idea into action and see how well your team is able to respond.

So although we are swamped with work right now (isn't everyone 24/7? these days) thats exactly what we spent the afternoon doing. At 2pm the Enterprise Sign On Engine was not able to undertake access control based on an action being applied to a resource, it could do lots of impressive decision making based around access to resources, but it was blissfully unaware tof the user invoking a read, a write, a pull, a push or any other action you care to think of a user performing on any given resource.

At 5pm the Enterprise Sign On Engine could do lots of impressive access control decision making for resources, only now it could also look at the action the user was undertaking (or potentially may wish to undertake) as advised by the SPEP and incorporate that into the decision process. Everyone can view but only a subset can write? No problem. Anyone can push data but you can only stream if your from a trusted federated partner or in the central administrators group? No problem. You can see a list of servers but you should only be able to see the ability write DNS changes when your access name is 'fred' (and of course actually carry out the DNS change action ;) ). Again no problem.

So for three hours work we're able to significantly enhance the value of the software, introduce more features into LXACML from its much bigger XACML brother, make it do something it was not intended to do and best of all not break backwards compatibility. Pretty damn nice. Best of all developers like to develop, we all like a challenge so it makes you feel good on a personal level.

Design well, code well, comment well, peer review well, unit test everything and regardless of workload just occasionally get that WOW idea in there and see how your team is really going, wouldn't it be cool if you knew everything was functioning really well :).

In other great news for us today our C++ implementations of SPEP are now functioning really well, Apache 2.0 is all but done and we'll be able to follow up our support for 1.3, 2.2 and hopefully IIS relatively quickly now. Apache 2.0 and Google Apps integration along with a number of bug fixes and improvements is making Beta 1 currently scheduled for late August look pretty nice, thats right no more Alpha, exciting times....

Time to get back to the work we're doing on our tools, I can't wait to show them off some in the near future.

Posted at 04:25AM Aug 09, 2007 in category Development  | 

| | | |

Dependencies, releases and my great team

So can I first up state for the record, I think we have some of the best people in the business working on the ESOE and other intient projects, Shaun, Andre, Paul your skills are outstanding you should be very proud of what you've all helped to build. Better still they managed to do this with me apparently at the helm, thats got to be worth extra bonus points :).

So ESOE Alpha 2 is finally out the door. We took an extra two weeks to speed up our release process now so that in future things are much more automated, some small pain and hold up now was worth the outcomes.

Alpha 2 brings a lot of new stuff to the table, you can read the release announcement here. The most exciting stuff and the biggest changes are actually only for developers, a release primarily targeted at developers... whats going on!. Its simple, we want to build a big strong open source community, by making the entry to development as easy as possible we hope that will happen a lot quicker. Developers we WANT you to HELP us with what we consider to be piece of software that will change the way authentication, access control and federation is done. Contact the development group to sign up, some of you already have and we welcome you. Of course if you want some details you can always email me directly

So what do I like the most in this release. Its a simple single word. IVY. We've moved the dependency management process entirely to Ivy, why not Maven 2 you may ask, thats a discussion for a different day, but Ivy is a godsend. Intient has even started hosting an Ivy repository which we'll open up for folks to use, of course if your doing ESOE development your able to use it now. We'll setup a request process in a few weeks time to get stuff added up there.

So with Ivy I can open up my eclipse development environment click an ant task and all my dependencies are downloaded from the web as well as the dependencies of the dependencies and so on. Better still if I want to overwrite something with a local version (lets say we have a local test build) it will take priority and flow around my system as if by magic without breaking the other guys stuff. It's also helping us with our continuous integration efforts. A new release of JAXB comes out for example, we can throw it up onto our server and on the next run of the CI server know if its going to cause us any problems should a client need to upgrade for some reason before we support it officially.

Our releases are now all automated as well, we may do some continued fine tuning in that department but again Ant combined with Ivy makes rolling out our releases very clean now, I can build an entire ESOE release (including SPEP) in about 15 minutes now. That was about a day previously to get all that together. Ivy also gives us very nice reporting so clients can easily see what binary versions of jars we have shipped them, so if you wish to manage jars with say jpackage that becomes a hell of a lot easier.

The wiki has been overhauled and now looks very slick with some documentation additions as well. ESOE Manager is currently getting the treatment behind closed doors. Right now to be perfectly blunt the support for editing policies sucks, no one wants to deal in raw XML, not even a code freak like me :). The new version of this stuff based on the designs we currently have will radically enhance policy management. Look out for some other LXACML policy additions as well, the PDP is about to get even more powerful then it already is.

In other project news Irukandji continues to come along at a cracking pace, I am pretty impressed with what it can do today. What it will be able to do when some slick web interfaces are added over the top will be really powerful. Stay tuned.

Posted at 06:11AM Jul 05, 2007 in category Development  | 

| | | |

XSD, Schema to C++ bindings generator

One of the things I get to do day to day which I really enjoy is work with some really innovative technologies and if I am really lucky with some companies that really get and support the open source and open standards arenas as much as we do.

One of the tools I have had the pleasure of working with recently is XSD from code synthesis. XSD has both commercial and GPL licenses available which should allow it to fit nicely with any project you may be undertaking.

XSD takes in any well formed schema file and generates C++ bindings, allowing you to work with unmarshalled XML documents in a much more convenient format then directly manipulating DOM using Xerces. It offers two modes of use:
* Tree - Represents the information stored in XML instance documents as a tree-like, in-memory data structure.
* Parser - A new, SAX-like mapping which represents the data stored in XML as a hierarchy of vocabulary-specific parsing events.

I have given XSD quite a thrashing integrating the latest versions of Xerces C++ and XML Security C++ with the XSD tree mode and coming up with a really nice all in one package that allows our developers to consume secure, trusted XML documents, in C++, in next to no time. It has stood up to pretty much every challenge I was able to throw at it, the flexibility it affords you is quite amazing. I've recently done similar work with JAXB and likewise recommend it highly, the two make for a good mix if your doing cross language XML processing.

You'll be able to see all of this in full action for yourself in around a month from now, in both the C++ and Java formats. Until then if your working with C++ and XML I really recommend you jump over to code synthesis give XSD a try and then when you see how great it is get yourself a support contract :) .

Posted at 07:48AM Feb 09, 2007 in category Development  | 

| | | |

Axis 2 and Spring, a small tutorial

With Axis 2 1.1 having come out on November 13th I started today to utilize it in the project I am currently working on.

Our requirements are somewhat specialized in that we didn't want to do your typical deployment of Axis with fancy WSDL descriptors, instead we wanted to use it to simply wrap our already generated XML in it for transport to remote nodes. It occurs to me that from looking at the various pieces of documentation available that this is something which takes a while to pickup for new comers so I have decided to document my procedure here.

Firstly the web descriptor, ensure the following is part of your web.xml file:

<!-- Instantiate spring loader listener for servlet 2.4 compliant containers -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet-mapping>
<servlet-name>axis2</servlet-name>
<url-pattern>/axis2/*</url-pattern>
</servlet-mapping>

Next in your applicationContext.xml file define spring beans as you would normally expect to, our example bean to undertake our soap logic looks like this:

<!-- Define the bean we would like to have invoked by Axis for SOAP calls -->
<bean name="myAxisSoapBean"
class="com.intient.MyLogicImpl">
<constructor-arg index="0" ref="myReferencedBean" />
</bean>

NB: Any spring injection you would like to carry out here can be undertaken as normal.

Now create a file called services.xml, it is consumed by Axis 2 to define your service endpoints:

<service name="rawsoap">
<description>
Raw XML Soap Query/Response
</description>

<parameter name="ServiceObjectSupplier" locked="false">org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier</parameter>
<parameter name="SpringBeanName" locked="false">myAxisSoapBean</parameter>
<operation name="queryXML">
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
</service>

Some important points to note here:
* ServiceObjectSupplier, defines how Axis2 gets references of the beans it should use, in our case we get it from the Servlet Context because we have access to that, for other options the official Axis 2 guide has more details
* SpringBeanName, the name of the bean we defined earlier in our applicationContext.xml file for use with Axis.
* The operation queryXML, in this case we only have one defined operation block, there is no reason why you can't have multiple operations if required (in fact we do but I am keeping it simple here)

Now we need to define our logic class com.intient.MyLogicImpl

public class MyLogicImpl
{
LogicBean logicBean;

return payload;
}
catch (Exception e)
{
// Create a SOAP fault response here....
}
}
}

You can see we have a function by the same name as our operation endpoint queryXML, it takes in a type of OMElement which is defined as part of the Axiom project (Axis Object Model) and returns the same type. In this case we decided that working with a string representation of the RAW XML from the soap body would be nice for us and converted appropriately so the string can be passed to our down stream logic code, probably provided by the injected reference to LogicBean. For completeness the function returns this string back to an OMElement object to be returned to Axis.

Once all this is completed your ready to deploy, the logic class above should live within a jar for your application and be stored at the usual WEB-INF/lib. The services.xml file should be stored in the META-INF directory of a aar file with the same name as your service, in our case rawsoap.aar, this is exactly the same as a jar file and can be created with the ANT jar task. Finally you should create a special directory called services under WEB-INF and store your aar file there.

Once everything is deployed you can send messages to the interface by accessing (assuming tomcat):
http://localhost:8080/axis2/services/rawsoap/queryXML

To get you started here is some of my JUnit 4 test case to access the above:

public class AttributeAuthorityTest
{

// Process your result!
}
}
}

Posted at 11:53PM Dec 03, 2006 in category Development  | 

| | | |