간단해서 보기 좋다. JBI-A standard-based approach for SOA in Java

By Mareej Kinnumpurath 13 Dec 2005 | TheServerSide.com

The industry has witnessed the evolution of a wide range of solutions addressing the problem space of B2B and enterprise application integration (EAI). These solutions varied from proprietary message oriented middleware to standard JMS based solutions and web services. This paper provides a brief introduction to the upcoming JBI (Java Business Integration) standard in relation to SOA (service-oriented architecture) principles and the ESB (Enterprise Service Bus) infrastructure.

Service Oriented Architecture

SOA (service-oriented architecture) is one of the latest developments that have made a huge leap in the area of application and business integration. SOA defines a set of well-defined architectural principles, paradigms and best practices to enable loosely coupled interaction between applications.

SOA promotes loosely coupled interaction between participating applications based on well-defined interfaces. Service implementations are self-contained and don’t depend on the contextual information and state of other services. Service interactions are mainly based on exchanging document-style data, defined using a standards-based messaging model. The services themselves are agnostic to the transport level interactions required to enable the communication between the service provider and service consumer.

Even though not a mandatory requirement, most of the modern SOA based systems utilise web services and related technologies for providing the required plumbing for the interactions between services. WSDL (Web Services Definition Language) is used as the main artefact for representing messaging models; SOAP as the message representation protocol and HTTP as the wire-level transport protocol. This doesn’t mean you always need to use the aforementioned technologies for implementing systems based on service-oriented architecture. Lot of enterprises have used similar architectures for realising loosely coupled systems, well before any of these buzzwords came into existence. However, the key difference is that now we have standards-based protocols, toolsets and software for enabling service oriented architecture.

SOA principles are significantly different from object-oriented paradigms and principles. The key difference is that the interactions between services are defined using interfaces that are oriented more towards data than behaviour. A service in isolation may be realised using object-oriented principles and techniques, however, the interactions between the services seldom use any of these techniques. Rather, these interfaces are geared more towards document-based interchanges. Where object-orientation binds behaviour closer to data, service-orientation decouples data from behaviour.

Enterprise Service Bus

An ESB (Enterprise Service Bus) provides the infrastructure for realising service-oriented architecture. ESBs provide a runtime environment for deploying and enabling your services augmented with design-tools for defining the interaction and orchestration of the services.

In the ESB world the services don’t directly interact with each other. Rather, the ESB runtime acts as a mediator between the services to loosely couple them. The ESB runtime would implement protocol bindings, message translation, message handling etc.

The key services provided by an SB would include:

• Providing transport bindings for the services
• Providing definition and discovery of the deployed services
• Rules based routing and orchestration of messages between services
• Value added services including document transformation etc

Most of the ESB vendors base their SOA proposition on open standards and technologies including the various web services standards and protocols. They provide a variety of transport bindings for invoking the services including HTTP, FTP, and JMS etc. Most ESBs use WS-BPEL (Business Process Execution Language for Web Services) for realising orchestration between the deployed services for implementing business processes. ESB vendors also provide quality of service features including fault-tolerance, failover, load balancing, message buffering etc.

Java Business Integration

JBI (Java Business Integration) is a Java-based standard addressing the EAI and B2B issues based on the paradigms and principles advocated by service-oriented architecture. The current version (1.0) is finalized through the JSR (Java Specification Request) 208 in August 2005. Both commercial and open source worlds have already started embracing JBI as an integration standard in their ESB products.

Mediator-based Architecture

JBI defines a plug-in based architecture where services can be plugged into the JBI runtime environment. JBI provides well-defined interfaces for services to interact with the JBI runtime environment. The services need to expose interfaces to the JBI runtime environment for the JBI runtime environment to route messages to the services. The JBI runtime environment acts as a mediator between the services that are deployed in the environment.

The JBI runtime core mainly comprises of the following components within the same JVM:

• Component framework: The component framework enables the deployment of the different types of components within the JBI runtime.
• Normalized Message Router: Normalized message router enables a standard mechanism of message interchange between the services.
• Management framework: The management framework based on JMX enables the deployment, management and monitoring of components within the JBI runtime.

Component Model

JBI defines two types of components in the JBI runtime environment,

• Service Engine Components: These are components responsible for implementing business logic and other services. The SE components can internally be realised using various technologies and design principles. SE components can be as simple as a component that provides low-level services like data transformation and translation or something more convoluted as a WS-BPEL instance that models an intricate business process.
• Binding Components: Binding components are mainly used to provide transport level bindings for the deployed services. BC components can be of a variety of types including,
  • Enabling remote communication with external systems using standard transport protocols.
  • Enable in-VM invocation between two services deployed in the same JVM.
  • Enable communication between services using standard WS-I (Web Services Interoperability) profiles.

