Is Todd's example a good use case for WSDL2.0?
To manage systems we need to impose some sort of uniform WSDL interface
that all our services inherit (WSDL2.0 does this well
as far as I know). Something akin to:
Start - bit of strange on this one but you get the idea ...
Stop
Suspend
Resume
Configure(XML configDoc)
These represent the lifecycle methods on the service that an operation
process might wish to use in conjunction with a host of
other things (e.g. VmWare, Provisioning systems such as SPSS, and so
on).
We (me and client) are trying to build our SOA exactly this way as well
as using WS-CDL (of course) as a system description
that can be used as part of our governance layer (behavioral governance
in this case).
The ops BP needs to be thought of as highly distributed - provisioning
can be central but active management cannot, it needs to
be at least as distributed as that that is managed. I think you will
find some interesting stuff at Enigmatec (www.enigmatec.com)
who have been doing this sort of thing for sometime. They also use
VmWare's Web Service interface to liaise with VmWare
and start/stop/suspend and resume as needed.
Got a cool write up in a financial service waters publication at the
end of last year.
Cheers
Steve T
On 24 Jan 2006, at 20:32, Gervas Douglas wrote:
> Thanks, Todd - interesting example. This reminds me of another example
> that I came across when doing a bit of consultancy for IntaMission a
> couple of years ago where they had a case study involving a decoupled
> client-server system based on Jini/JavaSpaces. The strength of the
> system was based on factors like automatic scalability (within
> hardware/comms infrastructural physical constraints), allowance for
> module failure etc. etc. The application involved farming out
> processor-intensive calculations on a flat, client-server model for a
> financial services company. Can one treat this as a flexible,
> adaptable candidate for a SOA approach and if so what is the most
> appropriate technology, J/JS or otherwise?
>
> There are many other applications such as process-control, real-time
> military, telecoms etc. which are not seen as being in the mainstream
> commercial sphere. My curiosity is to find where these low-profile
> system requirements/apps could benefit from a flexible, loosely
> coupled SOA structure. If the server response is time-critical,
> tight-coupling is probably of the essence. Is there a SOA format
> which could be applicable or is the requirement for loose-coupling so
> fundamental to SOA as to exclude time-critical responses? You might
> rightly question the relevance of these ramblings: I would simply like
> to use them as examples of useful applications to test the true
> relevance of the criteria that we deem to be indispensable to the
> definition of a SOA.
>
> It is easy to forget that ICT systems are used for applications more
> interesting than mundane commercial transactions. If we look at other
> uses for tin/ironware it might help us to test useful architectural
> constraints and definitions. Let us not be constrained by others'
> imagination!
>
> Gervas
>
> --- In [email protected], Todd Biske
> <[EMAIL PROTECTED]> wrote:
> >
> > I don't know if this what you're looking for, but coming from the
> > engineering/infrastructure side of the house at my current
> employer,
> > one of the first possible cases I presented was the systems
> > management space. The standards bodies are in line with this idea
> > with both the MUWS component of WSDM and WS-Management.
> >
> > The scenario I always used was that of an application server farm
> > hosting a service. A routing device in front of the farm collects
> > response times. When the response time exceeds a threshold, the
> > device publishes an event. A operational management process is
> > kicked off in the BPM system in response to the event. The process
> > fires off one or more service invocations to provision a new
> > application server instance and deploy the service that is
> exceeding
> > the response time threshold. When the application server comes up
> > and the service is deployed, the application server fires an
> event.
> > The orchestrated management process is in a state listening for the
> > event. After it receives it, it issues an administrative service
> > invocation to the routing device to update its routing table.
> >
> > It's a nice picture, but unfortunately, this scenario isn't
> something
> > that can be done today (at least out of the box) as very few
> products
> > have an administrative/operational interface exposed as web
> > services. Personally, I wish more vendors would think about
> > operational integration as well as functional integration from day
> > one, but unfortunately, state of the art management capabilities
> does
> > not drive sales until many releases down the road.
> >
> > -tb
> >
> >
> > On Jan 23, 2006, at 5:15 PM, Gervas Douglas wrote:
> >
> > > Most of the discussions that take place on SOA seem to be based
> on an
> > > implicit assumption that SOA only applies to "business"
> applications,
> > > i.e. that it fits into or belongs solely in the realm of
> Enterprise
> > > Application Architecture. I put "business" in inverted commas in
> the
> > > sense that in ICT it is used other than in a mere commercial
> sense,
> > > but more generally to refer to human end-user application needs.
> > >
> > > Should SOA be necessarily restricted to this domain if one
> envisages
> > > it essentially as an architecture for designing systems on a flat
> > > peer-to-peer basis, i.e. a client-server architecture with no
> fixed
> > > hierarchy and where an entity could be both client and server?
> This
> > > may sound a little vague conceptually, but have any of you come
> across
> > > examples of a SOA or a useful opportunity for implementing a SOA
> below
> > > the application layer?
> > >
> > > Gervas
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Service-oriented architecture
> Computer monitoring software
> Free computer monitoring software
>
> YAHOO! GROUPS LINKS
>
> ▪ Visit your group "service-orientated-architecture" on the web.
>
> ▪ To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
