Service granularity is an important consideration in SOA. Services should provide discrete functions like getFieldOne() rather than overly broad functions like GetDataElement(). REST is an architectural style using URI and HTTP that defines operations like GET, PUT, POST and DELETE. Distributed architectures introduce issues like latency from remote calls, partial failures across distributed components, and ensuring consistency with concurrency. The semantics of services is also a challenge, as tools like a hammer take on meaning based on context, environment and how they are used.
Reusing Existing Java EE Applications from SOA Suite 11gGuido Schmutz
You have a lot of existing Java EE applications. Part of these applications and their logic have a potential to be reused in an SOA. But what is the best practice for reusing such Java EE applications? This session will show different approaches available with SOA Suite 11g in the SCA assembly model as well as with the Oracle Service Bus to reuse existing Java EE artifacts.
Reusing Existing Java EE Applications from SOA Suite 11gGuido Schmutz
You have a lot of existing Java EE applications. Part of these applications and their logic have a potential to be reused in an SOA. But what is the best practice for reusing such Java EE applications? This session will show different approaches available with SOA Suite 11g in the SCA assembly model as well as with the Oracle Service Bus to reuse existing Java EE artifacts.
Layer 7: 2010 RSA Presentation on REST and Oauth SecurityCA API Management
In this presentation you'll learn why REST matters to the Enterprise, enterprise security requirements, REST security patterns, and moving beyond point-to-point.
Paul's presentation at SOA Workshop,Colombo,Sri Lanka identifies how ESBs fit into a Service Oriented Architecture, discusses when to use an ESB and when not to, looks at ESB patterns and anti-patterns, covers some simple ESB approaches and investigates how ESBs can fit into EDA.
(ATS3-GS02) Accelrys Enterprise Platform in Enterprise ArchitecturesBIOVIA
The Accelrys Enterprise Platform (AEP) provides support for scientific data integration and application delivery within an Enterprise environment. During this session, we’ll provide a primer on the Accelrys Enterprise Platform and how it fits within an existing Enterprise Platform. This will include the deployment scenarios and key integration points that are found most common (and sometimes not so common) in many organizations.
Use of SOA and Web Services Technologies for EA Migration - Lessons Learned o...Nathaniel Palmer
SOA and Web Services technologies can provide powerful tools and capabilities to effect migration towards an Enterprise Architecture (EA), but what are the challenges to such an exercise, and how can they be overcome? Based on a case study at the Department of Housing and Urban Development (HUD), the first effort in HUD to analyze and design the replacement of several legacy systems with an integrated and services-based
system, this presentation will provide a technical overview of SOA and Web Services, and lessons learned from the project. These lessons will cover methodologies and modeling artifacts that were developed for the effort, the use of BPM based on the Business Process Execution Language (BPEL) and system adapters to provide an abstraction layer for system integration, an example of how Web Services can directly support EA migration, and final considerations to pass onto similar projects.
Differentiating between web APIs, SOA, & integration…and why it mattersKim Clark
At a high level, both SOA and web APIs seem to solve the same problem – expose business function in real-time and in a reusable way. This tutorial looks at how these initiatives are different and how they align into an evolving integration architecture. It discusses how API Management differs from the integration architectures that came before it, such as SOA and EAI.
Layer 7: 2010 RSA Presentation on REST and Oauth SecurityCA API Management
In this presentation you'll learn why REST matters to the Enterprise, enterprise security requirements, REST security patterns, and moving beyond point-to-point.
Paul's presentation at SOA Workshop,Colombo,Sri Lanka identifies how ESBs fit into a Service Oriented Architecture, discusses when to use an ESB and when not to, looks at ESB patterns and anti-patterns, covers some simple ESB approaches and investigates how ESBs can fit into EDA.
(ATS3-GS02) Accelrys Enterprise Platform in Enterprise ArchitecturesBIOVIA
The Accelrys Enterprise Platform (AEP) provides support for scientific data integration and application delivery within an Enterprise environment. During this session, we’ll provide a primer on the Accelrys Enterprise Platform and how it fits within an existing Enterprise Platform. This will include the deployment scenarios and key integration points that are found most common (and sometimes not so common) in many organizations.
Use of SOA and Web Services Technologies for EA Migration - Lessons Learned o...Nathaniel Palmer
SOA and Web Services technologies can provide powerful tools and capabilities to effect migration towards an Enterprise Architecture (EA), but what are the challenges to such an exercise, and how can they be overcome? Based on a case study at the Department of Housing and Urban Development (HUD), the first effort in HUD to analyze and design the replacement of several legacy systems with an integrated and services-based
system, this presentation will provide a technical overview of SOA and Web Services, and lessons learned from the project. These lessons will cover methodologies and modeling artifacts that were developed for the effort, the use of BPM based on the Business Process Execution Language (BPEL) and system adapters to provide an abstraction layer for system integration, an example of how Web Services can directly support EA migration, and final considerations to pass onto similar projects.
Differentiating between web APIs, SOA, & integration…and why it mattersKim Clark
At a high level, both SOA and web APIs seem to solve the same problem – expose business function in real-time and in a reusable way. This tutorial looks at how these initiatives are different and how they align into an evolving integration architecture. It discusses how API Management differs from the integration architectures that came before it, such as SOA and EAI.
Welcome to Softgen Infotech
Softgen Infotech is a Bangalore based Training & Recruitment company. Softgen is the best Training & Recruitment company in Bangalore. Softgen offering various I.T courses like Testing, Data warehousing, SAP, websphere, Tibco, Java, Linux, Unix(AIX, HP-Ux and Solaris), SQL server & Oracle . We are providing excellent Class room/online trainings as per the trainee requirement. We also provide Corporate Training courses that are designed to meet the specific needs of your business and that will reduce your time in day to day work environment. Our customised training programs will fulfil your training requirements. We provide corporate trainings by efficient and well experienced trainers. We offer the most competitive and cost effective training programs
2. Service Oriented Architecture
Architecture
Service
Enterprise ready SOA stack
Services
Connectors
Containers
What are people saying ?
How much SOA
Its all in the semantics
3. Architecture
1471-2000:
“Architecture is the fundamental organization of a
system embodied in its components, their
relationships to each other, and to the
environment, and the principles guiding its design
and evolution”.
This is a good start, what does this mean for SOA?
4. In SOA solutions there are service providers—elements offering services to be used by
others and service users—elements that invoke services provided by others. These
categories are not mutually exclusive. A service provider may use other services, and a
service user may provide a service interface.
We define SOA as an architectural style where systems consist of service users and
service providers.
•An architectural style defines a vocabulary of component and connector types, and
constraints on how they can be combined [Shaw 1996].
•For SOA, the basic component types are service user and service provider. Auxiliary
component types, such as the enterprise service bus (ESB) and the directory of services, can
be used. SOA connector types include synchronous and asynchronous calls using SOAP, bare
http, and messaging infrastructure.
•Many properties can be assigned to these component and connector types, but they are
usually specific to each implementation technology
Evaluating a Service-Oriented Architecture September 2007
TECHNICAL REPORT
CMU/SEI-2007-TR-015
ESC-TR-2007-015
Software Architecture Technology Initiative
5. Capabilities Enterprise Ready = SOA + ESB
Service
A service is a network-aware unit of independent
deployment, which can deliver a set of capabilities to a
SOA
managed SLA.
Capabilities:service proxies, interfaces, orchestration, WSDL, BPEL, Directories (lookup)
Requires:standard notations and a meta-model for data.
Many alternatives here – choice will
Connector*
A connector defines a dynamic view on the overall impact overall quality attributes of the
architecture by defining a picture of run-time entities and SOA architecture:
potential interactions.
Capabilities: intelligent messaging (reliable messaging, XML SOAP –RPC, Document
ESB
content-based routing, transformation, protocol REST – Resource based
switching, protocol adaptors…), business event visibility
(event capture, feed to dashboards, link to network
Messaging – MQ Series
events…). RMI/IIOP – EJB etc
Container
A container monitors and administers the dynamic
integration of services at run-time.
Capabilities such as failover and load balancing,
Enterprise Service Bus vs. point to point,
application-level security functions (authentication, Service Fabric technology – infiniflow
authorisation, encryption / decryption, data integrity /
???
non-repudiation, digital signatures…), audit-logging and
registry functionality, centralised management and
distributed enforcement of application policies, logging,
audit, registry services etc.
*Adapted from SEI definition The Cloud is in here somewhere
6. WSDL Describes the syntax of a web service but NOT
<definitions name="HelloService"
it’s semantics
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
<portType name="Hello_PortType">
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
•Definition : HelloService
<binding name="Hello_Binding" type="tns:Hello_PortType">
<soap:binding style="rpc" •Message :
transport="http://schemas.xmlsoap.org/soap/http"/> 1.sayHelloRequest : firstName
<operation name="sayHello"> parameter
<soap:operation soapAction="sayHello"/> 2.sayHelloresponse: greeting return
<input> value
<soap:body
•Port Type: sayHello operation that consists
of a request and response service.
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"
use="encoded"/>
</input>
•Binding: Direction to use the SOAP HTTP
<output> transport protocol.
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" •Service: Service available at
namespace="urn:examples:helloservice" http://www.examples.com/SayHello/.
use="encoded"/>
</output>
•Port: Associates the binding with the URI
http://www.examples.com/SayHello/ where the
</operation>
</binding>
<service name="Hello_Service">
running service can be accessed.
<documentation>WSDL File for HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address
location="http://www.examples.com/SayHello/">
</port>
</service>
</definitions>
7. What have we lost with SOAP/XML that we have with
RMI/IIOP ???
RPC Document
RMI/IIOP
public interface BankAccount extends java.rmi.Remote
{
public void deposit(float amount) throws java.rmi.RemoteException;
public void withdraw(float amount) throws OverdrawnException,
java.rmi.RemoteException; public float getBalance() throws
java.rmi.RemoteException;
}
8. Why an Enterprise Service Bus ??
Point to Point vs. ESB
How to get effective re-use from SOA
and ESB, re-use achieved through
canonical form embedded in ESB
architecture
9. Deriving real value from SOA is not a technical problem
The Real Issues With SOA but more a journey between IT and the Business.
“That's my biggest worry about all this
“When organisations think of services as key
discussion about SOA is that I'm hearing plenty
assets in system design, the value of reusing
about the 'S' (there's quite little of 'O' going on)
these services becomes more apparent. As a
but the 'A' seems to vary from person to
result, technologies and techniques for asset
person, and that makes me worry that we're
management and governance, and
going to end up with a world where
repeatable ways to capture patterns for
interoperations is left for the reader rather than
combining assets, become much more
a world where the interoperability is built in
important. A set of workflows, referred to as
from the ground up.“
(Simon Phipps, Sun) Asset Production, Asset Identification, Asset
Management and Asset Consumption,
describe (the service lifecycle)”.
“Services are an important but insufficient (“SOA Development Using the IBM Rational Software
mechanism for the construction of systems”. Development Platform: A Practical Guide” September 2005)
(Grady Booch, IBM Fellow)
“The semantics issue (the meaning of parameters and so forth) has to be solved (domain
modeling). This is key in any business-to-business (B2B) and dynamic invocation scenario”.
(“Elements of Service-Oriented Analysis and Design”, IBM, 02 Jun 04)
“Information Management, which includes both data and content management, is an essential
building block for SOA”.
“Ultimately, without a solid and robust information management environment, SOA is limited and
presents fewer opportunities for end-to-end business integration and transformation”.
(“Information management in Service-Oriented Architecture, Part 1: Discover the role of information management in SOA”, IBM)
10. An Ideal World
"Where is the 'A' in SOA? With the emphasis
on turning every piece of software in the “A software process architecture is key to
enterprise into a collection of services, are we in understanding and interpreting the needs of
danger of replacing spaghetti code of old with just enough process”
spaghetti architecture of innumerable services ('Just Enough Process' for Web Services Delivery, Gartner,
with innumerable interdependencies?” October 2002)
(David Chappell, Sonic Software)
“Building an enterprise SOA requires an architecture for the configuration, hosting, and
management of integration components as services, an invocation framework for the routing of
messages between services, and flexibility of control over protocols, quality of service (QoS)
settings for message delivery, and security. The ESB provides that architecture. It puts the “A”
in SOA”.
“A key part of the architecture is a distributed “service container” model that can be used to host
and manage application assets and integration components as event-driven services that all
share a federated namespace for locating and accessing each other”.
(David Chappell, Sonic Software)
“SOAs don't address the challenge of ensuring that business data is delivered in a consistent and
semantically correct manner. In fact, they exacerbate the problem of maintaining consistent
definitions for business entities such as customer, product, or invoice”
(“SOA’s Achilles' Heel, Larry Allston, Vice President of products for Pantero Corporation).
11. How much SOA and how far
Loose IT coupling and strong business coupling – really desirable ??
12. Service Granularity
How granular to make a service
getFieldOne(); getFieldTwo()
vs. GetDataElement()
Representational State Transfer
URI, HTTP
GET (list) , PUT(update), POST(create), DELETE
(delete)
Note REST is an architecture NOT a protocol.
13. Issues with service and distributed architectures
Latency.
• There is a speed differential between a local (in the same process space) call
and a remote network call. This differential must be taken into account when
designing systems that will not suffer from potential performance problems.
This issue has not yet been rendered obsolete by faster networks and hardware
and remains a key design issue to be solved when designing a distributed
system. See J2EE design patterns Fast Lane Reader and Page-by-Page Iterator.
Memory Access.
• This essentially revolves around accesses to resources via pointers. Addresses
for a local space are not valid for a remote space. We can either provide a
language mechanism that hides the local/remote nature of a resource or we
treat it programmatically i.e. the programmer is aware of the difference.
• If we provide a language mechanism for abstracting out the differences then
ALL pointer usage must follow the distributed rationale. The language must not
be allowed to provide address-space relative pointers otherwise we are back to
the local/remote arguments. This tends to exclude languages such as C/C++
etc. from being able to support such a language extension.
14. Partial Failure.
• This has been described as the central reality of distributed computing see
[Waldo]. The issues boil down to the inability of some agent to adequately
identify what components have failed and reliably inform other components of
that failure. There is no global state that can be examined to determine the
nature of the failure, be that network or remote processor. To be able to
ensure a consistent state is maintained in the presence of failures distributed
applications must deal with indeterminacy, that is components must be designed
to react correctly to the various possible partial failures that can occur.
Concurrency.
• Objects involved in providing services across a network to multiple clients must
be able to handle concurrent method invocations. Thus if we strive for the one
model view all objects in our application must have adequate concurrency
semantics. There are subtle differences between multi-threaded applications
where the threading model can to some extent be controlled and a true
distributed object where the threading model is unknown.
15. The Semantics problem
Tools – the world of services, the picture depicts a hammer .. But what makes it a
hammer ??
Context and Environment – we possess an understanding of hammering – that is how
to use a hammer
Context and
Context and Environment underpins our view of services through the Environment
notion of suitability.
However our view of services underlies Context and Environment
Intelligibility Suitability
through the notion of intelligibility
Tools
Reflex Hammer – used in medicine !!