> Archive > Issue LVIII, January 2012
Download Issue
Download Full Service Technology Magazine PDF

The Service-Aware Interoperability Framework:
Making Cross-Boundary Interoperability a First-Class Citizen

Charles N. Mead

Charles N. Mead

So, first let's talk about why interoperability is hard. I'm sure everyone listening to this or at least most people listening to this have had experience with integrating systems across boundaries. And as the kind of interoperability you're trying to achieve becomes increasingly complicated, the difficulty of making the interoperability actually happen turns out to be increasingly difficult. I think if you had to summarize at a high level "why is interoperability hard?" these two bullets at least do a reasonably good job of pointing out some of the major issues. As you cross different boundaries, there are different levels of understanding and different kinds of things that need to be understood – and certainly some types of interoperability are harder than others and that has to do with whether you want computable semantics or if you just want syntax. Secondly you must understand the breadth of the deployment context – exactly what are you interoperating across. In the end, we're talking about managing complexity. And I think if you look at a particular interoperability scenario and you ask "why did this interoperability scenario fail" – again not every scenario fails for the same reason – there usually is at least one or two of these three points. The first point – the fact that there are no common technology standards – is probably the least important actually, while the next two are more important (i.e. that implicit assumptions that occur at multiple levels of the discretion don't get made explicit until it gets out on the wire at runtime and of course everything's made explicit at runtime). And then also, there are not a lot of formals ways to coordinate communication and explicitness between levels of stakeholders because of course stakeholders have very very different views, all the way from high level business use down to developer or tester mechanics. The view that I use, and have used for quite some time, about how to describe a complex system – because I think interoperability by definition involves a complex system or defines a complex system – is actually a view that I got from a book from a long time ago...

Runtime Governance Challenges & Concerns:
A Practical Approach to Throttling

Roger Stoffers

Roger Stoffers

Let's start by defining what throttling actually is from several points of view and then illustrate how these "zero-build" conclusions can be way off and can be very costly to resolve. For vendors, it's high-value sales. Vendors will spend lots of time persuading the customer that this (service) agent is the solution to their problems with system load and capacity. The zero-build argument is close to a guarantee that customers will spend more money on something that saves build effort. In the eyes of customers, throttling is a way to manage the amount of traffic to a service or a back end system, without build effort. Customers pay significant amounts of money to use throttling agents. The expectation is often that they manage the amount of throughput by restricting the access to a service to not exceed a certain metric (i.e. a specific number of calls per second or per minute, depending on load). These are tangible metrics which can be discussed. Customers can easily assume that the load on the system is reduced automatically by the throttling agent, without thinking about consequences of that statement. It sounds like magic. If we believe the vendors, it is magic. In the eyes of designers and architects this is a way of managing runtime characteristics of a service-based on a service-oriented solution. For a consumer program this could mean that the message has to wait until the measured load does not exceed the threshold anymore. To a throttling agent itself this usually means that the service call cannot be executed, because allowing execution would violate the expected threshold even more. Depending on the business goal and the context in which the service activity is requested by a consumer, the severity of what happens if messages are throttled is different in various scenarios. What should happen to a service call exceeding the threshold? This actually depends on the purpose of the service and the context in which this service call is executed...

Agile E-Service Composition

Pouya Fatehi, Seyyed Mohsen Hashemi

Pouya Fatehi Seyyed Mohsen Hashemi

Nowadays, application of service-oriented architecture are increasing rapidly; especially since the introduction of distributed electronic services on the web. SOA software has a modular manner and works as a collaboration of independent software components. As a result, the e-service approach is sufficient for software with independent components, each of which may be developed by a different company. Such software components and their cooperation form a composite service. Agile methodologies are the best candidate for developing small software components. Composite services and their building blocks are small pieces of software, making agile methodology a perfect fit for their development. In this paper, we introduce an agile method for service composition, inspired by agile patterns and practices. Therefore, across the agile manifesto, we can develop low cost, high quality composite services quickly using this method. A Service is a discoverable software resource which has an advertised service description. The service description is available in a repository, called a registry that can be searched by a potential consumer of the service. Given the service description, a service consumer can bind to and use the service. In the real world, e-services are represented by web services which have different types (grid services, distributed services, etc). RUP and similar guides, like the PMBOK, Software Engineering Institute's (SEI's) Capability Maturity Model Integrated (CMMI), or the UK's IT Infrastructure Library (ITIL) standards impose unnecessary process overhead for smaller projects. In contrast agile methodologies allow for fast and tight increments or phases, they cut down overhead and they ensure a close relationship between the developer and customer. Comparing agile methodologies with other methodologies, demonstrates that agile methodologies are more useful for developing services. So in this paper we are trying to represent a new agile methodology for services, especially for composed services...

2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006