|
 Part
II of IV
Read Part I
Waiting for the 2nd
Cross-Over
Sleepless in Seattle
Being Objective About SOA
SOA:
Until Death Us Do Part
Caveat
Emptor - BIG Time
CICS & IBM Adapters Come in
Many Flavors
Read the original,
April 20, 2005
"Mega Consolidation in Host Access & Web-to-Host Article"
Read
about SEAGULL's acquisition of Oak
Grove on June 13th, 2005
by
Anura Guruge
editor at
large, IT In-Depth
Waiting for the 2nd Cross-Over
The statement: “… revenues were disappointing
due to a revenue gap between our declining traditional business
revenue and the anticipated revenue from sales of our new solution
…”, on May 16th, by Gideon Hollander, the CEO of Jacada (who by now
knows this market rather intimately) confirms what many have known
for quite a while about this fickle ‘legacy capital’ market.
 The
‘gap’, or the ‘cross-over/cut-over’ as many others think of it is
that transition from legacy-orientation to EAI shown in our
technology diagram here.
[See
Part I for a bigger version].
What is, however, disquieting is that this is
the 2nd time, in the last 5 years, that many of the vendors in this
space have resorted to this excuse – though the ‘traditional
business’ that they are referring to has been the same!
In other words, there has already been one
hoped for cross-over from traditional-to-new that never came to
pass. The original cross-over was supposed to be with Web-to-host,
this term, as shown in our technology diagram, encompassing
three distinct methodologies; i.e. Java/ActiveX thin client access,
host publishing and host integration.
The cross-over to Web-to-host was supposed to
have happened around 2002, with Incorrect Data Corporation
speculating that this market would be worth that mythical $1B at
that point. The traditional business which
would have been left
behind at that juncture was to have
 been fat client-based host
access.
But Web-to-host, was derailed if not hijacked
by 9/11.
So now, five years later, the traditional
business is still much the same as it was in 2000, though “SOA”,
rather than Web-to-host per se, has now come to represent the hoped
for future for this industry.
Sleepless in
Seattle
What everybody wants to know is when the new
cross-over to EAI will start to occur. I, for one, don’t think it
will be this year. There is a very simple reason for that. We are
still looking, desperately, for the killer apps. to make this a
reality. No wonder there is so much sleep being lost in Seattle.
It is kind of “Sleepless in Seattle – Pinning for EIA”. The yet
again placid U.S. economy, spooked by the specter of inflation and
chastened by rising interest rates, is not helping matters. The
growth in corporate portals alone, despite their increasing
sophistication, is no longer sufficient to denote an upward spike in
market demand. We really do need a whole new genre of SOA-based
applications to adequately fulfill today’s pent up hopes for EAI –
that exploits legacy capital.
[A valuable aside: Though rarely talked about,
particularly in the context of host applications, grid computing,
right now is the killer application for SOA-based solutions. But it
is kind of funny in a very ironic way. The host access/Web-to-cost
community, on both the supply and demand side, somehow seems to
think that grid computing is not their concern. What a pity. One
of these days somebody in the vendor community will finally see the
light. There is as much potential in grid computing as there is in
composite applications.]
Being Objective
About SOA
Though the
acronym, much abused, is new, the concepts and principles of SOA
were already in place in 1997 when we first started to talk about
host integration. Yes, we
didn’t have XML Web services till 2000,
but as the true technocrats in this field know this notion that SOA
is contingent on Web services is but an urban legend. Other than
when dealing with 3rd party supplied functionality, it is usually
easier and more efficient to access behind-the-firewall “services”
[i.e. business logic from other applications] using EJBs, .NET
assemblies or even CORBA (as
IONA might
like to point out) than XML Web services. To this end, as shown in
the diagram to the
 right here, it is also worth noting that many of
