| |||
Identity Management and Enterprise Service Bus a Happy Marriage Does Not Make
The subject of identity and access management (IAM) is becoming increasingly important within organizations. Where previously IAM was linked to user lifecycle management on the basis of provisioning, there's currently a move in which many more components and focus points are gathered under the IAM flag, such as core registration, multifactor authentication, role-based access, and self-service workflows. Deployment of the enterprise service bus (ESB) is also expanding significantly. In particular, local system owners are using the ESB more frequently to send and receive messages between systems in real time. When asked whether ESB can be deployed to carry out a variety of identity management activities, like creating user accounts or changing the name or position of an employee, the conclusion almost always is that ESB appears to be an ideal mechanism for managing the various types of digital profiles or identities of a natural person on the network. For example, when an employee is entered into an HR system, a signal is sent to the ESB. In real time, the ESB then sends a message to the active directory and the user account is created. Since this action is performed in real time, in contrast to batch handling in identity management, it is ideal for commercial organizations, where, for example, users need to have their accounts created immediately. Consider the example of a web store or a provider of training courses: The ESB works in accordance with a pure model, where the linked applications are "subscribed" on the ESB and these various messages are "published." So far, ESB seems ideal for managing identities in the network; however, things work differently in practice, and there are a number of reasons why it is not ideal... Introducing the Agnostic Composition Controller Pattern
Composition Controllers are arguably the ultimate engines, moving contemporary SOA nowadays. Every aspect of complex SOA realisation, from Adaptive Case Management to Cloud Service Balancing using burst-in/burst-out, is based on implementation of this SOA Pattern. We are far from declaring this particular pattern as the main one in the entire SOA patterns catalogue, in the same way we are not placing Composability as the central principle among the other eight. Still, when it comes down to the materialisation of the core SOA promise–gaining/saving money through the reasonably effortless constant reuse of the atomic units of decoupled business logic equipped with standardised and seamlessly discoverable contract—the Composition Controller is the main and probably the only design model which can help. Task-orchestrated services as a nearly static physical implementation of service compositions (mostly for long running compositions) or Atomic Transaction Coordinators (generally for synchronous services) have been pretty much formalized in SOA over the last ten years. The most fascinating for us in terms of promoting the maximum possible level of reuse are Agnostic Composition Controllers (and sub-Controllers) as the direct realisation of the Composability principle. They are not only fascinating, but also probably the most difficult in practical implementation as we will have to employ almost all other declared SOA patterns in at least six different SOA frameworks. We tried to lay out the practical aspects of this endeavour in the recently published Applied SOA Patterns on the Oracle Platform, Packt Publishing, August 2014 (http://bit.ly/1uqK9dq). Initially, publication of this subject was planned as three.... The Importance of SOA to Cloud Computing
Increasingly, SOA and Cloud Computing are assuming more prominent roles in large organizations for the purpose of operational efficiency and cost reduction. These technologies already left behind the status of emerging technologies to consolidate as mature and proven technologies. It is evident that a growing adoption of service-oriented architectures and cloud platforms is taking place in all market segments. However, little is said, in fact, as SOA and cloud computing are related. Are SOA and Cloud Computing approaches complementary to each other, or should they be used separately? This article will clarify how these technologies are related, beyond the advantages of adopting them together. But before you consider having an IT solution that is SOA- or cloud computing-based, we should conceptualize what they mean. Cloud Computing provides an abstraction layer between computing resources and its technical implementation details, such as its servers, databases, and networks, in turn enabling computational resources to be used on demand while avoiding efforts in infrastructure management. In recent years, Cloud Computing is no longer a conceptual model and has become a model adopted by various organizations. Cloud Computing is a broad term that involves virtualization, software, platform- and infrastructure-as-a-service on demand. Currently, most large organizations still have their own IT infrastructures. However, with the various possibilities offered by cloud computing, this is no longer necessary. With the use of both hardware and software resources on a large scale, providers are able to provide all the necessary processing power at a much lower cost than could be achieved by any organization individually. Furthermore, especially in cases where the use of storage resources and processing vary, it is advisable to use Cloud Computing. This model has been defined as utility computing... Service Architecture – The Importance of Standardized Modeling – Part I
In SOA Enterprise Architecture instance definitions, it's very important to clearly define design standards regarding how the fundamental building blocks of the basic Service Architecture should be designed and implemented. These Building Blocks are: Service Contract, Message Processing Logic (mostly used in web-service related architectures), Service Component (core service logic). By grouping common design characteristics related to expected functional goals and several other factors, similar to what is done in the Service Layers design pattern [REF-1], standardized Models and sub-Models for each one are created. This enables policy-driven framework to be applied onto Enterprise Service Architecture definitions, as well as to any of its specific implementations (each particular Service Design). They are named as: Enterprise Service Contract – ESC Models, Messaging Processing Logic – MPL Models, Core Service Logic – CSL Models. The idea is to match every definition from the Service Contact Design & Service Logic Design stages [REF-2] to a defined Model for each corresponding building block, defined in the Enterprise Service Architecture. The importance given to this subject is based on the following premises: The ervice Contact Design & Service Logic Design [REF-2], which both entail making a particular Service Architecture instance, Service Development and Service Testing project stages, which pertain mostly to its implementation context, are the most related to the project's overall final productivity and quality. They also produce most of its deliverables, and therefore relate to Service Governance and Audit-related processes appliance effectiveness, effort and associated costs. In my experience as a Technical Leader of a 15-person team, for a service-oriented software factory project for a Telco company which had a very tight SLA regarding Quality and Productivity... |
SOA, Cloud Computing & Big Data Certification Workshops
To view the most current calendar of public SOA, Cloud Computing & Big Data Science Certified Professional workshops, visit www.arcitura.com/workshops
Download This Issue
About the Editor
|
||
Arcitura™ IT Certified Professionals (AITCP)
Arcitura™ IT Certified Professionals (AITCP)
Arcitura™ IT Certified Professionals (AITCP)
Arcitura™ YouTube Channel
Service Technology Magazine
The Prentice Hall Service Technology Series from Thomas Erl