The key aspect of JBI is the decoupling of the service engine and binding components so that business logic is not infested with the infrastructure details required for invoking and consuming services. This promotes a flexible and extensible architecture. Both BC and SE components within JBI can be service providers and/or service consumers.

Both BC and SE components provide interfaces to the JBI runtime for accepting messages from the JBI runtime. Similarly, they use interfaces provided by JBI for communicating with the JBI runtime.

Messaging Model

JBI uses a messaging model that decouples the service consumers from the service providers. The messaging model is defined using WSDL. WSDL is used to describe the operations exposed by both SE and BC components. WSDL is also used to define transport level bindings for the abstract service operations.

One of the key components used in the JBI architecture is NMR (Normalized Message Router). NMR provides the main messaging spine built around WSDL, which provides the loosely coupled message exchange between the SE and BC components deployed within the JBI runtime. Services are required to have interfaces, which are an aggregation of operations. Each operation is composed of zero or more messages. An interface can have one or more transport level bindings.

JBI uses a normalized format for representing messages within the runtime. A normalized message is composed of the following parts,

• Message properties
• Message payload
• Message attachments

The JBI specification provides standard interfaces for the service consumers and providers for exchanging messages with the NMR. NMR supports both one-way and request-response semantics for service invocation between consumers and providers.

Management

JBI uses JMX for the runtime installation, configuration and monitoring of services. The services are required to implement a set of JBI interfaces to make them manageable in the JBI environment. The JBI environment is required to provide a set of JMX MBeans to enable the management of the JBI runtime.

The JBI runtime environment allows the following operation related to the SE and BC components,

• Installation of components: This will make the component interface available to the normalized message router.
• Installation of component artefacts: This will allow deployment of component artefacts required for the functioning of installed components. For example, this could be deploying the connection details required to connect to a database for a deployed service that requires connecting to the database.
• Starting and stopping of services and groups of related services.

JBI defines standard deployment descriptors and packaging models for both components and component artefacts.

Roles

JBI identifies the following roles for providing an end-to-end JBI based EAI solution,

• Engine developers: Engine developers are required to provide the SE components that adhere to the NMR and management contracts.
• Binding developers: Binding developers provide the binding components that adhere to the NMR and management contracts.
• JBI Environment providers: JBI environment providers are required to support the JBI runtime using either J2EE 1.4 or J2SE 1.4 r newer platform.
• J2EE Platform providers: J2EE platform providers may include a JBI runtime as part of their application server offerings.
• JBI Application developers: JBI developers build JBI applications using the SE and BC components and the JBI environment.

Conclusion

With the whole industry aligning more and more towards open standards and specifications, JBI takes a great leap in enabling Java technologists adopting a standards-based approach in addressing integration issues using service oriented architecture and ESB infrastructure. Both commercial vendors like Oracle and open source software like ServiceMix have already started adopting JBI as part of their ESB offerings.

About the Author

Meeraj Kinnumpurath works as a Java architect with VOCA Ltd (formerly BACS), who are the largest clearing house in Europe. He has been using Java for the past eight years, developing enterprise applications. He has also published a few books on Java, J2EE and Web Services.

오늘도 역시 현실과 이론에 대한 강력한 이론에 괴리가 있음을 봉착했다.
공부 잘하는 놈이 돈잘 번다 라는 이상한 논리가 맞지 않음을....

결국 공부 많이 한 인간은 자기가 보는 것만 최우선이라서...
오히려 다른걸 못본다. 때문에 아키텍처 흐리는 거지.... 물론 안 그런 경우도 많다.

미꾸라지 잡다가 논뚜렁 망가지고 한해 농사 다 망칠라..... 아키텍처에서 작은것 하나도 무시 못할 것들이 많다. 에자일이 꼭 좋은 것만은 아니며 모든 아키텍처에는 트레이드 오프가 있다.


보수적인 소프트웨어 아키텍처가 좋다.
그러나 간간히 개발자들은 새로운 아키텍처를 원한다. 호기심 채우려고 그런 사람도 있고 아닌사람도 있고 ....

만일 자신의 호기심을 채우기 위해 제품을 선택하거나 오픈소스를 쓰거나...
혹은... 재미로 프로젝트를 한다면.... 그것이 바로 미래의 불행을 만들 수 있다고 생각한다.



오늘은 말많은 Ajax가 또 하나 해먹었다. 으으.....
아무런 검증없이 썼다면.... 아마 지금 매우 힘들어 하고 있지 않을까....
당연한거 아냐....

Put this 100% Java Enterprise Service Bus to work for you today.

http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-jbi_p.html

IT 거버넌스...
IT에 종사한다면 누구나 이 문제에 접하고 있다고 생각한다.
그저 바른 가치를 가진 결정을 위한 것이라고 생각하면 그만 ....

