- Can you give me a recent example of your SOA projects? How did you handle security?
- What is a SOA and why is it important?
- How do you define a successful SOA?
A successful SOA implementation requires that an organization substantially transform
their process to move from a traditional function-oriented, built-to-last, and long-running
development cycle to a process-oriented, built-to-change, and incremental build-and-deploy
process. Traditional development, in general, is aligned to application silos, is
tightly coupled, and is structured using components and objects as building blocks.
SOA development presents orchestrated solutions that are loosely coupled, using
services as their building blocks. It's important to recognize the differences and
establish a process to support the transformation
- What is the difference between services and components?
Services are logical grouping of components to achieve business functionality. Components
are implementation approaches to make a service. The components can be in JAVA,
C#, C++ but the services will be exposed in a general format like Web Services.
- What SOA design patterns have you used in the past?
- What design principles do you use when architecting SOA services?
- How can you achieve loose coupling of services?
As you know design patterns describe recurring solutions to common problems in software
design. And recognizing and implementing these patterns is an essential part of
successful Service Oriented Design. Below are 5 SOA design patterns:
1. Multichannel Applications
2. Composite Applications
3. Business Process Orchestration
4. Service Oriented Enterprise
5. Federated SOA
Multichannel Application SOA is a perfect fit for multichannel
applications. This pattern separates the back-end business logic from the front-end
logic and delivers full application functionality to a maximum number of users from
various channels in a minimal amount of time while reusing the same exposed services.
Strategic Planning Assumption: By 2008, more than 66% of new midsize and large interactive
applications will be designed to support multichannel access, up from less than
33% in 2007.
Composite Applications Services used in composite applications
may be new service implementations, fragments of old applications that were adapted
and wrapped, or combinations of the above. Two types of integration technology are
essential for effective operation of a composite SOA environment: 1) integration
technology behind the service interfaces, helping users wrap and adopt various pre-SOA
applications; and 2) integration technology helping users assemble and monitor transactions
from services.
Strategic Planning Assumption: Through 2012, the majority of SOA-style applications
will be interactive composite applications.
Business Process Orchestration Business process management (BPM)
suites are the tools devoted to implementing such SOA-based multistep processing
flows. The BPEL standard is often used to document the designed metadata flow model.
The metadata repository ("meta-database") is used to manage the proceedings of the
business process model at runtime. Some steps of the process are implemented by
calling SOA services. Other steps require human intervention.
Strategic Planning Assumption: By 2009, more than 75% of SOA applications will implement
some sequencing control outside of code of the service implementations, via external
BPM technology.
Service Oriented Enterprise The SOA-based enterprise model is a
step beyond composite applications. Here, all applications are perceived as components
of one integrated whole. No new application is created in isolation. Each application
is built from reusable components that are available for use not only in their initially
intended context, but also by other clients in other contexts. Essentially, the
integrated composite enterprise consists not of applications, but rather business
components — each an asset of the entire enterprise.
Strategic Planning Assumption: By 2010, more than 85% of enterprises will have combined
their application integration and SOA management tools and organizations.
Federated SOA The fundamental idea behind federated SOA is to logically
split the enterprise into semi-independent SOA domains (for example, reflecting
the enterprise organization in terms of subsidiaries, Business Units or departments),
each with its own specific SOA infrastructure, governance processes and SOA Center
of Excellence. Domains are then federated (that is, integrated — usually, but not
necessarily, after the fact — to enable inter-domain sharing of services) through
appropriate interoperability infrastructure, governance processes and organizational
settings. "SOA federation" is the process of enabling a federated SOA by establishing
the proper technical, governance and organizational capabilities.
Strategic Planning Assumption: Few large organizations are able to establish a singular
architectural blueprint for their entire IT. The best practice is to endorse domain
independence and allow them to differ in technology and architecture in exchange
for agreement to synchronize interoperability protocols and transports. Mergers
and acquisitions are clearly candidates for Federated SOA.
- What works better top-down or bottom-up service identification?
Top-down would suggest that you analyze your business processes, identifying activities
in support of your process that become candidate operations on service specifications
A Bottom-up approach would suggest that you analyze existing applications and assets
to identify those that will are candidates to be "service-ified".
Top-down - Has the advantage that the services identified throughout the layers
of the solution are aligned with the business processes which provided the scope
for the solution. It is also attractive from a project management perspective in
that the business process under consideration provides a natural project scope for
the development effort. However, the major drawback to this approach (and the reason
the customer I mentioned earlier got unstuck) is that it becomes harder to ensure
that you develop services for reuse (some thoughts on SOA and Reuse) as developers
are looking to develop services that support this process rather than ones that
will contribute to an enterprise-wide service portfolio.
Bottom-up - A bottom-up approach has the potential to develop a set service that
can support a number of processes, addressing the concern above, as the developers
are looking across a broad set of artifacts. The issues here are that where data
is the focus of the artifact analysis the tendency is to generate CRUD services
(which is bad) or to develop access operations that do not match well the requirements
of processes and therefore require business services to make multiple calls into
data-management services.
- How can services supporting long running processes be scaled effectively?
- How can a SOA avoid redundant service logic?
- What is the difference between agile and scrum?
Agile and Scrum are terms used in project management. The Agile methodology employs
incremental and iterative work cadences that are also called sprints. Scrum, on
the other hand is the type of agile approach that is used in software development.
Agile
The Agile methodology is used in project management and it helps project makers
to build software applications that are unpredictable in nature. Iterative and incremental
work cadences called sprints are used in this methodology. It is basically inspired
from traditional sequential model or the waterfall model.
The benefit of using the Agile methodology is that the direction of the project
can be accessed throughout its development cycle. The development is accessed with
the help of iterations or sprints. At the end of each sprint, an increment of work
is presented by the team developing the project. The focus is mainly on the repetition
of work cycles and the product they yield. This is the reason why the agile methodology
is also called as incremental and iterative.
In agile approach, the each step of development such as requirements, analysis,
design etc are continually monitored through the lifecycle of the project whereas
this not the case with the waterfall model. So by using agile approach, the development
teams can steer the project in the right direction.
Scrum
Scrum is a type of agile approach that is used in development of software applications.
It is just a framework and not a methodology or a full process. It does not provide
detailed instructions to what needs to be done rather most of it is dependent on
the team that is developing the software. Because the developing the project knows
how the problem can be solved that is why much is left on them.
Cross-functional and self-organizing teams are essential in case of scrum. There
is no team leader in this case who will assign tasks to the team members rather
the whole team addresses the issues or problems. It is cross-functional in a way
that everyone is involved in the project right from the idea to the implementation
of the project.
As it is an agile methodology, it also makes use of series of iterations or sprints.
Some of the features are developed as a part of the sprint and at the end of each
sprint; the features are completed right from coding, testing and their integration
into the product. A demonstration of the functionality is provided to the owner
at the end of each sprint so that feedback can be taken which can be helpful for
the next sprint.
The product is the primary object of a scrum project. At the end of each sprint,
the system or product is brought to a shippable state by the team members.
- Give me an example where you worked with stakeholders to document functional and
non-functional requirements. How did you prioritize the requirements?
Requirement that affects the functionality of the system is Functional and if it
will be the constrain to the system is Non-Functional.