today’s ‘integrators’ that enable you to create business logic Web
services do so using EJB or .NET object technology.
So the first thing we have to factor in is
that host integration is a bona fide SOA conformant methodology, and
that, moreover, it is a subset of EAI. Thus there are no borders or
barriers between host integration and EAI.
This means that host app. related objects or
Web services created with conventional host integration products
[e.g. Jacada Integrator] could be used, seamlessly, in an EAI
project involving other objects/services culled from contemporary
applications [say Siebel Sales 7.7 or SAP R/3]. Thus in practice
you can have host app. objects/services created say using Jacada
Integrator being used within the same composite application as
objects/services created using iWay – even though it is WRQ, rather
than Jacada, that claims to have a relationship with iWay. The
point here is that objects/services are vendor agonistic. But there
is a BIG gotcha. And it is this gotcha that will in the end
separate the wheat from the chaff when it comes to EAI players.
SOA: Until Death Us Do Part
Though it is pivotal to the whole notion of
SOA, I find in my discussions with folks (as well as at a
presentation in Boston last October to a large group of senior
software developers) that many don’t fully appreciate that SOA is a
‘run-time execution’ model. Simply put SOA is not a source-code
cut-and-paste scheme. It is all about providing software
functionality in the form of remotely invoked procedures. And that
is the crux. In reality this is in no way new, or specific to SOA.
Host integration and XML Web services also rely, totally, on
run-time execution-based remote procedure execution.
With run-time execution, when a composite
application is being executed, you also need to:
1.
Be able to
invoke and execute ALL
the ‘donor’
applications providing the services
2. Have ALL the integrator products used to
create the services active in order to gain the
necessary access/navigation into the donor
applications
So lets say you use WRQ’s Verastream to create
a bunch of services from mainframe CICS and IMS applications. You
then use these services, in Web services or object form, within a
new composite application. To give it relevance lets say it is a
portal application developed to be used with the Plumtree portal
server – Plumtree being a WRQ partner. So we now get around to
deploying and running this new portal-related composite
application. In order for the composite application to be able to
access the CICS and IMS functionality:
1.
the CICS and IMS applications need to still
be running on a mainframe
2.
Verastream needs to be running to act as a
run-time broker between the new composite application
and the legacy CICS/IMS applications
Though this is so obvious when you stop and
think about it, so many people just don’t get it. Even more scary,
there are so many people out there promoting and selling SOA-based
solutions that don’t fully understand the run-time ramifications.
As I had said in my May 12th blog get these people to draw you
pictures of what they are proposing, especially what it will look
like when the actual SOA-based composite application is executing.
Caveat Emptor – BIG Time
The run-time execution
model of SOA means that you end-up in a inextricable, long-term
relationship with the vendor whose technology is used to create the
objects/services you plan to use in the future. Think about that –
very carefully! Not only are you, yet again, extending the life of
your legacy applications but you are also going to now latch-on an
‘integrator’ onto these applications. Given enough time you will
end up thinking about this ‘integrator’ as your ‘legacy’ integrator
(irrespective of the donor applications being accessed) – because
this integrator would have been around with you for a while.
This is why the recent vendor consolidation is
important. For SOA you better choose a vendor that has the gumption
to be around, in viable form, for another decade or two! Otherwise
all this talk about ROI will be but smoke. This is in no way akin
to migrating from fat-clients from Attachmate to thin-clients from
Zephyr. If you decide to change your integrator vendor, you will
need a new set of objects/services and moreover have to redo your
composite application, along with all of the requisite testing and
validation. A few years ago Jacada used to have a reputation for
‘shelf-ware’. People would buy the Jacada Interface Server, play
with it for awhile and then end up using a simpler host publishing
offering from another vendor. With SOA/composite applications, you
really don’t want to change horses in mid-stream. It could be
hazardous to your career.
So the first
thing is that you may want to just deal with the new super
heavyweights and the likes of
IBM
and
IONA. It is also important to checkout their credentials when it
come to host integration experience, mainframe expertise and the
track-record of their adapters.
Though host integration has been possible
since around 1997/1998, there are still some vendors out there that
have little or no host integration experience. All they have been
involved in, to-date, has been host publishing. So check that out.
And then you still have to reconcile the crucial 3 “S”s: speed,
scalability and security.
CICS & IMS Adapters Come in Many
Flavors
The run-time execution model also dictates
that the performance, stability and security of your new composite
application is contingent on the integration solution you are using
to interface with the donor applications. So you have to make sure
that the integration server is not a weak link in your chain. There
is little point having mission-critical, backend donor applications
running on a ‘zero-downtime’ zSeries mainframe if you have a flaky
integration server that is not only unreliable but cannot deliver
the scalability required.
This is of particular importance if your new
composite application is going to be heavily dependent on mainframe
CICS/IMS transactions. There is a lot of variation in the
implementation of today’s CICS/IMS adapters – starting with which
APIs they use. Don’t just rely on data sheets and promises. Insist
on talking to other customers using these adapters. Grill them on
performance. If possible try the adapters, in-house, on an
evaluation basis, against your own applications before you make any
commitments. This is one area you have to be very careful.
So the bottom line here is that the run-time
execution model dictates that you will have to live with the
consequences of decisions you make toady, vis-à-vis SOA, for a long
time to come. So it is best to spend some time and effort making
sure that you are making the right long term decision.
More in Part III towards the end of June.
|