그러나 항상 문제는 많이 있다.

1) 경영자의 생각은 오직 수치만을 보고 생각하고 느낀다.
2) IT경영자는 생산되는 속도로 모든걸 생각하고 싶어 하는 사람도 있다.
3) 어떠한 개발자는 자신의 코드가 최고이지만 왜 위로 보고가 안되는지 도데체 몰라한다.
4) 어떤 툴은 개발편의나 비지니스의 목적을 위해 도입된다 라고 생각하기엔 너무나 정치가 많이 들어있다.
5) 현업은 막무가네 만들어 달라고만 한다. 기술은 얼만큼 비지니스를 커버해야 하는가 ?
6) 누가 설계하는 것이 가장 적절할까 ?
IT ? 비지니스 ? 아니면...업무를 아는 IT ...
7) 누가 투자를 유치하며 투자를 위해 해야 하는 일은 무엇인가 ? 또 성공사례는 무언가 ?
어떤 회사가 에자일 하게 빠르게 IT를 적용하는가 ?
그저 강제적인 회사 ?
IT와 비지니스의 융합된 회사 ?
IT가 리더인 회사 비지니스는 IT를 지원해야 하는 회사...

기타등등.... 아직도 보고 느낀것을 적으려면 이 블로그가 턱도 없이 부족하지만 적고 싶은건 무진장 많다. 아....... IT거버넌스

http://www.chwlund.com/?p=60

After the release of the Service Component Architecture (SCA) specification last month there have been a lot of discussion related to how SCA relates to Java Business Integration (JBI) (JSR-208). I will try to clear thinks up, all in all (if you dont have time to read more): SCA is a specification to make developers make services (in a SOA) in a standard, consistent and technology-independent way and JBI is a specification that defines how integration products should look like and how vendors could actually choose to design an integration product or component (standardization between integration technology vendors)

I have written about Java Business Integration in another post. Read this to learn more about JBI. To sum it up, JBI is all about the standardization of integration products (mainly ESBs). JBI specifies an architecture and an API that should be used when developing integration products. So, in our everyday consultant lifes, we do not have to care so much about this standard, but I think its a really important standard for the integration market, because it opens up integration solutions and makes it possible for different vendors to collaborate. I have written a lot more about this in my older post.

SCA, on the other hand, will maybe influence our everyday life much more than JBI. SCA is a specification that defines how we as developers should write services in a service -oriented architecture. Its like a general WSDL, but also much more. It defines how a service should be described and how it relates to other services. In this way we can define services independent of the technology used to implement it.
A white paper from IBM shows a specific example of how SCA will change how we develop services:

A EJB represents a reservation service for a airline-company and the service is loaded by the application like this:

This is fine if you only use EJBs and your future services only will be EJBs. But what if you have to implement the reservation service using a different kind of java component or even another technology platform (like .Net). Then its better to refer to your services in a more neutral and transparent way, like this:

ModuleContext moduleContext=CurrentModuleContext.getContext();
AirReservation airReservation= (AirReservation)moduleContext.locateService(“AirReservation?);
airReservation.bookFlight(flight);


Dave Schaffer says this about the relation between JBI and SCA:

One of the beauty of SCA is that it is focusing only on things that a SOA developer sees and touches. SCA does not care about how the runtime that is going to execute a SCA module is architected.

SCA defines services and a way to create them, but it does not say anything about how the runtime enviroments should be like. A SCA service could be executed by an integration product like an ESB. And this ESB could be designed according to JBI. So, summed up, there may not be any relation between SCA and JBI, but they are two very important standard that may function complementary in a service-oriented architecture and you may end up running your SCA services in a JBI-compatible integraton suite. Please correct me if I am wrong, because I havent got a deep understanding of SCA yet…

Links:
Dave Schaffer: SCA, JBI and more..
The serverside: Discussion
Servicemix.org: How does ServiceMix compare to Tuscany or SCA”

Entry Filed under: Uncategorized

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824

Blogs

Comparing SCA, Java EE and JBI Jean-Jacques Dubray Business Card Company: SAP Labs, LLC Posted on Dec. 12, 2005 02:25 PM in Java Programming, SAP NetWeaver Platform, Technologies

Java EE is one of the most successful application model and rightfully so. It greatly simplifies the development of stand alone, scalable, available, secure and transacted web applications. Everything in its application model is designed to process an arbitrary number of simultaneous requests and create a response synchronously as fast as possible. JSPs/Servlets, Session beans, Entity beans (as an in memory data cache), the security model, the transaction model, ... are all assisting the developer in creating these responses, in the richest and fastest possible way.

