Implementation of ChemAxon in a SOA environmentPresentation
September 2010
Product group
Desktop applications
This talk covers GSK R&D IT’s current progress in leveraging Service Oriented Architecture (SOA) against the problems posed by a mixed technology environment. During 2009 and 2010 IT has undergone a push to simplify the architecture, technologies and vendors used in order to reduce the cost of on-going support and maintenance of our vast application portfolio. One solution has been to consolidate the number of vendors used and to standardise on a suite of webservices that can provide the required functionality. ChemAxon was chosen to provide a number of the generic chemistry functions used by Discovery IT, ranging from structural searching to 2D rendering. We will begin by discussing how the ChemAxon toolkit and cartridge has been integrated into the enterprise environment and detail the effort required to migrate from some existing vendors to ChemAxon. We will also discuss the advantage SOA has played in this migration with respect to cost and client applications. Finally, we will show details of how the ChemAxon product has evolved in our systems and led to gains in consistency and supportability.
Subtitle for hearing impaired (hide)
0:03
Good morning! My name is Brett Hiemenz
0:06
and I’m a solutions’ delivery at GSK
0:08
Jonathan Lee couldn’t have produced a better lead up to mine
0:12
we have a very complimentary
0:15
presentation to follow
0:18
and
0:19
given earlier this year by Shane Weaver so I’ll be his stunt double for today
0:23
on implementation of ChemAxon in the SOA environment
0:28
or service oriented architecture environment
0:34
so this story goes back a ways for us
0:38
we’ve been working for SOA for about ten years which is actually pre-dates things
0:42
like SOAP and formalization of it
0:46
and we’ve actually achieved great benefits from it
0:51
and what we found is that that we can use
0:55
service-oriented architecture to
0:57
uh… separate our applications
0:59
from the underline
1:02
toolkit which we have many
1:05
and as you see here
1:07
uh… I want to discuss
1:08
why would we do this
1:10
and how we do this
1:18
so as to why
1:20
and I think that
1:21
as I said Jonathan has sort of hinted that
1:26
in GSK we’ve got pretty much every technology under the sun represented somewhere
1:30
in the company
1:31
and just about every particular language
1:34
and this is great for diversity and great for exploring new ideas
1:39
but it’s really really difficult to support
1:42
and in
1:43
recent times we’re finding ourselves and the trend
1:48
kind of simplified
1:49
onto
1:50
particular technologies and recently we’ve kind of
1:54
gotten down to .NET, Oracle
1:56
we still have a lot of Java applications and we still use that
2:00
but we’re phasing out things like C++
2:02
Pearl, Tcl, Fortran
2:04
believe it or not
2:05
plenty of other technologies
2:09
uh… that we have in our technological museum
2:13
but when we’re standardizing these things
2:16
the idea is
2:17
to simplify both 0:02:20.129,0:02:21.829 development
2:21
environment
2:23
and the support costs
2:26
so
2:26
how do we go about doing that
2:29
we need to analyse what we have
2:32
migrate some of them to newer technologies
2:34
and of course make the hard decisions to retire some of them
2:40
as part of that process
2:41
we find that
2:42
in our technologies museum that we have alot of different vendors represented that
2:47
in many cases we don’t use that much or it does not justify its costs
2:51
so we had to look at those very hard to make smart decisions
2:55
and consolidate or just remove them all together
3:03
so I gave a presentation last fall that kind of described
3:07
our web services
3:09
and how it was
3:10
and this is actually the
3:13
top level hasn’t changed very much
3:16
we have chemistry look-ups
3:17
structure search I mean the basic capabilities translation of one format to another
3:22
calculating simple properties calculating complex properties models that kinda stuff
3:26
we kept that in place
3:28
because that allows us
3:30
to deal with the complexity of stuff
3:32
under the hood
3:33
lots of different technologies lots of toolkit cartridges
3:37
for various reasons they have been used to satisfy these
3:41
various services
3:46
and we have good reasons for having these one particular vendor might be good
3:50
doing molfile coordinates from smiles
3:53
another vendor
3:54
has a great Oracle data cartridge
3:57
another vendor might do with the smarts conversion a little more better
4:00
and of course as always we’ve got some in-house stuff that we’ve done
4:09
but, that’s hard to maintain
4:11
we found the vendor that actually
4:13
kinda checked all the boxes for us
4:17
we’ve figured ChemAxon did a lot of the stuff we needed
4:20
not trying to change the world
4:23
basically taking best of breed ideas
4:25
and the best of breed technologies
4:27
and putting it into a nice tiny package
4:30
we found out they have a nice tool kit
4:32
full-featured tool kit
4:34
a performing cartridge product
4:37
plus they had been working in a new space at least at the time we started investigating
4:41
this
4:42
it’s a desktop applications
4:44
Instant JChem and JChem for Excel
4:47
uh… as I already mentioned they’re working with
4:50
languages that would be very in line with what we’re looking at… .NET
4:53
Java
4:55
or Oracle as a technology
4:57
as well as support for formats that
5:00
we know a lot
5:01
Smiles & Molfiles
5:04
but it wasn’t just the products they’re putting together we enjoyed
5:07
and we’ve thought that is a good thing for our for company
5:10
it was their commitment to continuous improvement
5:14
very responsive to changes that we
5:16
requested or ideas that we present
5:18
or even bugs that we point out
5:20
we’ve been getting a lot of
5:22
quick response on that, it’s been very good arrangement
5:28
we also found believe it or not
5:30
some of the in-house stuff that we’ve done
5:33
actually was performed by their toolkit so we got to replace a fair bit of that as well
5:39
and of course as always it has got to perform well
5:42
and it did
5:47
so this is what we ended up with
5:50
now you’ll notice
5:51
the top didn’t change
5:53
the services are still in place
5:55
but under the hood we were able to replace
5:58
a whole host of different cartridges toolkit
6:02
in-house tools not all of them we had a couple
6:05
GSK in-house stools
6:06
that’s OK
6:08
most of them we’re able to replace with ChemAxon
6:12
I say this is to be
6:14
we’re pretty close to that now
6:19
how we did it?
6:23
it’s a tough road
6:25
we have to look very hard at the vendor usage that we have basically I analysed all the licenses
6:30
that are out there
6:31
say you really use this
6:33
do you really need this
6:35
this has been sitting on your server for years you haven’t even updated it for a long time
6:39
Is it up to date?
6:41
How many people does it serve?
6:45
when we find out that they’re not really used we’re broken
6:51
or when we find out
6:53
they’re used, we try to take some of these applications and migrate them
6:56
to service oriented architecture not directly to ChemAxon specifically
7:02
or to any technology
7:02
accepted service oriented architecture allows us
7:07
to put whatever vendor on the hood
7:09
so we moved into the services that we had place
7:13
there were competing services other people have better ideas
7:17
got the best agreed together
7:18
and retired some of the services that
7:20
didn’t quite make the cut
7:22
and finally once we had people
7:25
hitting the web service layer
7:26
we were able to
7:29
migrated the tool kit that were on the hood so we saw a whole host of them there
7:33
simplify down to the right tool kit
7:34
the clients never know the difference because they’re hitting the services directly
7:42
this is the objective that we’re looking for we wanted to minimize this business impact cause it could
7:46
be very impactful
7:48
everyone’s got their favourite tool
7:51
the idea was
7:52
once we get them into the service oriented architecture
7:56
when we change
7:58
to a different tool kit
7:59
is not as important as the fact that
8:01
we can do it
8:05
furthermore we found out that we can move or pull out of the applications for possible
8:10
the actual business rules that are better in that application
8:14
if you have a dozen applications each one trying to implement the same business
8:18
rules someone’s going to make a mistake one’s going to get out of synch with the others
8:22
ones going to be older
8:23
you move that its business rules back into the service
8:27
give a central place for supporting that
8:28
a central place to make those changes
8:31
and because you have the services as the shield between tool kit and the application
8:36
we can ensure that the downtime is minimized or not at all
8:43
and finally we looked at
8:45
the total cost of ownership here
8:47
how much does this cost over time
8:52
now we analysed
8:54
taking 42 applications and migrating them to the ChemAxon tool kit
8:59
just each every applicant each one of these applications
9:03
we thought
9:04
okay that was compared against if these applications were using a service oriented architecture
9:10
how much would that cost
9:11
to migrate that over to ChemAxon
9:14
and what you see
9:15
is we had one place to support one place to modify the business rules one place to test
9:20
by having them and their services
9:24
versus
9:25
doing it for each and every application
9:28
migrating each and every application over to support
9:31
and having
9:31
basically passing on this business rules to the support people
9:36
this turned out to be quite an expensive preposition
9:39
and we estimated that after about ten years
9:41
it was going to cost over a 100 percent more
9:49
so
9:50
once we have a service-oriented architecture in place
9:54
they gave us
9:55
the freedom to do some pretty cool things
9:58
and and that is we can actually find a place in which actually take a common problem
10:04
solve it in the service
10:06
and then make it available
10:08
to a hosted applications
10:10
rather than solving each and every application
10:13
in this case
10:14
it’s just rendering structures
10:16
often times on a web page any common web page who want to be able to render structure based
10:20
on say Smiles
10:23
you solve the problem once get a good quality rendering
10:27
make it very easy to integrate that
10:31
you’re in good shape
10:32
you don’t have to figure out that problem for each and every application
10:37
so we used our service-oriented architecture
10:40
below balance service we had in place
10:43
all the common elements
10:45
we end up with although it might be a little hard to read
10:48
this one tag
10:50
that allows you to
10:51
render a structure a very simple HTML tag you can embed in your page
11:00
so take that the next step
11:02
try to do something that is generally hard to do or can be hard to do if you don’t
11:05
have the right tools
11:07
dynamic alignment
11:09
before we’re using HTML, JAVA Script
11:12
a bunch of AJAX stuff that
11:14
really took a lot of time
11:16
and was custom code
11:18
basically just to align ten structures took 26 seconds
11:21
hundred structures
11:22
200 seconds no one’s going to wait for that
11:26
but with this new thing in place and ChemAxon’s built-in ability to do alignment
11:30
all we had to do
11:34
is add an argument to the structure picture service
11:39
and basically let the server-side take care of the business
11:42
we ended up with the structure aligned as we need it
11:46
and it was a much better performing result
11:49
went down to seven seconds
11:51
for a hundred structures
11:53
which we consider to be pretty good
12:00
so that’s where we are today
12:02
we pretty much standardized most of our stuff on to ChemAxon
12:08
toolkit
12:09
but the reason why was to simplify both in terms of support and cost
12:14
and
12:15
the how this tricky i mean you do have to commit to service-oriented architecture you have
12:20
to
12:20
sometimes refractor existing applications to get there
12:24
and
12:26
it’s not always easy but we’ve done this this particular project for about
12:30
a year and the half to two years
12:32
and i think we’re starting to reap the benefits
12:36
and we feel that going forward this will be much more supportable
12:39
much more testable
12:41
and much more robust
12:43
now
12:45
we have the service oriented architecture in place we’re looking for more closely at desktop
12:50
applications like instant JChem
12:51
and JChem for Excel
12:52
i think we have a follow-up discussion on that our presentation on that later
12:57
thank you your time
13:03
(Spectators Applauses…)
13:08
OK… do we have some questions?
13:10
Pat?
13:15
I’m just wondering how you handle this on a global basis
13:20
so are you
13:21
deploying the services out individual sites or are you just
13:25
hitting one
13:27
central place for service oriented architecture globally?
13:31
Good question!!! currently we have a central place for that and there have been some talks of having mirrored services
13:36
but right now we have a central place for that so we do sometimes incur
13:42
some issues with legacy
13:44
but
13:45
like i said we’re there’s some talks about synchronizing in the future date
13:52
I’m Joerg Schmiedle, Roche
13:55
Are you planning to use Enterprise Service PLUS or are you using Enterprise Service PLUS
14:00
that is in the plan
14:02
we do not have that in place as yet
14:05
but that is one of the reasons that we are going with service-oriented architecture is
14:09
to moving into that space
14:12
the details are
14:13
being worked out though.