ServiceTechMag.com > Archive > Issue LXXVIII, November 2013

Download Issue
Download Full Service Technology Magazine PDF

Service Point Estimation Model for SOA Based Projects

Dinkar Gupta

Dinkar Gupta

Estimation in Service-Oriented Architecture (SOA) based projects has been a challenge for IT teams across the globe. As per "Estimating the cost, size and efforts for SOA application is a difficult task due to its diverse nature and loose coupling behavior, which results in an inaccurate estimate to measure the efforts, size and functionality of SOA applications". Service Point Estimation Technique presented in this paper is a newly developed estimation technique to calculate the size of an SOA project and derive efforts and costs for the corresponding service implementation. Based on foundations similar to the UCP & FP estimation techniques, it is a technology agnostic and generic model that can be applied in SOA projects across business solutions or product development initiatives. The basic reason for its design was simple - help IT teams answer the question "How big is this (SOA project) and how much will it cost to implement?" Given that the notion of service includes many more aspects that just functional logic served by that service, the estimation model considers all 3 aspects of service design – functional complexity, Quality of Service (QoS) expectations and service development environment; while calculating the size of Service at granularity of both service operations and service interface contracts. In past we have clearly felt the absence of a scientific method to estimate SOA projects in terms of the core unit of these projects – the services. This model is an attempt to fill that gap. The entire portfolio of service development, large scale service migrations and technology transformation programs are expected to get benefitted from the model because SOA is the norm in majority of systems development projects across enterprises. As is well known, SOA is founded on the notion of Services and each service is the characterized by 3 distinct layers – 1) Policies & Service level agreements (SLAs), 2) Service Interface and 3) Service Implementation, with the first two forming what is generally referred as Service Contract. Every service supports the business/functional capability assigned to it through a set of well-defined operations that are offered on the interface of the service under the specified SLAs (often called QoS Parameters)...


Modernizing Data Access in the Enterprise

Andrzej Parkitny

Andrzej Parkitny

Within a large organization, we are faced with the challenge of managing a large amount of data and providing read/write access to that data to multiple applications in the enterprise. In addition to this, some of the data sources may be exposed through service interfaces while other data sources have applications that are accessed directly. As good IT integrators, we should avoid tight coupling whenever possible, and if and when we identify tight coupling, we should recommend alternatives to the stakeholders involved that own the data and access that data. We should consider a number of architectural patterns and approaches which include, but are not limited to, SOAP Patterns (Legacy Wrapper, Service Façade, etc.), RESTful Service Patterns (Reusable Contract, Lightweight Endpoint, Entity Linking, etc.), and most importantly from an implementation perspective the utilization of data grid technologies (such as ORACLE Coherence, IBM WebSphere eXtreme Scale, and JBoss Infinispan. This article explores how the utilization of data grid technologies and the application of Service Oriented Architecture patterns can help IT integrators address the need of providing data resilience and availability in the enterprise. As software integrators, we are faced with many challenges in order to help fulfill the needs of our systems stakeholders. A common challenge in today's enterprise is the management and provisioning of data en-masse to front end applications. In order to ensure that our systems our future proof and intrinsically interoperable, we should strongly consider using Service Oriented Architecture and adhere to the principles that are central to SOA. Depending on the requirements from our business stakeholders, we may choose to expose services that are SOAP-based services or RESTful services. However, we should also consider what systems and data stores we wish to expose and how we choose to expose them. Traditionally, organizations have persisted their operational data on database technologies that implemented highly normalized entity relationship (ER) schemas. Examples of database technologies are ORACLE Database, IBM DB2, Sybase Database, and mySQL. For organizations that have a relatively small set of data to manage, a relational database is sufficient. However, as a data set that an organization maintains grows, scalability becomes a concern. Architectural decisions regarding database...


Event-Driven SOA

Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmiedel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg

Jürgen Kress Berthold Maier Hajo Normann
Danilo Schmiedel Guido Schmutz Bernd Trops Clemens Utschig-Utschig Torsten Winterberg

If we consider real companies and their business transactions, we see that the real world is not really service-driven at all, but much more event-driven. A new customer is created in the system, a new car reservation is made, a vehicle is returned or needs to be taken to the shop. All of these "functions" can be supported by services, but often also by precisely defined process chains. However, complex business processes can rarely be automated "in one piece," as the real exceptions and dependencies of diverse business processes are highly dynamic. That brings us to the point where the concept of "event" becomes useful in our architectures. In this article, we therefore want to shine light on event-driven architectures and tie them into our current argumentation chains in SOA. Most companies now collect business-relevant information by aggregating available data. As a rule, this is in the domain of data warehouses which condense information a follow-up to preceding events. Here the focus is directly on the data and not on the process information, which is actually much more interesting. We miss out on the ability to process business information in near-realtime, which would allow the company management to react much more quickly to events as they occur. The discipline of business intelligence is developing rapidly in order to take this issue into account. In the following, we want to consider the underlying mechanisms, or the events which allow faster reactions to important changes. The term "event" generally has two meanings. On one hand it denotes a perceptible occurrence, and on the other, its representation in a computer system. The latter is also called an "event object." The term itself is therefore ambiguous. What interests us is the "business event," namely the status change in a company. What does that mean exactly? As shown in Figure 1, an event is a type of "thing which happens," which, however, for us has no meaning as long as we are not informed of this in the form of a representation in our IT systems. The occurrence of an event in our view...


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