In fact, JEE has been so successful it has imposed itself as the main and preferred way of accessing back-end data, not just as a way to write new and cool stand alone web applications. Back-end integration is not easy, technologies are varied and often rustic to say the least, and most back-end systems were not designed  with the requirements of web applications in mind. There are three approaches to develop back-end integration solutions: invocation, mediation and activation.

Invocation has been the most commonly used approach used to date through technologies such as JCA, JAX-WS or WS-IF which are well aligned to support the request/response model but fail to support complex long running integration scenarios associated to particular application states. This is precisely one of the problems in JEE today because back-end integration does not always fit well the synchronous request/response model.

Mediation, is not new, and has been applied through proprietary products and frameworks for a decade. Last summer the JCP published an API to build standardized mediation infrastructure: the JBI specification. JBI is based on the "mediated message exchange" pattern: when a component sends a message to another component, this interchange is mediated by the JBI infrastructure, namely the NMR or Normalized Message Router. The NMR functionality can be augmented by Service Engines (such as transformation or orchestration engines) to facilitate the mediation with back-end systems. However, centrally coordinated architectures, such as JBI, have historically always struggled with the problem of "who manages the central infrastructure". The problem is most acute in B2B scenarios where most companies don't want to incur the cost of "mediating" message interchanges unless there is some value add. Actually, the JBI specification explicitly excludes from its scope the normalization of the interactions between two JBI instances. These type of interactions happen behind binding components in a completely proprietary way. This restriction greatly compromises the composition capabilities of JBI instances. Hence, JBI is well suited to solve small and local integration problems.

Activation is a relatively new approach to the problem. It consists of producing components which can be accessed via different middleware, synchronously or asynchronously. Activation maximizes the autonomy of the components themselves and their ability to be composed with other components. In particular, this means that the business logic implemented by a component cannot depend or rely on any specific middleware facilities. This is the component model proposed by SCA. In SCA, activation applies either at the component level or at the module level. A module is an assembly of components running in the same process. 

SCA enables arbitrary topologies of systems, supporting synchronous and asynchronous, client/server, peer-to-peer, long running or short lived interactions. SCA does not make any assumption about company boundaries and enables exposing a system as a component participating in another system, each of which having different managing authorities, i.e. company boundaries may be defined or shifted arbitrarily across an SCA system. SCA is well suited to solve any integration problem in particular the most complex ones, including the ones solved by mediation and invocation infrastructures. In many ways, SCA can be viewed as a decentralized mediation infrastructure where mediation happens either at the provider or the consumer side, without necessarily involving an intermediary.

To further understand the differences between the 3 approaches, let's look at how a "connected system" is assembled, i.e. how the wiring is defined and enacted in each approach. In an invocation based infrastructure, the wiring is usually defined via a "connection string containing the end point reference and some credential. In a mediation based infrastructure, the connected system is defined via a configuration file that contains the specification of a particular assembly of components, routing rules, ... This specification is consumed by the JBI infrastructure (NMR, Binding Components and Service Components). However each binding component retains its own proprietary mechanism to specify wiring to the service provider or consumer behind the binding component. In SCA, there is no central coordinator and an assembly of components is deployed to each component type, which activate components (instances of component types) for each unit of work being performed.

I do not want to end this note just by saying that SCA offers a new integration model because, SCA is also and above all a new application model, i.e a new way to build applications as an assembly of autonomous software agents, exposing service interfaces. SCA is innovative because it offers a unified application and integration model.

We can expect that Java EE and SCA will coexist offering a complementary application model while JBI will be used in traditional Enterprise Application Integration scenario. 

Jean-Jacques Dubray is a Standards Architect at SAP Labs, Palo Alto.

많은 사람들이 궁금해 한다.
이전부터 무엇이 다를까 하고 ....

EAI는 Hub/Spoke 패턴이고 ESB는 말그대로 BUS패턴이라고 생각을 하고 있다.
그런데 이렇게 혼란 스러운 이유는 많은 벤더들이 자신들의 입장에서 제품을 만들기에
이런 이야기까지 나온다.
BPM 을 근간으로 하는 SOA, EAI를 근간으로 하는 SOA등등...
실제 그들의 아키텍처를 보더라고 제품을 부각하기 위해 많은 노력을 하는 것이 보인다.

아래에 좋은 참고가 될만한 자료를 올림 ^^

PS : EAI, ESB, BPM 모두 자신이 하는 일이 다르며
간단하게 내 생각을 말하자면 휴먼 프로세스는 BPM이...IT프로세스는 ESB가...
EAI는 기간계시스템의 연동정도로 생각하고 정의 하고 싶다.
EAI는 인프라에 바탕을 두고..ESB는 서비스의 조합및 서비스 컨트롤등을 근간으로 하며
BPM은 인간의 프로세스를 제어하기.....
결국 IT는 또다시 경영으로 넘어가는 구나...

참고자료 :

invalid-file